Hi, Gorry, Again, thanks for the detailed comments. We welcome them!
Responses below... > On Apr 16, 2019, at 4:28 AM, Gorry Fairhurst <[email protected]> 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… --- _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
