Please see below.
On 16/04/2019, 16:28, Joe Touch wrote:
Hi, Gorry,
Again, thanks for the detailed comments. We welcome them!
Responses below...
I'll comment a little more on some of these.
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.
Yes, that makes sense ;-)
---
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.
I just sent my transport review of that draft to the list. It looks like
both will be reaching maturity about the same time. It would be really
nice if they could in some way be aligned - e.g., I think there is a
possibility that the IETF could both discourage application designs
using fragmentation and encourage appropriate endpoint sizing, while
acknowledging the need for fragments for tunnels. Whatever the INT Area
concludes, the recommendation is going to impact transport and network,
and there needs to be consistent advice to be useful. (I suggested there
is an opportunity that these could be published as a document pair in
the RFC-series, that was my own thought, but it would require some work
now to get to that place.)
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.
I agree, headroom in the size that is actually used is important: The
maximum packet size used doesn't have to be the currently measured PMTU.
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).
Yes.
- 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).
OK - if you wish to focus on the need to be more resillient to changes
in the path, that would be reasonable argument to make.
---
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).
My reading of ietf-intarea-frag-fragile suggests this doesn't deperacate
fragementation, but advises strongly against - but you should read and
form your own opinion.
---
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.
If you want an example, I looked back at RFC8085, and it more or less
says that
---
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…
---
I have thoughts on the best process, but I'll let others comment. That's
indeed an INTAREA WG/IESG issue - if they are updates to transport area
RFCs/IDs then I do have opinions on best to approach this!
Gorry
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
