Hi Joe, Could you also clear the not-ready mark in the datatracker?
Thanks, Chris. > On Dec 23, 2020, at 5:33 PM, Joseph Touch <to...@strayalpha.com> wrote: > > Looks good - thanks. > > Joe > >> On Dec 19, 2020, at 8:44 PM, Christian Hopps <cho...@chopps.org >> <mailto:cho...@chopps.org>> wrote: >> >> 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 >>> <mailto: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> >> _______________________________________________ >> Tsv-art mailing list >> tsv-...@ietf.org <mailto:tsv-...@ietf.org> >> https://www.ietf.org/mailman/listinfo/tsv-art > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > 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
