Re: [Int-area] Questions about INT Area Tunnels draft: aft-ietf-intarea-tunnels-09

[Joe Touch <[e-mail]>]

Hi, Gorry,

Again, thanks for the detailed comments. We welcome them!

Responses below...

> On Apr 16, 2019, at 4:28 AM, Gorry Fairhurst <[e-mail]> wrote:
> 
> 
> I have read draft-ietf-intarea-tunnels-09, because it is cited from another document that I am reviewing. I have a number of technical questions that I’d like to pass to the WG/editors for consideration.
> 
> Best wishes,
> 
> Gorry
> 
> (I also earlier posted some editorial comments.)
> 
> 
> *** Technical questions:
> 
> In section 4.1.1:
> “Similarly, the DF field of the
> transit packet is not related to that field in the tunnel link packet
> header (presuming both are IPv4) “
> - Why is this not true when IPv4 and IPv6 are used in combination to tunnel one over the other?

Because IPv6 has no DF field. DF on DF matters only when both headers have DF ;-)

IPv6 is always DF, so there are cases to explain, though.

I can make that more clear.

> ---
> In section4.2.1:
> “The high cost of
> fragmentation and reassembly is why it is useful for applications to
> avoid sending messages too close to the size of the tunnel path MTU
> [Ke95], although there is no signaling mechanism that can achieve
> this (see Section 4.2.3).”
> - This sentence seems like teh cost is just segmentation/reassembly costs. It's more complex we you wish to defend from attack and need to keep state in devices. So the original paper cited is just one part of the whole problem space. This ID seems to help clarify some of these issues: [I-D.ietf-intarea-frag-fragile-09].

As an aside, IMO, that document is a thinly veiled attempt to deprecate fragmentation that I continue to have concerns over.

That said, this sentence describes the problem of trying to tune closely to the tunnel path MTU; the attack and state issues in frag-fragile aren’t affected by whether a 2000B packet is split into 1280 and 720 or 1000 and 1000. It basically implies (though it could be more clear) that 1280 and 720 is a bad choice because the 1280 could later end up being fragmented into 1200, 80, and 720 (as a set) vs 1000 and 1000 if then going over a tunnel that needs to fragment to support 1280.

This can happen when you do PMTUD one hop at a time or even if you do the entire path with PMTUD if path properties change even a little (see below).

> - If you probed with context, as in (D)PLPMTUD you could achieve this signal?

You could but see above - the issue is trying to over-tune, not whether you can tune or not.

> Some further context on how to build more robust solutions is in [I-D.ietf-tsvwg-datagram-plpmtud].Using that approach I don’t see why that is the case - maybe my question is because section 4.2.3 is exclusively about PMTUD, and not PLPMTUD?

It wasn’t intended that way - it doesn’t matter how you find out, if you tune too close you end up running risks due to path changes, tunnel overhead changes, etc. too - even if you do it for the full path (PLPMTUD) vs each hop one at a time (PMTUD).

> ---
> In section 4.2.2:
> “Although many of these issues with tunnel fragmentation and MTU
> handling were discussed in [RFC4459]”
> - What is the relationship to the ID on Fragmentation Fragile [I-D.ietf-intarea-frag-fragile-09]?

Well, to start with I’m not trying to deprecate fragmentation — in fact, this document is a good reason why that can’t happen...

> - The present document in 5.3.1. states: “Always include frag support for at least two frags; do NOT try to deprecate fragmentation.“, which seems to be slightly incompatible with the other WG document?

Yes, IMO it is if you interpret frag-fragile as deprecating fragmentation (as I do, though the authors continue to claim isn’t really true - they’re just trying to get fragmentation to not be used, rather than to outlaw it).

> ---
> In section 4.3.2:
> - I think the following is open to misinterpretation and that concerns me, itdoes not seem strong enough::
> “ Tunnels carrying IP traffic (i.e., the focus of this document) need
> not react directly to congestion any more than would any other link
> layer [RFC8085].”
> - This refers to the UDP-Guidelines as BCP, which is OK, but if that is a reference then please more precisely quote the text in that RFC that says:
> “Two factors determine whether a UDP tunnel needs to employ specific
> congestion control mechanisms: first, whether the payload traffic is
> IP-based; and second, whether the tunneling scheme generates UDP
> traffic at a volume that corresponds to the volume of payload traffic
> carried within the tunnel.”
> - Is it posisble to also add a cition the detailed guidance in section 3.1.11 of RFC8085?

Yes.

> - It would be good to say [RFC2914] describes the best current practice for congestion control. Would that be OK?

Sure.

> - Please also consider citing [RFC8084] as a way to provide network tunnels and applications when using non-congestion-controlled traffic, to illustrate what can be done to realise some form of protection.

Absolutely - again, many of these docs didn’t exist when I started, so it’s very helpful to catch up this way…

> ---
> In section 4.3.3:
> - The section in Multipoint Tunnels and Multicast has no statement about unicast tunnels carrying multicast. I think this is a common deployment scenario. Is it possible to add something explicit, like:
> “Tunnels that carry IP multicast traffic with a unicast destination address, such as Automatic Multicast Tunneling [RFC7450] need to follow the same requirements as a tunnel carrying unicast data”
> - Do you think this is a fair recommendation? or have some other idea?

I’d have to think about this a little more, but yes, a recommendation in this area would be useful.

> ---
> In section 8:
> There are some references that I think need to be checked and referenced more:
> [I-D.ietf-tsvwg-ecn-encap-guidelines]
> [I-D.ietf-tsvwg-rfc6040update-shim]
> [I-D.ietf-tsvwg-datagram-plpmtud]
> [I-D.ietf-intarea-frag-fragile-09]?

Thanks again - these are helpful.

> ---
> In section 8.1:
> - I think there needs to be more normative references, especially on the documents where this recommends a change, or RFC2119 usage.

Agreed - I also think it’s likely this doc will end up UPDATING a lot of these docs where there are such explicit errors.

That may create a WG problem though - I don’t know if a BCP can update a STANDARD, but that’s for the WG and IESG to figure out, IMO…

---