Looks good - thanks. Joe
> On Dec 19, 2020, at 8:44 PM, Christian Hopps <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 > https://www.ietf.org/mailman/listinfo/tsv-art
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
