Hi Joe, Thanks so much for your review and feedback. I have just published a new version of the draft that I believe covers the concerns you raised in the review.
New: https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-05 <https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-05> Changes: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-05 <https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-05> Thanks, Chris. > On Dec 19, 2020, at 7:57 PM, Joseph Touch <to...@strayalpha.com> wrote: > > > >> On Dec 19, 2020, at 2:16 PM, Christian Hopps <cho...@chopps.org >> <mailto:cho...@chopps.org>> wrote: >> >> >> >>> On Dec 4, 2020, at 3:14 AM, Christian Hopps <cho...@chopps.org >>> <mailto:cho...@chopps.org>> wrote: >> >> Looking through this list I realized one thing. We are not technically >> defining a new tunnel here. We are defining a new payload for the already >> defined IPsec/ESP tunnel. So many of these points are covered by the base >> ESP tunnel document. Where we do differ is that we do not pre-fragment >> packets (i.e., we do not use IP fragmentation or have a tunnel MTU) on >> ingress as the encapsulation supports fragmentation and reassembly by design >> of any sized IP packet. This fact is noted in the text while talking about >> the DF bit mapping (or lack thereof). > > It’s the ways in which you differ that need to be addressed. > >> "IP-TFS never IP fragments the inner packets and the inner packets will not >> affect the fragmentation of the outer encapsulation packets." > > It doesn’t IP fragment, but it does fragment. There are still fragmentation > and reassembly considerations as a result. > >> Do you think I should expand a bit more on that text to anything more clear? > > Yes - the point is to explain how much you rely on some properties of ESP to > avoid replays and maintain ordering and explain that’s why some of the > typical reassembly issues aren’t relevant. But not all.. > >> >>>> There are a number of other tunnel considerations that should be addressed, >>>> again as discussed in draft-ietf-intarea-tunnels. These include: >> >> >>>> - The >>>> impact of tunnel traversal on the inner hopcount/TTL (there should be >>>> none, as >>>> per that doc; hopcount should be adjusted by routers, not tunnels) - >> >> This is covered by IPsec (https://tools.ietf.org/html/rfc4301#section-5.1.2 >> <https://tools.ietf.org/html/rfc4301#section-5.1.2> section 5.1.2.1 in >> particular). > > It should be noted as how that impacts the methods of this doc. > >>>> Impact of errors in the tunnel on the ingress >> >> What would you suggest saying about this? Broadly I'm thinking "errors in >> the tunnel will affect inner packet delivery?" Seems a bit obvious so I >> think I may be missing what your after. > > You should describe how you expect ICMP errors arriving at the ingress to be > handled when they arise because of a packet traversing the tunnel. If it’s > “how ESP handles it”, fine, but mention that. > >>>> - Specification of the >>>> EMTU_R of the tunnel itself, and how that is determined - >> >> There is no maximum, all IP packet sizes are supported. :) > > OK, then mention that. It’s different from the EMTU_R of ESP, for example. > >>>> What the >>>> ingress should do if an incoming packet exceeds EMTU_R - It should be >>>> noted that this is a unicast tunnel - What you expect if there are >>>> multiple paths between the tunnel ingress and egress - Does the >>>> tunnel >>>> itself have a flow ID? (if the outer packet is IPv6) If so, is it fixed or >>>> intended to vary arbitrarily (and if so, how)? - If the outer packet >>>> is >>>> IPv4, do you expect to use DF=1? If not, how are you handling ID issues in >>>> RFC >>>> 6864? If so, it might be useful to add a reminder that the ID can be >>>> anything >>>> (including constant, which may be useful in avoiding a covert channel). >> >> We inherit these from the base IPsec/ESP tunnel mechanism that we use. > > Some of it you do inherit, but others you do not (as you note above). They > all need to be addressed. > > I.e., you’re potentially putting multiple IP packets inside one tunnel > packet; what does the header of the tunnel packet look like? You can’t simply > say “do what ESP does” because ESP allows only one IP packet as payload. > I.e., see Sec 5.1.2.1 - all those values “copied from the inner packet” - how > do they work when you have more than one packet and the values vary across > those payloads?? > > That’s the point here - you can definitely say “do what ESP does” when that’s > enough, but it’s clearly not. The ways in which you differ need to be spelled > out explicitly. > > Joe > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org <mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
