Subject: [tsvwg] Please expand RFC6040 to address all IP-based tunnels

From: Steve Baillargeon <[email-masked]>
Date: Wed, 30 Dec 2015 14:15:54 +0000

Adding IETF tsvwg list.

-Steve B

From: Bob Briscoe [mailto:[email-masked]]
Sent: Wednesday, December 23, 2015 6:49 PM
To: Steve Baillargeon
Cc: Ingemar Johansson S; John Kaippallimalil
Subject: Re: RFC6040 Questions

Steve,

We should be having this conversation on the IETF tsvwg list. Then we would get other people's views. I'm not sure of the IETF position on this.

Do you mind fwd'ing this thread to tsvwg?

Bob
On 23/12/15 18:27, Steve Baillargeon wrote:
Hi Bob
What about doing a RFC6040 bis?
RFC 6040 title is already generic enough to include all tunnels.

My view is the IP header of the GTP-U tunnel belongs to IETF and 3GPP must repeat or reduce its scope as needed within its 3GPP spec.

-Steve

From: Bob Briscoe [mailto:[email-masked]]
Sent: Tuesday, December 22, 2015 8:16 PM
To: Steve Baillargeon
Cc: Ingemar Johansson S; John Kaippallimalil
Subject: Re: RFC6040 Questions

Steve,
On 20/12/15 15:40, Steve Baillargeon wrote:
Hi Bob
I had the time to look into ecn-encap draft.
At this point in timer, my biggest concern is mostly how the information is organized.

ecn-encap states :
Therefore, in all such tightly coupled IP-in-IP tunnelling protocols, the rules in [RFC6040] for propagating the ECN field between the two IP headers SHOULD be applied directly.

But RFC 6040 states the doc is for IP-in-IP tunnels (only).

Yes I felt into the trap and originally assumed RFC 6040 would apply to all "IP-based tunneling protocols" i.e. any tunnel that requires an outer IP header.

I general, I prefer to have all the info for a given topic in one doc. I am sure they are many RFCs out there that do not follow this "guideline".
But it will be great to have all ECN propagation rules and guidelines about all IP-based tunneling protocols in 1 place i.e. in RFC 6040.

I also think that having such consolidated IETF document will make it easier for 3GPP to updates their documents related to LTE traffic over GTP-U tunnel and IPSec.
I will take an action to discuss updates to GTPv1-U spec. I would prefer to add a reference to a complete RFC 6040 as opposed to "re-invent the wheel" in the GTPv1-U spec.
For a 3GPP protocol (like GTP), the IETF doesn't have change authority over it anyway. The 3GPP has to change the GTP spec. And once ecn-encap is published as an RFC it will give the 3GPP the necessary IETF reference to do that.

However the standards ownership is a bit hard to unpick, because GTP is a construction of IP (=IETF) headers with a GTP header (=3GPP) in between. So the 3GPP has to specify what values a GTP tunnel endpoint should put in IP header fields, when the 3GPP doesn't actually have jurisdiction over IP. That's why I'm trying to make it easy for 3GPP, giving them an IETF spec to cite that says what the IETF would do in the general case. But in writing that, I have to be careful not to tread on the 3GPP's toes!

Rather than state this rule only in ecn-encap (once it is an RFC), I would also prefer to be able to tweak RFC6040 to widen the over-narrow scope I gave it at the time. I will try, but RFCs can never be materially changed one published, so the only ways to do that are:
a) An erratum to RFC6040;
b) A new RFC containing the whole text of RFC6040 verbatim, plus the extra scope statement.
c) Add an "Updates RFC6040" header to ecn-encap, so when it becomes RFC the short section on tunnelling will update RFC6040.
d) A very short new standards track RFC with the additional scope statement for RFC6040, and a header that says
    Updates: RFC6040
which will then cause RFC6040 to be flagged as "Updated by RFCXXXX"

(a) is only applicable to correct a non-technical error, so unlikely to be acceptable to the IETF.
(b) isn't the way the IETF normally works, because it opens up all the original debates on the wording of RFC6040 that were closed when it was published.
(c) is not feasible, because ecn-encap is a BCP, which cannot update a Proposed Standard. Also, ecn-encap is long, and only one short paragraph would update RFC6040, so I don't like this approach because it's messy and unclear
(d) is likely to be the only way the IETF allows - it is the 'normal' way the IETF works.

Altho (b) would be tidier, (d) is all that can happen.

Regarding the aspect of having multiple IP-based tunnels terminating at the same end node/device.
For instance: inner IP/GTP-U/middle IP /ESP/outer IP (omitting UDP here)
If ECN propagation is not successfully at the outer encapsulator, then I believe the end node must inspect the middle IP header and propagate middle ECN to inner IP as you have it defined in Figure 4 in RFC 6040.
Therefore, in practice, I believe we will always need to inspect both middle and outer IP headers at the dual tunnel decapsulator .
What does "ECN propagation is not successful at the outer encapsulator" actually mean?

Actually you don't need to answer. Because I have realised that the ECN propagation rules have to be applied to one pair of IP headers at a time, even before one considers testing for all the illegal or CU (Currently Unused) combinations of ECN fields in Fig 4 of RFC6040.

A CE middle can legitimately be encapsulated by an ECT(0) outer if the tunnel ingress is RFC3168-compliant (which is why this is a legitimate combination in Fig 4 in RFC6040). So the outer can legitimately be ECT(0) while the middle is CE, and the inner is ECT(0) (say). So, it would be wrong for decap to ignore the CE in the middle by just applying RFC6040 propagation rules between outer and inner.

My second biggest concern is how to achieve "incremental deployment" without negatively impacting the forwarding capacity of the tunnel encapsulators/decapsulators.
I suspect many existing tunnel encapsulators and decapsulators do not support ECN field nor ECN propagation rules.
For implementers who follow standards carefully, that should be rare for IPsec hardware, because ECN was around (if experimental) when IPsec was defined, and there was a lot of discussion with the security community about ECN.

However, even for standards-conscientious implementers, it's likely that early non-IPsec (IP-in-IP) tunnel hardware doesn't support ECN. And possibly later hardware too, because RFC3168 omitted to flag in its headers that it updated RFC2003. However when I noticed this I registered an erratum to RFC2003, so that at least it is flagged as updated by RFC3168.

Nonetheless, I am also well-aware that a number of IPsec tunnel implementers are not standards-conscientious, and think they are entitled to ignore ECN propagation (or invent their own way of doing it). Reasoning ranges from i) not even being aware of ECN, through ii) "ECN isn't deployed yet" to iii) a belief that a security hat entitles you to ignore standards that do not seem to be security-related (as I've said, information security people can tend to be blind to traffic security issues).

Do you expect the implementer to initial support the RFC 6040 ECN propagation rules in "software"?
If so, I suspect it will cause reduction in forwarding capacity (?).
Do you have any feedback or suggestion on this matter?
I wouldn't expect support for RFC6040 to be universal yet because it's only 5 years old, but it doesn't have to be universal - compliance with the earlier protocols that it consolidated (RFC3168 and/or RFC4301) would be sufficient for interoperability.

However, I would have very little sympathy for an implementer that had failed to comply with a 15-year-old standards-track change [RFC3168] to the most important interoperability protocols in the world (IPv4 & IPv6). So if an operator discovers it is operating boxes in its network that do not comply with (say) RFC3168, it should check when it tendered for the box. IMO, if this was less than 15 years ago, it would be perfectly entitled to go back to the implementer and seek redress for a failure to comply with the IP standards in force at the time of tender (obviously depending on the exact wording of the contracts and tenders).

If all ECN-tunnelling standards have been ignored, I imagine the most likely behaviour will be:
* copy inner to outer on encap (because the outer is usually constructed by modifying a copy of the inner). [This would be RFC6040 compliant anyway]
* ignore outer on decap [non-compliant]
So the problem is only on decap.

I think there is a temporary hardware solution for decap, by abbreviating the rules in Table 4 of RFC6040 to reduce the codepath:
   foreach packet {
        if (read(packet, ECN_outer) == CE) {
            strip_outer();
            remark(packet, ECN_inner) = CE;
        } else strip_outer();
    }

These three steps can be done by configuration of today's hardware. An operator could temporarily use this hack as long as:
a) it was doing no ECT(1) marking in its network (at the moment only PCN does that)
b) it had deployed nothing in its network that relied on the drop behaviour in Table 4 of RFC6040

Don't quote me on this! I'm not really advocating that operators don't need to comply with RFC6040. The whole point of which was to ensure a single predictable behaviour from all tunnel equipment.

Nonetheless, if introducing the extra steps for CE-marked packets reduced performance, it shouldn't be too bad, as long as CE packets were a small proportion of the aggregate (which would be typical initially, altho the introduction of scalable TCP hosts in a few year's time could change that).
If the hardware couldn't keep up, it would merely drop some CE packets.

On the other hand, if decap were left completely non-compliant, the result would also be drops - but probably worse episodes of drop than might be caused by very occasional processor overload due to one extra process step. The drop would probably be worse, because, it would be caused by an oscillation of end-system load overrunning capacity. Explanation: if there were an ECN router in the middle of such a tunnel, any congestion marking would get discarded at egress, leading to the sender causing more and more severe congestion until drop started. That wouldn't be fatal, but it would lead to intermittently high drop.

Bob

Thank you Bob

Regards
Steve Baillargeon

From: Steve Baillargeon
Sent: Thursday, December 03, 2015 11:52 AM
To: 'Bob Briscoe'
Cc: Ingemar Johansson S; John Kaippallimalil
Subject: RE: RFC6040 Questions

Hi Bob
Thank you for the detailed response. Very helpful.

Let me review your proposal i.e. ignore the intermediate header.
I will investigate the main GTP-U and IPSec uses cases and it see if it holds.

I will also try to comment as you requested on  https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-encap-guidelines-04#section-5.1

Regards
Steve Baillargeon
Ericsson