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

Joseph Touch <touch@strayalpha.com> Tue, 05 January 2021 16:10 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BF53A0DE4; Tue, 5 Jan 2021 08:10:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwfO3ymnFKuR; Tue, 5 Jan 2021 08:10:35 -0800 (PST)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A253A0E44; Tue, 5 Jan 2021 08:10:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Mp3MJVNrfJ/ihWVUJCx6b4aHhPqry0YP2QudHr00Dc4=; b=gT1qoKEw3HLChA1COHEnNZpEJ eAnsbop121/QX0CCiugkx3ZlqTkHbRuU+nwsjgY97N8msHmQAJSKdNjqitiqJIwkxBdO0ngUKXYPs eBwxQtclGftVnUYGLvt45WpaQMSfgohQSUzZgJWKfRn7s+rSm1Xt18mM9VHWY8hfrmk7S8HzFa+Vm vITXQrXOSqWyq9wcOTsUU+BEg8SrTGXb/G9G/2SjoM6uYrP16HOjN+4bPH+cyaI7ZZEdqALKXh/nP 38soIy1f9Vbd+Yj8GhT0kTQPD/LNx/ArcnghOkk7sfx+VCGUGoWY/gxomXlGjLxmVrMbCq3Gq3TIi RLrvWCG5Q==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:57297 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <touch@strayalpha.com>) id 1kwoub-001Yp3-E4; Tue, 05 Jan 2021 11:10:26 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_3DCC034D-9FC5-47A5-BC09-58A244DB31FC"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <984DE126-29BC-443E-ABA6-A08A501B4FA5@chopps.org>
Date: Tue, 5 Jan 2021 08:10:20 -0800
Cc: ipsec@ietf.org, tsv-art <tsv-art@ietf.org>, draft-ietf-ipsecme-iptfs.all@ietf.org
Message-Id: <75B1875C-3E5C-481E-9100-B7D7B10A24EA@strayalpha.com>
References: <160706317241.25013.15326204319913211090@ietfa.amsl.com> <559B100B-4BC2-4E95-AFF8-95BBAE0BDAC8@chopps.org> <663120BF-01DA-449A-911D-EBD17EFBE729@chopps.org> <6D0D5787-F5F2-421F-89BA-F56647D545BF@strayalpha.com> <F95E3436-97DE-4EB5-AD15-99C0B054A365@chopps.org> <2574222A-BB85-4F4B-AEC7-7E5BB7FE45CC@strayalpha.com> <984DE126-29BC-443E-ABA6-A08A501B4FA5@chopps.org>
To: Christian Hopps <chopps@chopps.org>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/4Solv7ZsDYVtbcV8xnA7lKyHKBg>
Subject: Re: [Tsv-art] [IPsec] Tsvart early review of draft-ietf-ipsecme-iptfs-03
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jan 2021 16:10:38 -0000

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 <chopps@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 <touch@strayalpha.com <mailto:touch@strayalpha.com>> wrote:
>> 
>> Looks good - thanks.
>> 
>> Joe
>> 
>>> On Dec 19, 2020, at 8:44 PM, Christian Hopps <chopps@chopps.org <mailto:chopps@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 <touch@strayalpha.com <mailto:touch@strayalpha.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Dec 19, 2020, at 2:16 PM, Christian Hopps <chopps@chopps.org <mailto:chopps@chopps.org>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Dec 4, 2020, at 3:14 AM, Christian Hopps <chopps@chopps.org <mailto:chopps@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-art@ietf.org <mailto:Tsv-art@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-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art