Subject: Re: [IPsec] [Tsv-art] Tsvart early review of draft-ietf-ipsecme-iptfs-03

From: Christian Hopps <[email-masked]>
Date: Tue, 5 Jan 2021 04:36:48 -0500

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 <[email-masked]> wrote:
> 
> Looks good - thanks.
> 
> Joe
> 
>> On Dec 19, 2020, at 8:44 PM, Christian Hopps <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 
>>> 
>>>> On Dec 19, 2020, at 2:16 PM, Christian Hopps <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Dec 4, 2020, at 3:14 AM, Christian Hopps <[email-masked] <mailto:[email-masked]>> 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
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
>> _______________________________________________
>> Tsv-art mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/tsv-art
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Joseph Touch <[email-masked]>
Date: Tue, 5 Jan 2021 08:10:20 -0800

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 <[email-masked]> wrote:
> 
> Hi Joe,
> 
>> On Dec 23, 2020, at 5:33 PM, Joseph Touch <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Looks good - thanks.
>> 
>> Joe
>> 
>>> https://www.ietf.org/mailman/listinfo/tsv-art <https://www.ietf.org/mailman/listinfo/tsv-art>
>> 
> [email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 6 Jan 2021 22:44:02 +0200

> I’m not aware that it’s possible for me to do this. It might be the

That is not normally done during the reviews. If the reviewer is happy
with the changes authors have done, then thats it. The document will
get rereviewed during the last call and telechat times also (at least
in most review teams), and the original reviewer will have option to
comment it again.

Area directors usually check the original review, and the reply thread
for it and then decide whether everything was covered or not...

Of course every review team has their own way of doing things, and I
do not know exactly what TSVART does.
-- 
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Jan 2021 09:51:27 +0000

Hi,

First of all thanks to the WG chairs for the request and Joe for the review. It
is much better to catch things earlier as it is often less disruptiove for the
WG to deal with the feedback at this stage. 

So I don't see any way the reviewer can change their review ones it has been
posted. The datatracker currently only tracks the review, not the resolution of
the review. 

However, as this is an early review and that is directly visible I don't think
this is an issue. Also, it is fairly likely that you will get a new TSVART
review when you do the IETF last call and then you will have review that I guess
will have a Ready. And as Tero says, we ADs follow up our own review team
reviews and check where the discussion went in preparation for balloting. So theconcluding discussion resolve the review. 

Cheers

Magnus