IPsecME folks,
I would like to draw your attention to
<https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-tunnel/> from
the transport area w-g.
You may recall I gave early warning of this work to the Security Area
open meeting back in July'09. A formal SecDir review has just been
requested, but voluntary reviews from other people who live & breath
IPsec would also be greatly appreciated. We want to get this right.
Please include me in the distr if you post any issues (or
non-issues), as I'm not permantently subscribed to <ipsec@ietf.org>.
Ideally cc <ts...@ieft.org>.
You will notice it updates 4301 decap. I want to emphasise that the
update only affects a combination of inner & outer that is currently
unused (CU) - existing 4301 behaviour remains completely unchanged,
and it adds no modes or options.
Abstract is below.
Cheers
Bob
========================================================================
Transport Area Working Group B. Briscoe
Internet-Draft BT
Updates: 3168, 4301 March 03, 2010
(if approved)
Intended status: Standards Track
Expires: September 4, 2010
Tunnelling of Explicit Congestion Notification
draft-ietf-tsvwg-ecn-tunnel-08
Abstract
This document redefines how the explicit congestion notification
(ECN) field of the IP header should be constructed on entry to and
exit from any IP in IP tunnel. On encapsulation it updates RFC3168
to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec
ECN processing. On decapsulation it updates both RFC3168 and RFC4301
to add new behaviours for previously unused combinations of inner and
outer header. The new rules ensure the ECN field is correctly
propagated across a tunnel whether it is used to signal one or two
severity levels of congestion, whereas before only one severity level
was supported. Tunnel endpoints can be updated in any order without
affecting pre-existing uses of the ECN field, providing backward
compatibility. Nonetheless, operators wanting to support two
severity levels (e.g. for pre-congestion notification--PCN) can
require compliance with this new specification. A thorough analysis
of the reasoning for these changes and the implications is included.
In the unlikely event that the new rules do not meet a specific need,
RFC4774 gives guidance on designing alternate ECN semantics and this
document extends that to include tunnelling issues.
________________________________________________________________
Bob Briscoe, BT Innovate & Design
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
