HI, Christian, I’m not aware that it’s possible for me to do this. It might be the transport chairs who do.
Joe > On Jan 5, 2021, at 1:36 AM, Christian Hopps <cho...@chopps.org> wrote: > > 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 >> <mailto: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 >>> <https://www.ietf.org/mailman/listinfo/tsv-art> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org <mailto:IPsec@ietf.org> >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > Tsv-art mailing list > tsv-...@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
