Subject: Re: [tsvwg] UDP/IP outer as an IP-shim-IP tunnel and AMT as an example

From: Bob Briscoe <[email-masked]>
Date: Tue, 31 Oct 2017 00:01:16 +0000

Jake,

Sry, I just found your email from 02 Aug while checking for any 
correspondence I might have missed on draft-ietf-tsvwg-rfc6040update-shim

Responses inline...

On 02/08/17 20:35, Holland, Jake wrote:
>
> Hi Bob,
>
> Thanks for looking into my AMT question and following up.
>
> A few comments and questions:
>
> 1. I agree that your proposed addition covers a gap that was implied 
> but not stated by section 4.3 of RFC 6040.
>
> 2. I’m not understanding something: what is it about a protocol that 
> makes it a generic IP-inside-UDP encapsulation that doesn’t need to be 
> explicitly mentioned by the shim-update, vs. encapsulations that do 
> need an explicit update?
>
> Maybe I’m misunderstanding, but an AMT Data packet 
> (https://tools.ietf.org/html/rfc7450#section-5.1.6) 
> <https://tools.ietf.org/html/rfc7450#section-5.1.6%29> on the wire 
> looks like [L2]-IP-UDP-AMT-IP-..., and I think it’s correct that the 
> new ECN requirements in section 4 would apply in a way that I don’t 
> see how it’s different from GRE or Teredo. (Except maybe that it’s 
> unlikely ever to carry TCP in the inner IP; is that the distinguishing 
> factor?)
>
> draft-ietf-tsvwg-rfc6040update-shim-04 proposes to update Teredo and 
> GRE but not AMT, even though it seems from section 5.1 that both GRE 
> and Teredo also have the same kind of “probably existing 
> implementations are already compatible-mode in practice” status under 
> RFC 6040. But I’m not clear on why some of the protocols get an 
> explicit mention and others don’t.
>
[BB]: Sry, I didn't realize there was an AMT header in the IP-UDP-AMT-IP 
stack. I thought AMT relied only on the UDP header between IP headers. I 
should have read the RFC properly, shouldn't I?

So, in answer to your question, AMT does need an explicit update. The 
only encapsulations that don't need an explicit update are those that 
use a simple IP:UDP:IP encap , because they are all covered by the fact 
that RFC8085 already refers to RFC6040.

So, I have created a new section for AMT in my local copy of 
draft-ietf-tsvwg-rfc6040update-shim, which I intended to post before the 
deadline last night but I ran out of time. So I'll send to you before 
the end of the week.

I believe we're going to have to create an ECN capability negotiation 
between the gateway and the relay. Because the relay should only use the 
normal tunnelling mode of RFC6040 if it has checked that the gateway has 
ECN decap logic.

We'll probably need to use one of the reserved bits in the relay 
discovery and relay advertisement messages. This capability negotiation 
should broadly follow the pattern of the L2TP capability negotiation 
that's already in the shim draft, except it's simpler, cos data 
forwarding is all one-way.

Once done, I'd appreciate if you could check that what I've written is 
correct.

Thanks for questioning this - I've added you to the ACKs in my local copy.

> 3. Related: What makes it impractical to update all the IP-inside-UDP 
> RFCs?
>
> It seems to me like it would be useful, because whether I’m an 
> implementer or a network operator, if I implement or deploy a protocol 
> such as AMT, today I get no hint from 
> https://tools.ietf.org/html/rfc7450 or from the RFC index that I have 
> any responsibilities regarding ECN.
>
> But if the page for RFC 7450 had the “Updated by” link at the top 
> pointing to the new update-shim document, both these cases seem much 
> more likely to have their ECN behavior considered during a normal 
> round of due diligence.
>
[BB]: Indeed, ensuring the relevant RFCs have an "Updated by" tag is 
what I'm trying to do with this exercise.

Now that I understand AMT's encap, I have added 7450 to the "Updates:" 
header of draft-ietf-tsvwg-rfc6040update-shim so, once it is published 
as RFCXXXX, the RFC index, IETF tools and datatracker will tag 7450 with 
"Updated by RFCXXXX".

> It also seems justifiable to update all such protocols, because 
> section 4 of draft-ietf-tsvwg-rfc6040update-shim-04 does impose new 
> requirements, even if (as section 4 argues) the requirements are not 
> expected to change any existing implementation’s actual compliance 
> status, since it’s probably already doing compatible-mode.
>
[BB]: My goal is indeed to update "all such protocols", but I'm limiting 
the scope to those on the standards track or in widespread use. 
Otherwise I would have to cover loads of protocols that are long dead.

Nonetheless, draft-ietf-tsvwg-rfc6040update-shim says it applies to any 
tunnel protocol within its written scope, so it still covers any I have 
missed and have therefore not listed explicitly.

A number of helpful people like you have pointed out ones I've missed, 
but the rate of discovery has reduced to a trickle. So altho the process 
could theoretically continue for ever, I think to all intents and 
purposes the output has halted.

> Is there a good list of existing IP-shim-IP tunnel protocols that the 
> 6040 update-shim document applies to? Is it feasible to include one in 
> this document, whether or not this document will explicitly update them?
>
[BB]: If you know of any I've missed (after I post the lastest rev 
tonight), pls tell me.
I bet you're now going to prove me wrong when I say the rate of 
discovery has reduced to a trickle, aren't you?!

> Today that project seems to be left as an exercise for the network 
> operator, if RFC8085/BCP145 is the suggested answer.
>

[BB]: And apologies again for missing your email.

Bob
>
> Kind regards, and thanks again.
>
> Jake
>
> On 7/20/17, 2:26 AM, "Bob Briscoe" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> David (as doc shepherd),
>
> In the tsvwg mtg onTue, it was suggested that AMT ought to be included 
> in the list of RFCs that define a new IP-shim-IP tunnelling protocol.
>
> I said that I had actually looked at this and decided not to include 
> it. I now remember why. It was cos AMT is just using UDP-IP 
> encapsulation, not really defining a new encapsulation.
>
> Nonetheless thanks to the guy who came to the mic (sry I can't 
> remember the name - I think from Akamai) for making me revisit this. 
> It identifies a gap: rfc6040update-shim doesn't mention general use of 
> UDP-IP encapsulation. It only mentions the specific case of GUE 
> (generic UDP encapsulation).
>
> The way I propose to handle this is to add a bullet in 5.  IP-in-IP 
> Tunnels with Tightly Coupled Shim Headers 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtsvwg-2Drfc6040update-2Dshim-2D04-23section-2D5&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=VM32VUO08UF8Qna2N2K2LeXXaxEJuS5bXaWxlvKSSac&s=DHj4DEzT-tdNKgKJkuD7wryzKTZCEysTcq1XnSUwvGo&e=> 
> for UDP tunnels. Then add the following covering general use of UDP-IP 
> encapsulation, giving AMT as one example of it:
>
>        5.1.x UDP Tunnels
>        Section 3.1.11 of the UDP usage guidelines in RFC 8085 already
>        explains that a tunnel that encapsulates an IP header within a
>        UDP/IP datagram, e.g. Automatic Multicast Tunneling (AMT
>        [RFC7450]), needs to follow RFC 6040 when propagating the ECN
>        field between inner and outer IP headers.
>        The requirements in Section 4 update RFC 6040, so they add
>        the important, but previously unstated requirement that, if
>        the UDP tunnel egress does not, or might not, support ECN
>        propagation, a legacy UDP tunnel ingress has to zero the outer
>        ECN field, e.g. by configuration.
>
> Do any RFC's need to be updated? No.
> Given the UDP tunnelling section of RFC 8085 (UDP usage guidelines) 
> already refers to RFC 6040, I don't think we need to update every RFC 
> that uses UDP Tunnelling to refer to RFC 6040.
>
> It would be ideal, but perhaps impractical.
>
>
>
> Bob
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/ 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__bobbriscoe.net_&d=DwMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=VM32VUO08UF8Qna2N2K2LeXXaxEJuS5bXaWxlvKSSac&s=sLmMIa1pa488n_G5PUpLou0aYaFwXxSYz0N9aiSeuw0&e=>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/