From nobody Tue Jan 5 01:36:54 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32E23A07F4; Tue, 5 Jan 2021 01:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Xm0xncPxo9oA; Tue, 5 Jan 2021 01:36:50 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 966333A07F0; Tue, 5 Jan 2021 01:36:50 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id D0A91601E3; Tue, 5 Jan 2021 09:36:49 +0000 (UTC) From: Christian Hopps Message-Id: <984DE126-29BC-443E-ABA6-A08A501B4FA5@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_9540A5B7-E496-444B-9D0D-7BF004940696"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 5 Jan 2021 04:36:48 -0500 In-Reply-To: <2574222A-BB85-4F4B-AEC7-7E5BB7FE45CC@strayalpha.com> Cc: Christian Hopps , ipsec@ietf.org, tsv-art , draft-ietf-ipsecme-iptfs.all@ietf.org To: Joseph Touch 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> <2574222A-BB85-4F4B-AEC7-7E5BB7FE45CC@strayalpha.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [IPsec] [Tsv-art] Tsvart early review of draft-ietf-ipsecme-iptfs-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 09:36:53 -0000 --Apple-Mail=_9540A5B7-E496-444B-9D0D-7BF004940696 Content-Type: multipart/alternative; boundary="Apple-Mail=_E5C4DDC8-7F24-4351-A459-BE85B4BE2E51" --Apple-Mail=_E5C4DDC8-7F24-4351-A459-BE85B4BE2E51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = wrote: >=20 > Looks good - thanks. >=20 > Joe >=20 >> On Dec 19, 2020, at 8:44 PM, Christian Hopps > wrote: >>=20 >> Hi Joe, >>=20 >> 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. >>=20 >> New: https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-05 = >> Changes: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-iptfs-05 = >>=20 >> Thanks, >> Chris. >>=20 >>> On Dec 19, 2020, at 7:57 PM, Joseph Touch > wrote: >>>=20 >>>=20 >>>=20 >>>> On Dec 19, 2020, at 2:16 PM, Christian Hopps > wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On Dec 4, 2020, at 3:14 AM, Christian Hopps > wrote: >>>>=20 >>>> 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). >>>=20 >>> It=E2=80=99s the ways in which you differ that need to be addressed. >>>=20 >>>> "IP-TFS never IP fragments the inner packets and the inner packets = will not affect the fragmentation of the outer encapsulation packets." >>>=20 >>> It doesn=E2=80=99t IP fragment, but it does fragment. There are = still fragmentation and reassembly considerations as a result. >>>=20 >>>> Do you think I should expand a bit more on that text to anything = more clear? >>>=20 >>> Yes - the point is to explain how much you rely on some properties = of ESP to avoid replays and maintain ordering and explain that=E2=80=99s = why some of the typical reassembly issues aren=E2=80=99t relevant. But = not all.. >>>=20 >>>>=20 >>>>>> There are a number of other tunnel considerations that should be = addressed, >>>>>> again as discussed in draft-ietf-intarea-tunnels. These include: >>>>=20 >>>>=20 >>>>>> - 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) - >>>>=20 >>>> This is covered by IPsec = (https://tools.ietf.org/html/rfc4301#section-5.1.2 = section 5.1.2.1 in = particular). >>>=20 >>> It should be noted as how that impacts the methods of this doc. >>>=20 >>>>>> Impact of errors in the tunnel on the ingress >>>>=20 >>>> 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. >>>=20 >>> 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=E2=80=99s =E2=80=9Chow ESP handles it=E2=80=9D, fine, but = mention that. >>>=20 >>>>>> - Specification of the >>>>>> EMTU_R of the tunnel itself, and how that is determined - >>>>=20 >>>> There is no maximum, all IP packet sizes are supported. :) >>>=20 >>> OK, then mention that. It=E2=80=99s different from the EMTU_R of = ESP, for example. >>>=20 >>>>>> 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=3D1? 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). >>>>=20 >>>> We inherit these from the base IPsec/ESP tunnel mechanism that we = use. >>>=20 >>> Some of it you do inherit, but others you do not (as you note = above). They all need to be addressed. >>>=20 >>> I.e., you=E2=80=99re potentially putting multiple IP packets inside = one tunnel packet; what does the header of the tunnel packet look like? = You can=E2=80=99t simply say =E2=80=9Cdo what ESP does=E2=80=9D because = ESP allows only one IP packet as payload. I.e., see Sec 5.1.2.1 - all = those values =E2=80=9Ccopied from the inner packet=E2=80=9D - how do = they work when you have more than one packet and the values vary across = those payloads?? >>>=20 >>> That=E2=80=99s the point here - you can definitely say =E2=80=9Cdo = what ESP does=E2=80=9D when that=E2=80=99s enough, but it=E2=80=99s = clearly not. The ways in which you differ need to be spelled out = explicitly. >>>=20 >>> Joe >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> 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 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_E5C4DDC8-7F24-4351-A459-BE85B4BE2E51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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> wrote:

Looks good - = thanks.

Joe

On Dec 19, 2020, at 8:44 PM, Christian Hopps = <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
Changes: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-iptfs-05=

Thanks,
Chris.

On Dec 19, 2020, at 7:57 PM, Joseph Touch <touch@strayalpha.com> wrote:



On Dec 19, 2020, at 2:16 PM, = Christian Hopps <chopps@chopps.org> wrote:



On Dec = 4, 2020, at 3:14 AM, Christian Hopps <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=E2=80=99s 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=E2=80=99t 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=E2=80=99s why some of the typical reassembly = issues aren=E2=80=99t 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 sect= ion 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=E2=80=99s =E2=80=9Chow ESP handles = it=E2=80=9D, 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=E2=80=99s 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=3D1? 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=E2=80=99re potentially putting multiple IP packets inside one tunnel = packet; what does the header of the tunnel packet look like? You can=E2=80= =99t simply say =E2=80=9Cdo what ESP does=E2=80=9D because ESP allows = only one IP packet as payload. I.e., see Sec 5.1.2.1 - all those values = =E2=80=9Ccopied from the inner packet=E2=80=9D - how do they work when = you have more than one packet and the values vary across those = payloads??

That=E2=80=99s the point here - you = can definitely say =E2=80=9Cdo what ESP does=E2=80=9D when that=E2=80=99s = enough, but it=E2=80=99s clearly not. The ways in which you differ need = to be spelled out explicitly.

Joe

_______________________________________________
IPsec mailing list
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

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_E5C4DDC8-7F24-4351-A459-BE85B4BE2E51-- --Apple-Mail=_9540A5B7-E496-444B-9D0D-7BF004940696 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl/0MzAACgkQLh2DDte4 MCVE5Q//eu5JSoXBzC9TGFsAZQDrwal6zwE19N4HHletMs9bz0P+EHOC/3AgAkz5 d6rzzhSIWjc9Iu2dwtjESfzHh9Uip7Pe6nJaxNRg2cr4iFZyQuqcbHzOiAN5dpT8 Q9gIxVLwr7El6/ZC0pE5clGInjroSLh32BsFDvuGi/UNwIgLa8h+JkwyCpoiHxoI Wi+7YVe+10gOC2L9neOQCPZsNaLGZX8znMl7+27rEYU7m3xDVSHM5ghlA0e/G61g B/fM0ojK8sud2146Zt7GIBkjcDlwecUf3VBMTec7NaIQn2yHFRYodv1jAIQCk2Dq 5N4ZBEyJ127hgCekGejaLtD+pwmB7I4MB56BvfzZ7+HpQ//CkXxytAvWhWxPXIdY euZ1qn07oyN3TII0jOX7dT7gQFBzp1WLLlZrhn/HV1UFQco97+2+N1YoTUn8dIaZ +rxjqCdDv2+u+WACPG5IAmhvtBk0vkW9qAL+xckynYUdnfYuHpiHi8Mmxk6Gj1ni h4Sw82hsOonwJWaqtHqPJNGb+FgS4x8JU5DkREHuUb8m3lrjkcS+S8HLh1cO10Ig GCKu90W0/8BqUBWTxn8kSMKC9qVSbVL/2yRDahA2OTZ2PpnAv+D8jv/jKVAScOhR Vt/CEbDsO93TlznrJOREVvkBvlmKLjpdogOAk9qv+Hmta4/pJRk= =IMB+ -----END PGP SIGNATURE----- --Apple-Mail=_9540A5B7-E496-444B-9D0D-7BF004940696-- From nobody Tue Jan 5 01:37:43 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BF63A0657; Tue, 5 Jan 2021 01:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9HSm6mN0bapH; Tue, 5 Jan 2021 01:37:40 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 533183A0553; Tue, 5 Jan 2021 01:37:40 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id D54C6601E3; Tue, 5 Jan 2021 09:37:39 +0000 (UTC) From: Christian Hopps Content-Type: multipart/signed; boundary="Apple-Mail=_36F0DF75-C6FE-4E69-880C-C1166CDB19A2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Message-Id: Date: Tue, 5 Jan 2021 04:37:39 -0500 Cc: Christian Hopps , ipsec@ietf.org To: ipsecme-chairs@ietf.org X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: [IPsec] IP-TFS drafts calls. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 09:37:42 -0000 --Apple-Mail=_36F0DF75-C6FE-4E69-880C-C1166CDB19A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Now that the IP-TFS draft has also completed its transport area review, = can we start a WGLC on it? https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ Also, as per the last IETF meeting, can we please start an WG adoption = call on the supporting YANG draft? https://datatracker.ietf.org/doc/draft-fedyk-ipsecme-yang-iptfs/ Thanks, Chris. --Apple-Mail=_36F0DF75-C6FE-4E69-880C-C1166CDB19A2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl/0M2MACgkQLh2DDte4 MCWIow//cTCiiWsCiBHiK+1C6MH+FEQgPfNkNyNsNAR1pSTlKwhkR73rbyNxMGiU BSPjeaoKCu4abMOiwpC/OOVSOCF5j+fA0O6upOa28samZ06ZRKpuJ/eBWqKfT64i vLC1UOMpqqVMGntYAnqJCZwaAAHs2GwYlpJRN69aoRnwUp4IsbOBtJvg4BoQLwJO Gi+b/jTAfx4n/q/2aoYcYwElrbn+X7xXfeyI4E4nCETeNxePT+FcAp+Csn8LhiIy K8v4MzTp6jD6hmIv4IIwAWS2grKo95anuBZUiA1uz0M99iwDkIwzqskOqnPSuMLe FfhQtPZwbzppJSnMtOTzD/5PJQwmhV1DT2SwCqJlwIC1i2vEHWhCe9qEa2DdsF62 nEewuCtytUAgAe7uxXqx131O3KtpvwMrVO+JTLNNrnKkip4F6Gsaym+6Kre+wX51 rPCQVxVOYeKwSS85uscVAhNnGFyYxgDFrzrnCLoEJcGzAEG9iW+iCbxHv+s1tuK6 J+mS/mr+bWjy5a+ISWFFh1CvPStxjYn5CYtnx1mo6VyTzrpNTKR0OEFUu5x+OGGm FMaOHhyctABQYL92sDX8MJD0xNrdvUTb09+K3SmUqzC4fYuG4PxCMbkMoCMigzYd GTQDrOJWoBp8Mz5noNWg12UikbuJ3CWOsL3PFWLCBGBmZre/3XM= =fxg7 -----END PGP SIGNATURE----- --Apple-Mail=_36F0DF75-C6FE-4E69-880C-C1166CDB19A2-- From nobody Tue Jan 5 08:10:43 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@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 ) 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 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 , 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> <2574222A-BB85-4F4B-AEC7-7E5BB7FE45CC@strayalpha.com> <984DE126-29BC-443E-ABA6-A08A501B4FA5@chopps.org> To: Christian Hopps 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: Subject: Re: [IPsec] [Tsv-art] Tsvart early review of draft-ietf-ipsecme-iptfs-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 16:10:38 -0000 --Apple-Mail=_3DCC034D-9FC5-47A5-BC09-58A244DB31FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 HI, Christian, I=E2=80=99m not aware that it=E2=80=99s 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 wrote: >=20 > Hi Joe, >=20 > Could you also clear the not-ready mark in the datatracker? >=20 > Thanks, > Chris. >=20 >> On Dec 23, 2020, at 5:33 PM, Joseph Touch > wrote: >>=20 >> Looks good - thanks. >>=20 >> Joe >>=20 >>> On Dec 19, 2020, at 8:44 PM, Christian Hopps > wrote: >>>=20 >>> Hi Joe, >>>=20 >>> 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. >>>=20 >>> New: https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-05 = >>> Changes: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-iptfs-05 = >>>=20 >>> Thanks, >>> Chris. >>>=20 >>>> On Dec 19, 2020, at 7:57 PM, Joseph Touch > wrote: >>>>=20 >>>>=20 >>>>=20 >>>>> On Dec 19, 2020, at 2:16 PM, Christian Hopps > wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On Dec 4, 2020, at 3:14 AM, Christian Hopps > wrote: >>>>>=20 >>>>> 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). >>>>=20 >>>> It=E2=80=99s the ways in which you differ that need to be = addressed. >>>>=20 >>>>> "IP-TFS never IP fragments the inner packets and the inner packets = will not affect the fragmentation of the outer encapsulation packets." >>>>=20 >>>> It doesn=E2=80=99t IP fragment, but it does fragment. There are = still fragmentation and reassembly considerations as a result. >>>>=20 >>>>> Do you think I should expand a bit more on that text to anything = more clear? >>>>=20 >>>> Yes - the point is to explain how much you rely on some properties = of ESP to avoid replays and maintain ordering and explain that=E2=80=99s = why some of the typical reassembly issues aren=E2=80=99t relevant. But = not all.. >>>>=20 >>>>>=20 >>>>>>> There are a number of other tunnel considerations that should be = addressed, >>>>>>> again as discussed in draft-ietf-intarea-tunnels. These include: >>>>>=20 >>>>>=20 >>>>>>> - 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) - >>>>>=20 >>>>> This is covered by IPsec = (https://tools.ietf.org/html/rfc4301#section-5.1.2 = section 5.1.2.1 in = particular). >>>>=20 >>>> It should be noted as how that impacts the methods of this doc. >>>>=20 >>>>>>> Impact of errors in the tunnel on the ingress >>>>>=20 >>>>> 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. >>>>=20 >>>> 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=E2=80=99s =E2=80=9Chow ESP handles it=E2=80=9D, fine, but = mention that. >>>>=20 >>>>>>> - Specification of the >>>>>>> EMTU_R of the tunnel itself, and how that is determined - >>>>>=20 >>>>> There is no maximum, all IP packet sizes are supported. :) >>>>=20 >>>> OK, then mention that. It=E2=80=99s different from the EMTU_R of = ESP, for example. >>>>=20 >>>>>>> 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=3D1? 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). >>>>>=20 >>>>> We inherit these from the base IPsec/ESP tunnel mechanism that we = use. >>>>=20 >>>> Some of it you do inherit, but others you do not (as you note = above). They all need to be addressed. >>>>=20 >>>> I.e., you=E2=80=99re potentially putting multiple IP packets inside = one tunnel packet; what does the header of the tunnel packet look like? = You can=E2=80=99t simply say =E2=80=9Cdo what ESP does=E2=80=9D because = ESP allows only one IP packet as payload. I.e., see Sec 5.1.2.1 - all = those values =E2=80=9Ccopied from the inner packet=E2=80=9D - how do = they work when you have more than one packet and the values vary across = those payloads?? >>>>=20 >>>> That=E2=80=99s the point here - you can definitely say =E2=80=9Cdo = what ESP does=E2=80=9D when that=E2=80=99s enough, but it=E2=80=99s = clearly not. The ways in which you differ need to be spelled out = explicitly. >>>>=20 >>>> Joe >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> 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 = >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art --Apple-Mail=_3DCC034D-9FC5-47A5-BC09-58A244DB31FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 HI, = Christian,

I=E2=80=99m= not aware that it=E2=80=99s 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> wrote:

Looks good - = thanks.

Joe

On Dec 19, 2020, at 8:44 PM, Christian Hopps = <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
Changes: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-iptfs-05=

Thanks,
Chris.

On Dec 19, 2020, at 7:57 PM, Joseph Touch <touch@strayalpha.com> wrote:



On Dec 19, 2020, at 2:16 PM, = Christian Hopps <chopps@chopps.org> wrote:



On Dec = 4, 2020, at 3:14 AM, Christian Hopps <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=E2=80=99s 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=E2=80=99t 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=E2=80=99s why some of the typical reassembly = issues aren=E2=80=99t 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 sect= ion 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=E2=80=99s =E2=80=9Chow ESP handles = it=E2=80=9D, 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=E2=80=99s 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=3D1? 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=E2=80=99re potentially putting multiple IP packets inside one tunnel = packet; what does the header of the tunnel packet look like? You can=E2=80= =99t simply say =E2=80=9Cdo what ESP does=E2=80=9D because ESP allows = only one IP packet as payload. I.e., see Sec 5.1.2.1 - all those values = =E2=80=9Ccopied from the inner packet=E2=80=9D - how do they work when = you have more than one packet and the values vary across those = payloads??

That=E2=80=99s the point here - you = can definitely say =E2=80=9Cdo what ESP does=E2=80=9D when that=E2=80=99s = enough, but it=E2=80=99s clearly not. The ways in which you differ need = to be spelled out explicitly.

Joe

_______________________________________________
IPsec mailing list
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

_______________________________________________
IPsec mailing list
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

= --Apple-Mail=_3DCC034D-9FC5-47A5-BC09-58A244DB31FC-- From nobody Wed Jan 6 12:44:18 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613853A0FFB; Wed, 6 Jan 2021 12:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 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, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 2qjCMQA0akwW; Wed, 6 Jan 2021 12:44:10 -0800 (PST) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (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 0C8B33A0E15; Wed, 6 Jan 2021 12:44:08 -0800 (PST) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 9D0041B001C6; Wed, 6 Jan 2021 22:44:03 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1609965843; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EUlw6Ssxtpz474dqh7Kqr3pMj8fyUui+DVXL1r3urGc=; b=Qlu8iVc17KetW4Jw52Hr6j9a9GZN3wjYaqUKvR2Mx0j8Gb8u5TousWO5V3Vi9U32yiLGag dXnyytr1V9KmPXUy+o+1Wa/dcK5Jsh6+qLLtgYEl5Ne8sUmr/aTpzQ4joh1p0//RZpc1gB cKqLMkX4gZEyD6F0J92zhMKA+Bm7IGrBq0SyxBWEapEosTDS9M/iZgKJJ38HPmAx4DejuG wOCrembStkpkCsINjUeUw0Fz8dvC7wdKxidfV6qyUNg5G/31GmMu+4rLI99aXM30+6K+RB R8O30I0NMM9PMg2bKtBrMchKOEFbye70RUAymj5DwWCEffxokgxpCxBEx4Srjw== Received: by fireball.acr.fi (Postfix, from userid 15204) id B2DA025C107B; Wed, 6 Jan 2021 22:44:02 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24566.8466.701001.422127@fireball.acr.fi> Date: Wed, 6 Jan 2021 22:44:02 +0200 From: Tero Kivinen To: Joseph Touch Cc: Christian Hopps , ipsec@ietf.org, tsv-art , draft-ietf-ipsecme-iptfs.all@ietf.org In-Reply-To: <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> <2574222A-BB85-4F4B-AEC7-7E5BB7FE45CC@strayalpha.com> <984DE126-29BC-443E-ABA6-A08A501B4FA5@chopps.org> <75B1875C-3E5C-481E-9100-B7D7B10A24EA@strayalpha.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1609965843; a=rsa-sha256; cv=none; b=JTXwqiDqRPZ3jzifY50+0u3MMBRS6swpa6AdiId52V7QMBfe3Y1nT/yEe8dQy6SFkF3UCB 3VHl11521Ft7VKqxzwJIEiGRGkfKgo3j+Kj86t80Nz4APzub9qCY6QxLNvhjevUn9harI0 ntd7PNNQ33Jrvebdfk5LquB88bN2FIjd0KPNR7auuF7pqvS4MSPNnSYA+baMFjkJu/iFbp 16GRFgdWGr3DXtyIEKmmWE5ofMsMrEcxziOgFAhFKtne5LdEM2ef391ytf3ShpI4nRAS0U KegwBfXDUH6lIaMljNAxnQ/tWoFTDCd0MyxRL1cdioDBf7mRsjPSz+Abn9vrXQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1609965843; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EUlw6Ssxtpz474dqh7Kqr3pMj8fyUui+DVXL1r3urGc=; b=NwoP/9MN6Ilmz2gnAUBIDFL7f9HTkiInV5Fs+Dshu5pf1JkK+1qneqjEfDzh9EIjYlmPz+ UxQKzh0SUSFSindtgUzJtk+IHcoeVGggL6nYo6XFkynwC4Fs+YrtQV29NqWdBjQDZQ+52W 0cvcA8hCaZQ11lCNWvyblyb2r+tQroavfsYtnSI6qJCXwu1w3RsFJ91RnwEhSfeu7m2wKK dZ6c85AbZYcKWMCA3a/NaSj0RfS51APEdWkhLXLG51/KAe5AF3PaoS69mz1m0Is680lGTg 6lIKxtnpDMGkDX/ZTmr1x6C02ktSB8OYiUPvfmbMxoHd2OxzakMfTGMw5+2f+A== Archived-At: Subject: Re: [IPsec] [Tsv-art] Tsvart early review of draft-ietf-ipsecme-iptfs-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 20:44:13 -0000 Joseph Touch writes: > I=E2=80=99m not aware that it=E2=80=99s possible for me to do this. I= t might be the > transport chairs who do. 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. --=20 kivinen@iki.fi From nobody Sun Jan 10 01:01:53 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5283A0EDA; Sun, 10 Jan 2021 01:01:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <161026930772.5785.18334810206819683423@ietfa.amsl.com> Date: Sun, 10 Jan 2021 01:01:47 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-multiple-ke-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 09:01:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Multiple Key Exchanges in IKEv2 Authors : C. Tjhai M. Tomlinson G. Bartlett S. Fluhrer D. Van Geest O. Garcia-Morchon Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-multiple-ke-02.txt Pages : 23 Date : 2021-01-10 Abstract: This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. The primary application of this feature in IKEv2 is the ability to perform one or more post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman key exchange, so that the resulting shared key is resistant against quantum computer attacks. Another possible application is the ability to combine several key exchanges in situations when no single key exchange algorithm is trusted by both initiator and responder. This document updates RFC7296 by renaming a transform type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this transform type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-02 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-multiple-ke-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-multiple-ke-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 11 01:51:46 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F3C3A09E1; Mon, 11 Jan 2021 01:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 64j21QB99lDd; Mon, 11 Jan 2021 01:51:32 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70079.outbound.protection.outlook.com [40.107.7.79]) (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 3748D3A09B5; Mon, 11 Jan 2021 01:51:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oGZZFzkkWNGQnS6wuRJWPB4xCmQuZE8G1Q5r31r6XGBks15KiL65pqPHTvTgZtAnZ5TrRrFk4VbYMWhWMZmNxA1PV9kxYevd3U1I2Z+4ILR6SH1az5O3PLCHsWvzVTBl1ydKd1IY3IZvBqK0CbRA3gQXIitdDMOF3MlUEJugNpxKZ+6e6e+7maD1LLYDQD+mUEzQtGqRdPESpkSFo/j0FjhVV23a0I7CYqsVUN3tn4Raeq0hPhMWec5AiVC+JEAdL43Ufn/aIFBNglcr4QIKWaJGUF7BX15VfS/KnmFdUr2V5aqf0TJjp+tLJz7IZ5zltk74P3FyZJMiILJOGAMvVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+3TlFKA9yojYMtpTN4za/CQsEVVs+mbhBOz7PDtqtcA=; b=KWB/Txi/9PNg3gcIZXesAMZPL8liBalfNzMLNYs1qmVMu1iTrXaj+t4wWURLzPkFMEQ9j3Wls917DFifx5Mna8PPryRey1hA56cbwZXD5VPE/JnsF63n/Q8msUrbLYUuQip6GKeLXPwOgWCWPXrj+SYifLN7GujWBsP80bFFkZho6xCgZgJVlBHxvTPu+G1MPlswlpi3uRv27DrIqQsyyFfRZ9k8dzMb7kVlqlZSVoi7qfM5atBea/RfWP62DyrxoMexiwijrf3qy3hHu0dtGtqp7a7twYtBAA5IrIEbgS0cQ5y2cIZ8WGfXysdFIkXLAiFKmETD4Z/zbd4Fivo1LQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+3TlFKA9yojYMtpTN4za/CQsEVVs+mbhBOz7PDtqtcA=; b=SsZ4jR1GQdNfcywWBocPQimSbrPr6GtxIOAbKoCFOtLKLU/RFs0gtwmv7OlmHcpTtR0kCjrJebn+Cj+GKqgtjkyWHWeognhoRl0lJGlSHtrNvZnAHHdG4jptUhjviVyL2QNEXCkNPyMXP+cGc7qcinPj36bQnP1CBUDdGN4Zi/8= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB4444.eurprd07.prod.outlook.com (2603:10a6:7:a0::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.5; Mon, 11 Jan 2021 09:51:27 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::8cd:496:65de:4ace%6]) with mapi id 15.20.3763.008; Mon, 11 Jan 2021 09:51:27 +0000 From: Magnus Westerlund To: "touch@strayalpha.com" , "kivinen@iki.fi" CC: "draft-ietf-ipsecme-iptfs.all@ietf.org" , "chopps@chopps.org" , "tsv-art@ietf.org" , "ipsec@ietf.org" Thread-Topic: [Tsv-art] [IPsec] Tsvart early review of draft-ietf-ipsecme-iptfs-03 Thread-Index: AQHW1lSy+U15NbkdTE2TMymHHyg5Sqn/KW0AgAA/eQCABeHLgIATlTkAgABt8wCAAd7OAIAHJVGA Date: Mon, 11 Jan 2021 09:51:27 +0000 Message-ID: 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> <2574222A-BB85-4F4B-AEC7-7E5BB7FE45CC@strayalpha.com> <984DE126-29BC-443E-ABA6-A08A501B4FA5@chopps.org> <75B1875C-3E5C-481E-9100-B7D7B10A24EA@strayalpha.com> <24566.8466.701001.422127@fireball.acr.fi> In-Reply-To: <24566.8466.701001.422127@fireball.acr.fi> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: strayalpha.com; dkim=none (message not signed) header.d=none;strayalpha.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.130.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 22708c74-78f0-4854-74cd-08d8b61676d1 x-ms-traffictypediagnostic: HE1PR07MB4444: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zr1fKqSFOred/JAcZ5RiSFG5vN+W3rHG5Aznq2E4WaKYUmg4WesZsSU7oSRkR5V1cPZhBRWxO7kSDHi7pmHhJJ+PhBVRIU1uJEg6CFHAhp3BK66/UPc0gpb0NqXe0ljFZkVZUqVk0xd+L79vo46aOzGTUK7Tq2w+xPy7gNR6N7pBKSoiXonyQlvDwo91uef4uoSwWVzSDcdo2vD6JrqHwaZp+51oK97fMRGaZOcPcQUCxbVC8jc1txaufkt34uJA1V7qpFH30d/t9zN/t8nmG4gIgI/3iqeAnIHsEHTY0mcIglYTQDTcd1V5aJw/xkE2Srmluk/0cTXEsxhqMlddIJtvSFtkycpt8z69XYP4IEO+zXSokS0wg/hSt1gP65xYjU1IFT971A+eFJTL5cJIqgYqGP51IGkPTrlnolJ8mpb+QK32ioMLsqsna2iLQ/zL x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(136003)(376002)(346002)(396003)(2906002)(71200400001)(86362001)(36756003)(186003)(44832011)(6486002)(8936002)(26005)(66476007)(6506007)(8676002)(64756008)(83380400001)(76116006)(66946007)(66446008)(66556008)(2616005)(110136005)(99936003)(478600001)(4326008)(5660300002)(54906003)(66616009)(316002)(6512007)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?OWU3NHlBdzM4aVREYlRWZzJjUlhYTzlkcHlSM1hXZUY2ZDNMeHpMR0ZsRmZn?= =?utf-8?B?NmZYNXpzaWQyRDJhT1lLRVlJMzl5aEwxblRWZVY2RnlqZTQ2T3o1K2NzQXVE?= =?utf-8?B?VloxWEpOR1M4RDJRQzZwZ0JTT2VGY3JwQ3hpVnpjSnVwa1lSeGtXS2w4Zlpx?= =?utf-8?B?bEhXWkdtR2dQTFoyTlhncHZwY1RPRXVIWEdKblRHODdFcGZKRWdWUzh1TFQ2?= =?utf-8?B?S2NDVzJEMlNxWnB6OVRFZFBxeWsxa1NaTitOQ3hnMXZNbDJYMlQrejJKOWZW?= =?utf-8?B?WkZBeFExUGtZRDd5M2ZFVHdSN2c5MDZaTVNCMVBSOW9hZGJndjVtakV4RStt?= =?utf-8?B?MG1xbWxpcnJoWDhQTjJLY01wUnVIb2RFTmx2VDE5RktxL0ZWaGh1TldISXFE?= =?utf-8?B?WmQyeTJJU05DVExTT1d3cVdveStDZzdnUzQwSmp3a0dZUURWejV1RnN3NVV4?= =?utf-8?B?Q082SUl6ejNob1FHQlAyMHN0WjA5ODBSNHgrV2MzY0M1d2VybFRmUTMzODJn?= =?utf-8?B?Y0lVY3pFSTBqUGR5aHRqNytyN290b3BjUE1qYWJFakJSWHMvb1NHNi9CRmEz?= =?utf-8?B?QXJjS0JUVCszRnUzWlZyYVU4ekJoS0hYNklxYXg5aTFTWGlMMmsvSGVQdVE2?= =?utf-8?B?Nzl6YkxwbGNTQ3ZtUDc3aXQvcnhmK3UzYlhuVERZUktMTE9LbUFxWGd1Znk4?= =?utf-8?B?S2lPekxoQzNWc05pRU91dWJDVXBpU0VJdzlPSHNCQ3B5SWI2dXdpZkNIdTZ6?= =?utf-8?B?SEkwaDIrU3lsU3l6T0NZZTlNWUFxZEIweDBuMmFRMTZXUGpyWHZqWHh6Z3BX?= =?utf-8?B?NHFlMERORzB0OFR0c0c2NFhOQmk4T1ZLS2FhNzBiRkFkcFY0SWEyQmo2TmVE?= =?utf-8?B?R3FwTy9ZdlVPRWtYVDdaRlZaWTBxekpmTnh1RHlMa0tDSVRNUnptbDU1MEY0?= =?utf-8?B?cUhRVHQ4YXpOa0ZvTHg3Mlh0aEFPamxhMzMrb3c2dmJzRmMrRVd3RmZIOUp3?= =?utf-8?B?WE81aGJGVUt3aWNtaGF1NEZPTkp0MzhmZHl3SFpQdjdEQS9nZ1BSUGNoM2hp?= =?utf-8?B?RS9Ea1V6dmkzVUx5djZUajMxb213bFdlUjNlMmlkNEJvTjIrdmVXZjRqTnRX?= =?utf-8?B?TGhjSFhqVS9JYTFiaTVpTndvcXZyT1E2VWhxSEZXc0tFUjZUMnRIOFd5Y3R0?= =?utf-8?B?Sk5EdEYyQXNoTWdPcjl1T0IyVm9yRzFoTGowM0VNbDZxa29rbTFRZkwvcS93?= =?utf-8?B?cjNCZXVmM0Zubm41c3RaNjY0bmE4b2tqcU81UHZpUmVvMVVLekxHNElhbHVv?= =?utf-8?Q?9MQC/vFikfWVS9D7YNcwKwbrFnLmj+pyS6?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-iC4Y5eXHz7r0MYsoCb9j" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 22708c74-78f0-4854-74cd-08d8b61676d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2021 09:51:27.0490 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FQjgFq3h0Ik91QT2q+yadE2dsDWwHFKC+pVA/+3DYagRX+Q0PCecC4kQGIw+xbL+aSTIgkeggVObqX9BA3aBX38aDTplALCmY4WKFW8CH4s= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4444 Archived-At: Subject: Re: [IPsec] [Tsv-art] Tsvart early review of draft-ietf-ipsecme-iptfs-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 09:51:42 -0000 --=-iC4Y5eXHz7r0MYsoCb9j Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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.=20 So I don't see any way the reviewer can change their review ones it has bee= n posted. The datatracker currently only tracks the review, not the resolutio= n of the review.=20 However, as this is an early review and that is directly visible I don't th= ink 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. S= o theconcluding discussion resolve the review.=20 Cheers Magnus On Wed, 2021-01-06 at 22:44 +0200, Tero Kivinen wrote: > Joseph Touch writes: > > I=E2=80=99m not aware that it=E2=80=99s possible for me to do this. It = might be the > > transport chairs who do. >=20 > 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. >=20 > Area directors usually check the original review, and the reply thread > for it and then decide whether everything was covered or not... >=20 > Of course every review team has their own way of doing things, and I > do not know exactly what TSVART does. --=-iC4Y5eXHz7r0MYsoCb9j Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCErYw ggX0MIID3KADAgECAg8BdlE9InYZOYLl1zGep4IwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMC U0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB IHYzMB4XDTIwMTIxMTA5NTg0OVoXDTIzMTIxMjA5NTg0OVowXjERMA8GA1UECgwIRXJpY3Nzb24x GjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCIT6U9ddUp UCEryIA27xtF8WsRAIfc5jBavfu0OGDmwITYYRD2PaMEdEK+I4dqz0f6xcCrDnBk2Xj+JxjhaRkq TAifJZima9WE2JoI/uq8UsS2HJWlhspAwKx1osARgtRiMjRZZyyfiRZLbgXHWYpnTt3i9QsuX/uo 9oZFWpDCbZee4Il9uldsUcuBLZx2PyZvBvC8KCUaBXsZX6bwV7hssRVn+BgFCuEievJMx0khTRVh i9goObxu5Jl44RtwbZNYB1UE1IzRWEZw+b3cEvXiQjPl2e3ytMZSmhy+IaKmjxES6ODiuh51KAcm PZfZIaX2djmD76YGi+ETmnb8Xm3dAgMBAAGjggHEMIIBwDAfBgNVHSMEGDAWgBQcexmel5x2rCA9 2NzjkWrj2y2mUzAdBgNVHQ4EFgQUICO/88T0EQvEUm5+HVt/d9Mm+Z8wDgYDVR0PAQH/BAQDAgWg MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMCkGA1UdEQQiMCCBHm1hZ251cy53ZXN0ZXJs dW5kQGVyaWNzc29uLmNvbTBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlh LmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3Qu dGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2Vy aWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwDQYJKoZIhvcNAQELBQADggIBANRZXQy+lUW97uaL uApOixnDKLpUoz+N/5Owd/9illmbxQDEY1/pPs4KJSvw88p+F3bmOzb+fLUNa6Mi/2Tw83FzEVmO 3RqzKtca+I9GDpRQ8oWL7hrUPJoNacidSZLmAP4L4kwHIhvGNX4f1c/oB4fAkP/xZsAAxYi7nKxd XA2n/KMWNkezyB9BSsD8ZOS4pWU8UaZjd5r0fzqM5zQbU4EPqHa8jFMSMz1UrYXPKKxl6E4WA3TE w1oLjcli0NWGQHyQ+3Kh7fe6zPoXfLd/2EQjr2o76ssgoqd2V1Mx5TRHdUyxjIMPEOVYpvcerNUB hEBkaOQ9FugYcMhMc8BF7nQZq+hsL/T7idg4gE2sEfNdK9RBf/EVH10GMrmbadqTycztD1gUL3dV Qxik4TCMxIctt9XqtTGHaMewZLQAXp/sHWlU/vmz9brcuzYQ9YVd5hTendGMUyGhWPV/KvxouKPK zdrGeEqUQCeBwWgQASQNOrpTzMJwZAV/Ww3ExQCjHvflvUQzVuU0sC6AEVkgqMATIXS6h6rjLL31 pjt2JV84XRjF5afYkcRIHTsrtcoWeFtOu/GpZNhtq+tde0QvnkSsjczMWU0gKk0hXBmXwEGUimuD Vq/Wvr0mr18d9mKA6xPNQOfn/VL5CWXa11OtOjj8WsTy3XUpyJ6dc9Z72TmKMIIF9DCCA9ygAwIB AgIPAXZRPSJ2GTmC5dcxnqeCMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQK DAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEy MTEwOTU4NDlaFw0yMzEyMTIwOTU4NDlaMF4xETAPBgNVBAoMCEVyaWNzc29uMRowGAYDVQQDDBFN YWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nz b24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAiE+lPXXVKVAhK8iANu8bRfFr EQCH3OYwWr37tDhg5sCE2GEQ9j2jBHRCviOHas9H+sXAqw5wZNl4/icY4WkZKkwInyWYpmvVhNia CP7qvFLEthyVpYbKQMCsdaLAEYLUYjI0WWcsn4kWS24Fx1mKZ07d4vULLl/7qPaGRVqQwm2XnuCJ fbpXbFHLgS2cdj8mbwbwvCglGgV7GV+m8Fe4bLEVZ/gYBQrhInryTMdJIU0VYYvYKDm8buSZeOEb cG2TWAdVBNSM0VhGcPm93BL14kIz5dnt8rTGUpocviGipo8REujg4roedSgHJj2X2SGl9nY5g++m BovhE5p2/F5t3QIDAQABo4IBxDCCAcAwHwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMw HQYDVR0OBBYEFCAjv/PE9BELxFJufh1bf3fTJvmfMA4GA1UdDwEB/wQEAwIFoDBVBgNVHSAETjBM MEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3Qu dGVsaWFzb25lcmEuY29tL0NQUzApBgNVHREEIjAggR5tYWdudXMud2VzdGVybHVuZEBlcmljc3Nv bi5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYzLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwgYIG CCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBI BggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMA0GCSqGSIb3DQEBCwUAA4ICAQDUWV0MvpVFve7mi7gKTosZwyi6VKM/ jf+TsHf/YpZZm8UAxGNf6T7OCiUr8PPKfhd25js2/ny1DWujIv9k8PNxcxFZjt0asyrXGviPRg6U UPKFi+4a1DyaDWnInUmS5gD+C+JMByIbxjV+H9XP6AeHwJD/8WbAAMWIu5ysXVwNp/yjFjZHs8gf QUrA/GTkuKVlPFGmY3ea9H86jOc0G1OBD6h2vIxTEjM9VK2FzyisZehOFgN0xMNaC43JYtDVhkB8 kPtyoe33usz6F3y3f9hEI69qO+rLIKKndldTMeU0R3VMsYyDDxDlWKb3HqzVAYRAZGjkPRboGHDI THPARe50GavobC/0+4nYOIBNrBHzXSvUQX/xFR9dBjK5m2nak8nM7Q9YFC93VUMYpOEwjMSHLbfV 6rUxh2jHsGS0AF6f7B1pVP75s/W63Ls2EPWFXeYU3p3RjFMhoVj1fyr8aLijys3axnhKlEAngcFo EAEkDTq6U8zCcGQFf1sNxMUAox735b1EM1blNLAugBFZIKjAEyF0uoeq4yy99aY7diVfOF0YxeWn 2JHESB07K7XKFnhbTrvxqWTYbavrXXtEL55ErI3MzFlNICpNIVwZl8BBlIprg1av1r69Jq9fHfZi gOsTzUDn5/1S+Qll2tdTrTo4/FrE8t11KcienXPWe9k5ijCCBsIwggSqoAMCAQICEFO4foPhnJko k7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3MTIxNjQ2WjBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs8t8AALhQ8qe7 2FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh /VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98M vWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmd vkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7 zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP 1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3s p0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25a EvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUU kBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCC AbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFz b25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1 c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1 c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6XnHasID3Y3OOR auPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBCwUAA4IC AQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZiObNHCZ7mmSNM Vek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7 m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HT CIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNM MbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7 DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPN mJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKa kDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i 0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+W kDGCAsowggLGAgEBMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdlE9InYZOYLl1zGep4IwDQYJYIZIAWUD BAIBBQCgggFBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDEx MTA5NTEyNVowLwYJKoZIhvcNAQkEMSIEIPqam96Gsw9VQFzKFGYLfWBfgtnTaWb0HzXV2M4lEdJF MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdlE9InYZOYLl1zGep4IwawYLKoZI hvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXZRPSJ2GTmC5dcxnqeCMA0GCSqGSIb3DQEB AQUABIIBAGOrS81EiYeOfOh/+oYO5av85spi+la5kJWGUPp9DjtWhbO2GtNhiKbzf68Ok/p74rjY MMQa1jcIr7JmK7ZsPXHwHxn8Ee0HM9LAIkb+oYA7qgKFHMjbtVnMeuVPlPbMZ/E6263sCX4YorFX 6WbhT8q6mU12oJS/mkuiC6ZDNPsPQjEzLTd4NF2ognzChJUQN6/5wEwLZZv52BuEsDsNxbesOzCV q8hlOyPoMXUd10oZi4ptjoDRhRzobFnhA5eoPbLu9sH5CcVKjB62OpzJVyrfkz11rlVF/UCQRtcS u0Q6Rd2Tv7j8gmVEQvir8lk9lu8p7LYV3bppEwFi7YCmyUUAAAAAAAA= --=-iC4Y5eXHz7r0MYsoCb9j-- From nobody Mon Jan 11 03:57:24 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1473D3A0BDC; Mon, 11 Jan 2021 03:57:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <161036623903.10425.16204152197124055278@ietfa.amsl.com> Date: Mon, 11 Jan 2021 03:57:19 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 11:57:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Group Key Management using IKEv2 Authors : Valery Smyslov Brian Weis Filename : draft-ietf-ipsecme-g-ikev2-02.txt Pages : 60 Date : 2021-01-11 Abstract: This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components require a Group Controller/Key Server to download IPsec group security associations to authorized members of a group. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-g-ikev2-02 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-g-ikev2-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 12 03:22:51 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAC73A1128 for ; Tue, 12 Jan 2021 03:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 R1bJc6juS6uA for ; Tue, 12 Jan 2021 03:22:49 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9883A1127 for ; Tue, 12 Jan 2021 03:22:48 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id u21so2466689lja.0 for ; Tue, 12 Jan 2021 03:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=F2Z57GqV/VCPfttk1OMtXBXNLXoPX9fRKlVjt1sN9yk=; b=TR2KwezBSWbBj78bG+U1inPQcUP7zoCCBodMH38NiuyVibVgdSxke5leq35neDSR8A XABli90wLPdxXNCcbHNYeujSpoK6dGiqu+rJxUGFZkmDofnCGnW/bz6K46t4mR/0nuiC weD4HPSPo3cm3ZtrRi6fWyLmwhIKfzPuJnpU8OptXjjopN0rwjx8bBsrPkajWPy8rqwp QYicroQrqMVy1JswAznzBguJiX1Sy71qd0IxLF0fal8Q7q1fyzNWlTxFDBq93+Mka0HJ +qBOfJ0+YLVI8ON3QAeTTEdALT7NcVqxHqGYndKmhCGkvxH96l8/cLKUZYL2F/Y6V7/3 1ssw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=F2Z57GqV/VCPfttk1OMtXBXNLXoPX9fRKlVjt1sN9yk=; b=YrbeHYH41fRLfTBc6c3hyMYkpmu4YV1Ew03TrRCGH3zjFehBZ8mdvUFM7x2zKzAHHJ p76roUDboxy4l1IaMGZTGiwTQrYSyXeIzVop3fay7BvJmin17klWTlycLuU4zzm2c6wL yLvd/U+Y/eRBlnz6oN31jpRx3N8aXzh5RZzC3dxknyUR03Wf9oxQjvC6uQw8Opt3nHyh FXo1uHhxGRHprcyLYXO21cDtDlKdRLoxNt8YyknsUaPLPItdI5NSHVZNwLyVEpctiuvk 162UNUrHScT9sJ+BoF3oTIzSOaC+fL2zrpZk8aN3at4d5QnFKnhy4E9V2/haHo3rM/Se ahlw== X-Gm-Message-State: AOAM533HbumHojAFzJGiJtWfrUpmbd2Xd8Vc0iDzzav6nt+wSq+iXgZv UyzVRxTfDptx2yHu7dm6m7261/D8IJ4= X-Google-Smtp-Source: ABdhPJyaptdA+NHaHD4Vx0bQ7UCWnMWKlnu5bEGFRfDOzyJXUWGpIA8P52idmFHHsDY/baUQINygZw== X-Received: by 2002:a2e:b4b3:: with SMTP id q19mr1720184ljm.121.1610450566362; Tue, 12 Jan 2021 03:22:46 -0800 (PST) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id z14sm313279ljc.41.2021.01.12.03.22.45 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2021 03:22:45 -0800 (PST) From: "Valery Smyslov" To: "IPsecME WG" References: <161026930788.5785.4505948873365460028@ietfa.amsl.com> In-Reply-To: <161026930788.5785.4505948873365460028@ietfa.amsl.com> Date: Tue, 12 Jan 2021 14:22:46 +0300 Message-ID: <0bef01d6e8d5$4104a5b0$c30df110$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFKR6RYgNduS45bJYBER4lIbmBmW6s9GhkA Content-Language: ru Archived-At: Subject: [IPsec] FW: New Version Notification for draft-ietf-ipsecme-ikev2-multiple-ke-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 11:22:51 -0000 Hi, we've published a new version of the draft. The only change is an = addition of a reference to draft-tjhai-ikev2-beyond-64k-limit. Regards, Valery. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Sunday, January 10, 2021 12:02 PM To: C. Tjhai; D. Van Geest; G. Bartlett; M. Tomlinson; O. = Garcia-Morchon; S. Fluhrer; Daniel Van Geest; Oscar Garcia-Morchon; = Scott Fluhrer; Valery Smyslov Subject: New Version Notification for = draft-ietf-ipsecme-ikev2-multiple-ke-02.txt A new version of I-D, draft-ietf-ipsecme-ikev2-multiple-ke-02.txt has been successfully submitted by C. Tjhai and posted to the IETF repository. Name: draft-ietf-ipsecme-ikev2-multiple-ke Revision: 02 Title: Multiple Key Exchanges in IKEv2 Document date: 2021-01-10 Group: ipsecme Pages: 23 URL: = https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-multiple-ke-02.t= xt Status: = https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/ Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-multiple-k= e Htmlized: = https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-multiple-ke-02 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ikev2-multiple-ke-= 02 Abstract: This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. The primary application of this feature in IKEv2 is the ability to perform one or more post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman key exchange, so that the resulting shared key is resistant against quantum computer attacks. Another possible application is the ability to combine several key exchanges in situations when no single key exchange algorithm is trusted by both initiator and responder. This document updates RFC7296 by renaming a transform type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method". It also renames an IANA registry for this transform type from "Transform Type 4 - Diffie- Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Jan 12 03:26:17 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BFF3A1135 for ; Tue, 12 Jan 2021 03:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QmDM9vmRc09H for ; Tue, 12 Jan 2021 03:26:15 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACD763A1128 for ; Tue, 12 Jan 2021 03:26:14 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id s26so2805916lfc.8 for ; Tue, 12 Jan 2021 03:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=eKTbdIyaly39hnAXZ91Hzc7XuzqzOhT8RJ/GnBSpf+w=; b=Ad2Rd1zIH1si24MZBLmPEaG11SGs7m9wMxhY1PWgKVv7ueT7xQtsLenIrurndYMcQN a+QogaOOo1KTVdOywOMZqtnIouYqoF/w3hiCBdMgqBV5LsdcmSCeKKXlV4k/2bbJ58vj cf6gBNlmb8LXu63UKg0eK/nnVLRBAvN23gJirEp59hyghEzWmu7vaET7gy1wh0Xu/5/q iaVD9ISlKZL7nS3SCr/Rpar0s6yWXwIaauMNK/Bpz4KX1vzExMfAlMK1a1y7a/xMhlCb 704d7i74fl3M3aa/pxVCE8RKJcFHVuArLiiDOUdeCpsoXFy1JngZVNkrbW4NJiwqkFSM +7kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=eKTbdIyaly39hnAXZ91Hzc7XuzqzOhT8RJ/GnBSpf+w=; b=gFG2BbngCJrB5bwzqfcElEWESIAKh6dLnKpKtDuCyUA53FjBme+M+fJ+D8TRIoIpZb 3m8bIQqngPbO84P9wFt8RYZnNZe0zIcyEagOhrTcX6cZP8P4vcDpcHljhABX8RsoTG4T X1PEYib19Ng0ol2WlixFVJjUzWPChL9TuiC5C4R2z7hDF8vO8mPCRQux/CzBLmX+Xw07 NJY2+Vm3HMeXm27ljolR7shf30iE36coiQKU0k4svEOWPBvXaidMUkr/wceR5H3JCVeD 7tWPByqWWAsgS5rXDt4hnxt9NT9y0rXKCqi59Yyqnsfbs9L6FL3KPO63o+qx/73KzT2o bteg== X-Gm-Message-State: AOAM531Cm1zSNibkyqY62Y/purfAotJxnKkN3yZ4hK8LRzJy5m8o61Y5 +Fisj3aaZZgmOWQIj6Rsh6bycb41fQw= X-Google-Smtp-Source: ABdhPJzDkBc1Kb1/W6JfjOent6fiu42h2fX9e8WqSZrQqjSeotv66/K/6sNWtV68grDrA9XNksz6kw== X-Received: by 2002:ac2:58f4:: with SMTP id v20mr2074191lfo.636.1610450772630; Tue, 12 Jan 2021 03:26:12 -0800 (PST) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id t9sm358180lff.45.2021.01.12.03.26.12 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2021 03:26:12 -0800 (PST) From: "Valery Smyslov" To: "IPsecME WG" References: <161036623921.10425.1288595129414296678@ietfa.amsl.com> In-Reply-To: <161036623921.10425.1288595129414296678@ietfa.amsl.com> Date: Tue, 12 Jan 2021 14:26:13 +0300 Message-ID: <0bf001d6e8d5$bc1d8e60$3458ab20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ6DeHxsjK7jHefxRlX6X/hb8VBIajdjsmQ Content-Language: ru Archived-At: Subject: [IPsec] FW: New Version Notification for draft-ietf-ipsecme-g-ikev2-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 11:26:17 -0000 Hi, we've published a new version of the draft. The changes are relatively minor - few clarifications are added. The draft still waits for reviews, which would be very welcome. Regards, Valery. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, January 11, 2021 2:57 PM To: Brian Weis; Valery Smyslov Subject: New Version Notification for draft-ietf-ipsecme-g-ikev2-02.txt A new version of I-D, draft-ietf-ipsecme-g-ikev2-02.txt has been successfully submitted by Valery Smyslov and posted to the IETF repository. Name: draft-ietf-ipsecme-g-ikev2 Revision: 02 Title: Group Key Management using IKEv2 Document date: 2021-01-11 Group: ipsecme Pages: 60 URL: https://www.ietf.org/archive/id/draft-ietf-ipsecme-g-ikev2-02.txt Status: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2 Htmlized: https://tools.ietf.org/html/draft-ietf-ipsecme-g-ikev2-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-g-ikev2-02 Abstract: This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components require a Group Controller/Key Server to download IPsec group security associations to authorized members of a group. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sat Jan 16 11:20:52 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F353A1964; Sat, 16 Jan 2021 11:20:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, kaduk@mit.edu, kivinen@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161082484983.22581.7581691167862926910@ietfa.amsl.com> Date: Sat, 16 Jan 2021 11:20:50 -0800 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 110 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2021 19:20:50 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: tls acme Technology Overlap: cfrg People who must be present: Yoav Nir Tero Kivinen Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jan 17 13:27:25 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989993A085E; Sun, 17 Jan 2021 13:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 1FDuOXwgojYM; Sun, 17 Jan 2021 13:27:21 -0800 (PST) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 DEA7F3A084A; Sun, 17 Jan 2021 13:27:19 -0800 (PST) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id DC4B420689; Sun, 17 Jan 2021 23:27:16 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1610918836; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=TJUrL//1lPf6aQtPvpav5mE8o86UG/znrRzQnYwxGik=; b=y1zLmTuxrpsw8PK58xUY6i/XkNjn/oSVBOqmZibOsrIaAPO9zoPdzZiajxYGOyxyMQglpB j2Fwm+BOXtJp0zIO/7s2uHkesZWCQXTLIGakxRlMitwvmlCqcN5WijlaAHtQR7DvVJE8N4 nOG/jQDsj5XutnHm/YAly3AQg3M/DU8= Received: by fireball.acr.fi (Postfix, from userid 15204) id D62D025C1106; Sun, 17 Jan 2021 23:27:14 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24580.43954.709072.153522@fireball.acr.fi> Date: Sun, 17 Jan 2021 23:27:14 +0200 From: Tero Kivinen To: ipsec@ietf.org, draft-ietf-ipsecme-iptfs@ietf.org CC: Joseph Touch X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 57 min X-Total-Time: 76 min ARC-Seal: i=1; s=meesny; d=iki.fi; t=1610918836; a=rsa-sha256; cv=none; b=RQx6TyfrEd0/E/VtaLXJW2BHOpB0KS0jI30dVfsufQDfKTvFi7Rd2916Ky8Vj7mTgLa6/u gq1dbVFbff2yv8g2DB8HLHxkN/8hevvCuNZQyoBaZhP/HSCmyUTNs2vKv4a6NFDc/axY3v yG5Aj07/SPY30QlT0SWWqROiDf2VKu0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1610918836; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=TJUrL//1lPf6aQtPvpav5mE8o86UG/znrRzQnYwxGik=; b=O2PEfQ+nfzp0qLiInK/D/yXdsaXCgzeNCFUoN6UhV+Aw4pwtUEGxFM62Gvda3BFR/DnR+j Gbib/6BeydbPs6uBME6fweyo/rvpVLP68/glX2SuGX524MLIdeFXexSzmX2sr6c82EFGmE f21DqjvupqJGbb/XYrHdIpms/v+ejx0= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] My review of the draft-ietf-ipsecme-iprfs-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 21:27:25 -0000 First, thanks for the Joe for very good TSV review for this draft. I am now going through this draft to see whether it is ready for WGLC, and while reviewing it I have some comments on it. On the other hand I think it is starting to get ready for WGLC... In section 2.2.3 fragmentation etc, the draft talks about replay protection, but in the ESP replay attack protection is optional, and does not need to be done by the receiver, altough the sequence number generation MUST be done by sender. Also normally in ESP seqeuence numbers are not required to be back to back, there could be cases where they would be incrementing by larger value, and cases where the sequence numbers are not sent out in order. This can happen for example if multiple encryption boards are used, and each of them have separate coordinated sequence number generation. This can also cause reordering in some cases. The draft now says that "sender MUST Send the inner-packet fragments back-to-back", which adds a new requirement for ESP. It might be good idea to add note, that says this changes requirement from RFC4303, which only requires that sequence numbers are incremented, not by how much (for example draft-ietf-lwig-minimal-esp proposes that in some enviroments it might be better to use time for sequence number generation so they do not need to store sequence number while sleeping). Section 2.2.3 does not change the replay protection parts, just talks about that similar method than what is used in the replay protection can be used for reassembly. This may cause issues if the ESP level does not do replay protection, but the reassembly code assumes it is done. The text also seems to indicate that the window sizes for the reassembly and replay protection could be different. If reassembly and replay windows are not same, I think the smaller one of them is used, as if replay window is smaller, then too old packets are dropped before they would reach the larger reassembly window, and same happens for other way around. I think we could just say that when using this detection of replays is mandatory and that replay window and the reassembly window are same. Also note, that increasing replay window size does not have that much effect on the memory consumption of the SA, but increasing reassembly window size does have. I.e., if the quite often used 1024 packet replay window size is matched with same sized reassembly window of 1024 * 1024 byte packets, that will mean each SA could consume up to 1 MB for reassembly window. Also even when the 2.2.3 says in that there is no need for timers, I disagree with that, as during rekey or other operations it might be possible that the traffic from the SA is moved to the newly created SA, and then few minutes later the old SA is deleted. Keeping the reassembly buffers for that long just because there is no incoming packets is just wasting data. In section 2.2.2 and 2.2.3.1 the draft tries to fill the packets to full, even when there would only be one byte fitting on the frame, and I think this is bad idea. I would think it would be better to say that if less than 5% (or some other fixed configurable amount) of the packet is available and the packet to be added would be fragmented, then packet is padded instead of fragmenting, and the packet to be added is moved to next outer packet. I think there is too much emphasis on not wasting the bandwidth and too much emphasis on the robustness of the protocol. Small amount of padding that will avoid fragmentation is much more desirable than not wasting few % of the bandwidth. In section 2.2.5 it says that ECN value is not mapped, because of constant-send-rate, but it leaves out the other part, i.e., if some device is sending inner data faster than the constant-send-rate then the IPTFS should set the ECN for inner packets when adding them to the aggregated frame, just to indicate this information to the other end. In section 2.2.7 the draft says there is no effective MTU, which is true, but the question is that should there be one? I mean even if the original sender will automatically detect that 63kB UDP packets go through without fragmentation that does not mean that it will be good idea to use 63kB packets as that will cause latency for all other packets sharing the same SA. I think it would be useful to be able to restrict the effective MTU of the tunnel. In section 2.3 why does the text say: In other words, an SA that has AGGFRAG_PAYLOAD enabled MUST NOT have non-AGGFRAG_PAYLOAD payloads such as IP (IP protocol 4), TCP transport (IP protocol 6), or ESP pad packets (protocol 59) intermixed with non-empty AGGFRAG_PAYLOAD payloads. why is that restriction with only non-empty AGGFRAG_PAYLOAD payloads? When can empty AGGFRAG_PAYLOAD used intermixed with other payloads? The rekeying of the SA is not specified fully. It does say that rekeying cannot change the USE_AGGFRAG information, but it does not say that rekeyed SA actually inherits the USE_AGGFRAG flag. It should explictly mention that. Also it does not mention whether frame is allowed to to be fragmented across the old and new SA. It should say that as sequence numbers are different for the SAs, the packet can never be fragmented so that part of it is in old SA, and part of it is in the newly created SA. In section 2.2.4 draft says: ESP payload length is equal to the AGGFRAG_PAYLOAD header length. This would indicate that this packet is not the same length than other frames. I think it would be better to say that this has just the AGGFRAG_PAYLOAD header, and then rest of the frame is padding. -- kivinen@iki.fi From nobody Sun Jan 17 13:34:55 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D903A08F4 for ; Sun, 17 Jan 2021 13:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 35MIDDb1Vv_z for ; Sun, 17 Jan 2021 13:34:50 -0800 (PST) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 8E1E03A08F9 for ; Sun, 17 Jan 2021 13:34:49 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id BE51A20593; Sun, 17 Jan 2021 23:34:47 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1610919287; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VJuOeeDSteTkfMNopFBRyzGkM7g1fui7EQCfFd1hGjE=; b=dyugQyOIfFO5KFYA7CMNCvXjPX99B6W4QSy9S1XsL9N7xTj5U0SU4tF9ti32i4hct/5GHM KFJRKl26Kry3MWW4bLSrrbnJPvLO9zqlla4XcZ0K0uJjRRTR5pBiIeXMvHIKTnd52UX2qz ur0SUw9b1YBOVc28NusweQf6EQQ+BS8= Received: by fireball.acr.fi (Postfix, from userid 15204) id 493BA25C1107; Sun, 17 Jan 2021 23:34:46 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24580.44406.245377.921032@fireball.acr.fi> Date: Sun, 17 Jan 2021 23:34:46 +0200 From: Tero Kivinen To: Christian Hopps Cc: ipsec@ietf.org In-Reply-To: References: X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 7 min ARC-Seal: i=1; s=meesny; d=iki.fi; t=1610919287; a=rsa-sha256; cv=none; b=errR/l1Umruyc54jJCFa2tSsV2YRSdy0LXmRYj9aJkJAGJ5uAV4C7KqCVlHrqTlqkz1TOf r2U9UfK8Q5To/O5y1tNBgpOPRUq7CtF9ByZHhsJY5tmhOLoE+uwEkMs37QRgThNaBpPzIu N9rKnz3Va210AxaeNDEWjnFfR1kaAIo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1610919287; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VJuOeeDSteTkfMNopFBRyzGkM7g1fui7EQCfFd1hGjE=; b=RO0pbDnmPojKqw/o+XJTmtkYrsPUIjWfsn0/27TwIgqZwncFx6X0H1BH7PflQgPdtR1/p7 EbObqXUaFcQMKZkkbZYW3KdtYHHvymu/7I5MVHZ9/v5RrfEwh7z0k4wdK0IVghJ2tCKMJX nmxJ/Uy3lQVrSaJoXiyM84+T3lzzjCI= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] IP-TFS drafts calls. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2021 21:34:53 -0000 Christian Hopps writes: > Also, as per the last IETF meeting, can we please start an WG > adoption call on the supporting YANG draft? > > https://datatracker.ietf.org/doc/draft-fedyk-ipsecme-yang-iptfs/ I think this draft is not exactly in sync with the main iptfs, as it still has some counters etc that would indicate there could be non aggregated and aggregated packets mixed in same SA, and it says that IP-TFS may be run only in one direction, but when using IKE I think the IP-TFS is always for in both directions, but of course the paramters and data rates might be different in different directions. Also there is ietf-i2nsf-ikeless@20202-10-30.yang which looks like typo, and it has this use-path-mtu, which does not tell which algorithm is used etc. Also I do not know what tx-drop-packets is supposed to mean? If we have already sent them how can we find out information whether it was dropped or not. Or is that supposed to be tx-queue-drop-packets, i.e., packets that were dropped before added to the outer ESP packet? Also it is difficult to say whether some of the counters are counting inner or outer packets, so it would be better to be more exact with the wordings, i.e., in addition of using -inner- perhaps also use -outer-. Is there going to be update for this draft to get it in sync with the main draft? -- kivinen@iki.fi From nobody Mon Jan 18 12:35:20 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FE93A0957 for ; Mon, 18 Jan 2021 12:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.onmicrosoft.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 eZ_9Ol3DQD8z for ; Mon, 18 Jan 2021 12:35:14 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770131.outbound.protection.outlook.com [40.107.77.131]) (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 104663A0C11 for ; Mon, 18 Jan 2021 12:35:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=my1oIwXXqoCVd0cwkWuq18cBIfQhi+Xy6A7WVVUOZBcIvIYlYog4AAlYDiBxAH8FP5ch5h4hjG/Y80WmHdHFEcv9VMu3cLhqpDVUjmlgHwamQ7r9TofDe8A/4zJ6s9SNB/xD2T7012f9xD8uxaawi5TvdK04VGCNNJiM2Z37CA3cWu/wRSZxKUXePijZecJStsjMz5rnRf2aUOnn9XIHmyYQKmZvg4EQU9JtAImJaLLuH5ZKjWlBESTw479kLx3CM0smlqGo/HPC+kKdZKj1aGOLI4+mUIV4eHS9V9bxtrPCAw94OyM12wk4Csl8EIsBcGNpWOZo5srVZ2y1gHABkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XgQqt+ZhDe0jeo1ChnJwhtoOEK7z/MRDkvm9AO9SCYg=; b=VkjSY1ULAOWFZn9TTF5x6hwbROeFj/4mbhUIqM6miELTcAVYhC+lv96E7Lc7pskqx48h5ow/QzTLvWaKhrPNlBoJM8psXTtroehXqiP1jGOcB+0q/gygc0S7sxo/khMFRNowCrZ3LziXdHUgjf5+xZdflbgKTPxtQU3eGn+qNBoFinHiut/wrP260PccsgBTbHxSolEkEx651xP08n+Psl7u54faXq48cp3M1OSup5TashVAW0Rdip3IMWv3CFOsok9uNnnHwTk9u8spJQgKzo+yF4s2nWbA+rzedai+whGLbkOvMZQCTLl4fYFnZgGOBnEGwZa1f0LZIxrN3LP2/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XgQqt+ZhDe0jeo1ChnJwhtoOEK7z/MRDkvm9AO9SCYg=; b=asyXt+ouyMIz5wakiKlMcQKfwPC03mH0oRvon7aRKBHXbLecrH4SWv8bvspo+dPrA+Z4tO1duVlCxandtK9Kd2XroB68mQScSliNd8fEvqP5Ja2+vLO/ERXrwBTClWTgdZN8iWrUEoD82E/e9RbFyuohzDE9nccnHZgMsQdITpM= Received: from MN2PR14MB4030.namprd14.prod.outlook.com (2603:10b6:208:1dc::14) by MN2PR14MB3423.namprd14.prod.outlook.com (2603:10b6:208:1a2::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9; Mon, 18 Jan 2021 20:35:09 +0000 Received: from MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::2420:fdbd:5ad4:a355]) by MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::2420:fdbd:5ad4:a355%8]) with mapi id 15.20.3763.014; Mon, 18 Jan 2021 20:35:09 +0000 From: Don Fedyk To: Tero Kivinen , Christian Hopps CC: "ipsec@ietf.org" Thread-Topic: [IPsec] IP-TFS drafts calls. Thread-Index: AQHW40Ztg6o0WlFn4kKOkA8NPNfmwaosapkAgAFua7A= Date: Mon, 18 Jan 2021 20:35:09 +0000 Message-ID: References: <24580.44406.245377.921032@fireball.acr.fi> In-Reply-To: <24580.44406.245377.921032@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=labn.net; x-originating-ip: [173.48.105.206] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f77ee3f-620d-48e9-2bcb-08d8bbf08c3c x-ms-traffictypediagnostic: MN2PR14MB3423: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: C5M7kG0gjvd5edKZ/UnGUasrdtjowW+KddDRY7MR9Pd9Flpr3zXss8cqdEdoHssAJKgiAaebCFItMpmv7W2V81Gu2q8R2X6sxIZGCHCHjWpkSkqa1GKg3Shn6YyL5/LraIAfkeGjY1ZsoO8ypAwtgMK2SUztNGDTNvlxeBvmeHnO6C/qhDLMyoH9RvyFvh3eSBeUKLzTnh9CBzJwXSqHvWtPWb/jmbFxNKCd2zAO9TiYt6G/BaqxAmIlht/z9FoVFNF2NrAnSwNpbgLQgDmPcGpiMDtg9Q/8D1aMxyRHWNckdazIrJmukt2sWOsJhkshbjXTpD1bUyNLEhkPCaCOQ3z76zfnwqJJmr+c3bWk+MTN31WZ7wEyNAZG3NmhW+Tt+sEIWUPvLoA4Q+jUQzfzDv+FyTKzEjTJCx+XvIMxhfgA8o/PTVpPW37Q29do3U+rbAsfaq/dk/6VRopoT03e7w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB4030.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(346002)(396003)(39830400003)(376002)(2906002)(66556008)(66446008)(64756008)(26005)(966005)(9686003)(110136005)(316002)(66476007)(186003)(8676002)(76116006)(8936002)(478600001)(5660300002)(55016002)(4326008)(66946007)(4001150100001)(6506007)(86362001)(7696005)(33656002)(83380400001)(71200400001)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?fAxEEYf+lZkY5QC9kyZJBS2y7oXmMyEYOW11VfcJmBjHrxcZriz1kQtOIB3d?= =?us-ascii?Q?9IjQGi8CYk1C3P1Tbgsgdr3P694KJD/DmO6MXxlJl9QQXNxfFpnXNadA16Bb?= =?us-ascii?Q?RG+895vwAahsvP6k/FCQnuWJ7zKa6+Q0IW16w8+TlZZGNI7LwPnnRR61nkp5?= =?us-ascii?Q?cnvm2I0fRVzP2Pgx9Xo9+iiCE88eBD4Sv/R/+d+fED3GzZTpvQpYQig+58R5?= =?us-ascii?Q?wAotcTOmn5Z9/i95JOMdo/rJZrFDw2wgy9i+dusfaG8P1KwwiKefgawoJoML?= =?us-ascii?Q?EDpwClPInCfOOvJQy4+8NdMsjNK8CgBvrA4wc/fD6dNV+/GhFgq/UNzw/6iN?= =?us-ascii?Q?Z92Ae5w8gh6juxITRx0EC+Fk/6cO2Fso2Ts09SCb0ZKbYxt0mmVKUoSqZccp?= =?us-ascii?Q?SZhAzaAq3k8St8aB3Bdy/dJGupHb9vaymW64i5YZO8sM04HzUR9JP9RtrLIX?= =?us-ascii?Q?AmOzcfR/PRGwBNJCQuFOhAwFy1MVNn0NEb3++Cum9N0Fge2IOhfNAZbl9u0f?= =?us-ascii?Q?XzEJq+DN4DKG2OCS1tnXo/H6OsDoxEN90v33iCL/mYxtSjFACpNnSmkXVWpO?= =?us-ascii?Q?BosKMNIz9yyVINi1Tqyk437zlOLoyNfKvm6lYCTFmotwLII0qesnpxr51q2l?= =?us-ascii?Q?aU78bAZAaVw58DxlfVyAQPQ1085Ihqt2wvBXL8OAYyx3Oeo0KVNY27mSXib7?= =?us-ascii?Q?b9e4C+ENuyS3nXkUTgXsJUZVPOKn5xuVnmRV1QAOAPwYsVsG8M3Aa7BhWfa9?= =?us-ascii?Q?MT29WOQz+ZLpnlE09m5ilHDDyYVh3olTYMNez0zdf6vsM6JpmplmpQ9miLze?= =?us-ascii?Q?A8a+Ncqy91GU8h7Mkm/raz1vaiV5j2oGqAfNyGWX2o8VFOQolSsDwY1bcAMa?= =?us-ascii?Q?TsvoRvBz6enJLSr6/+r/hg4aM4WfSWH3i+y6M6UqAi14v05MaFdOTRRDDeaT?= =?us-ascii?Q?9AyPrFOyUyd4FtG+2PIWqsNwrCUiI0A4YBk7J1sdwUM=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: labn.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB4030.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f77ee3f-620d-48e9-2bcb-08d8bbf08c3c X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2021 20:35:09.0461 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: eb60ac54-2184-4344-9b60-40c8b2b72561 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: q/Oi27fttHQ6JqKhOxDOXeGcmCqdK8niHiwutwuxEKvCm9j3aLaCkzCSFSpORARDAWR2/aE1yt75iBqyMH7nVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3423 Archived-At: Subject: Re: [IPsec] IP-TFS drafts calls. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2021 20:35:18 -0000 Hi Tero For draft-fedyk-ipsecme-yang-iptfs-01 we are asking for adoption as WG draf= t which means it does not need to be perfect. =20 The intention is supports the draft-ietf-ipsecme-iptfs-05 which is at a dif= ferent stage and Chris is the sole author so I'll let him address.=20 Please see the answers [don] inline: =20 Thanks Don -----Original Message----- Subject: [IPsec] IP-TFS drafts calls. Christian Hopps writes: > Also, as per the last IETF meeting, can we please start an WG adoption=20 > call on the supporting YANG draft? >=20 > https://datatracker.ietf.org/doc/draft-fedyk-ipsecme-yang-iptfs/ I think this draft is not exactly in sync with the main iptfs, as it still = has some counters etc that would indicate there could be non aggregated and= aggregated packets mixed in same SA,=20 [don] We can clarify. The stats are not per type of SA but only the releva= nt stats would be updated per SA. So yes it is in sync but some counters wo= uld be zero per SA. (my understanding).=20 and it says that IP-TFS may be run only in one direction, but when using IK= E I think the IP-TFS is always for in both directions, but of course the pa= ramters and data rates might be different in different directions. [don] We can clarify. The intention is IP-TFS encapsulation may not be oper= ating in both directions. =20 Also there is ietf-i2nsf-ikeless@20202-10-30.yang which looks like typo, an= d it has this use-path-mtu, which does not tell which algorithm is used etc= . [don] Not a typo The base draft draft-ietf-i2nsf-sdn-ipsec-flow-protection-= 12 contains 3 related YANG models.=20 ietf-i2nsf-ikeless@20202-10-30.yang=20 ietf-i2nsf-ikec@2020-10-30.yang ietf-i2nsf-ike@2020-10-30.yang We augment the ike and the ikless with use-path-mtu for the IP-TFS tunnel p= acket size computation. =20 I think you may be referring to the sample configuration data. This data sh= ows IP-TFS configuration samples only. But encalg encryption algorithm is = a configuration mandatory object in YANG schema we are augmenting. Therefo= re we supplied a minimal configuration for this schema - enough to satisfy = yanglint.=20 We can add a note - this is common policy for test modules as far as I know= . The draft-ietf-i2nsf-sdn-ipsec-flow-protection-12 contains much more ex= tensive sample configuration for the cases when encryption algorithm is spe= cified.=20 Also I do not know what tx-drop-packets is supposed to mean? If we have alr= eady sent them how can we find out information whether it was dropped or no= t. Or is that supposed to be tx-queue-drop-packets, i.e., packets that were= dropped before added to the outer ESP packet? [don] The description is Outbound dropped packets so your understanding is = my understanding we have overrun the ability to transmit the packets either= due to queuing or other. We will clarify.=20 Also it is difficult to say whether some of the counters are counting inner= or outer packets, so it would be better to be more exact with the wordings= , i.e., in addition of using -inner- perhaps also use -outer-. [don] The current wording is inner for packets that are encapsulated. The i= psec-stats capture outer packets. (Outers is redundant at that level. All= pad packets are outer (within iptfs- we could make inter an outer more exp= licit. Whereas extra pad packets are inner. (I assume this what you would l= ike clarified. Is there going to be update for this draft to get it in sync with the main = draft? [don]It is in sync but we can clarify your points (and any other clarificat= ions of course).=20 Thanks Don=20 -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jan 19 05:54:24 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE35C3A1506 for ; Tue, 19 Jan 2021 05:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 c8UBMRlpIAT5 for ; Tue, 19 Jan 2021 05:54:20 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id A8CB53A1505 for ; Tue, 19 Jan 2021 05:54:20 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1B38960F67; Tue, 19 Jan 2021 13:54:19 +0000 (UTC) From: Christian Hopps Message-Id: <48EE4FCD-B978-48CE-8B44-2532F9BDFAB8@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_D67560C6-96C6-49BE-B151-CB48781485CE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 19 Jan 2021 08:54:18 -0500 In-Reply-To: <24580.44406.245377.921032@fireball.acr.fi> Cc: Christian Hopps , ipsec@ietf.org To: Tero Kivinen References: <24580.44406.245377.921032@fireball.acr.fi> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [IPsec] IP-TFS drafts calls. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 13:54:22 -0000 --Apple-Mail=_D67560C6-96C6-49BE-B151-CB48781485CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 17, 2021, at 4:34 PM, Tero Kivinen wrote: >=20 > Christian Hopps writes: >> Also, as per the last IETF meeting, can we please start an WG >> adoption call on the supporting YANG draft? >>=20 >> https://datatracker.ietf.org/doc/draft-fedyk-ipsecme-yang-iptfs/ >=20 > I think this draft is not exactly in sync with the main iptfs, as it [...] Don replied to many of your points, a couple comments below from me: > and it has this use-path-mtu, which does not tell which > algorithm is used etc. Correct, this draft was published prior to the addition of PLMTUD to the = base specification (from the tsvart review). We'll update this in the = next revision. > Is there going to be update for this draft to get it in sync with the > main draft? Yes, of course, we're just requesting WG adoption, presumably there will = be reviews (like yours) and revisions to address them. :) Thanks, Chris. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 --Apple-Mail=_D67560C6-96C6-49BE-B151-CB48781485CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmAG5IoACgkQLh2DDte4 MCUTeQ//d6HhG4uz1arDLfSzrpSbFBwwiGvnZ+THJKu1T9jqmeCGtKEEVsEkVYfn IjMv73hnw71Bg40I6sBjgYHY/xNFuCF5NgS9g9IveOzYrYMMrsK9t0Qltkaz2OpN hM2Iai+7WZg5R1KYcZQHm6P3hp4mZM7gPBHC5ICu/pLGrmgG/c98qaAbdxxvPGIL mWLetYx9F8MpAkCUlRpfNgKRpcRm+LK7dYTopWoDBV7mui1iBVhsLtfz/URV+BDE jnu1nMWS0Ng+yPnflGmZvV99POBUWG7gZpcpoPeYvTsuHwGEJUNNhEiBUWQqQyJ8 DO2QGjHAdx/nMJCIoi3BahFRDap+jz6FI8OgkAEBjIPmX7TE+oEcKBQX9IqHqwGg h++gsqcH7B1RPbOMg14qbjYP5RDZc/Y300bztfgHKh43DKpcfUYc7domvsp7VG2v 3kzYKN9HuYtPHBvfku4+jJI/rT5EUHWt3wS3rC/0YY4vXqcqCB3cApti36Pfb0+p DwWYDAmyIUQ4sJYaxALl9PIQ2R3HWpfMYyiqC/FbnZRBTJ7CKhid1CA1spEv+qhq D11XVCKrX+0x2vmv32L8Y89++cot4ROmv2NhUVidvRdAj/mjrmfYFbIqWN8lJmAH FqGm8m4QKdjzPYAAZcvW+WBMI6j9ULXiD36BMIZmIsMZ66yzdOg= =xp25 -----END PGP SIGNATURE----- --Apple-Mail=_D67560C6-96C6-49BE-B151-CB48781485CE-- From nobody Tue Jan 19 08:15:25 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B89E3A15EB; Tue, 19 Jan 2021 08:15:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <161107292324.12110.7393468770501860943@ietfa.amsl.com> Date: Tue, 19 Jan 2021 08:15:23 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 16:15:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : IP-TFS: IP Traffic Flow Security Using Aggregation and Fragmentation Author : Christian Hopps Filename : draft-ietf-ipsecme-iptfs-06.txt Pages : 29 Date : 2021-01-19 Abstract: This document describes a mechanism to enhance IPsec traffic flow security by adding traffic flow confidentiality to encrypted IP encapsulated traffic. Traffic flow confidentiality is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well as non-constant send-rate usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-06 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 19 08:33:46 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4003E3A1602; Tue, 19 Jan 2021 08:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 yMMEE-dvMq9C; Tue, 19 Jan 2021 08:33:42 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 397503A1603; Tue, 19 Jan 2021 08:33:42 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 4F102616A2; Tue, 19 Jan 2021 16:33:40 +0000 (UTC) From: Christian Hopps Message-Id: <35741F85-18EC-4460-A320-316BD216A083@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_A69913A9-31E2-4F13-B812-AD30EB6EF861"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 19 Jan 2021 11:33:39 -0500 In-Reply-To: <24580.43954.709072.153522@fireball.acr.fi> Cc: Christian Hopps , ipsec@ietf.org, draft-ietf-ipsecme-iptfs@ietf.org, Joseph Touch To: Tero Kivinen References: <24580.43954.709072.153522@fireball.acr.fi> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [IPsec] My review of the draft-ietf-ipsecme-iprfs-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 16:33:44 -0000 --Apple-Mail=_A69913A9-31E2-4F13-B812-AD30EB6EF861 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Tero, I have published a new version of the draft which I believe addresses = the issues you raise in your WGLC readiness review below. As such, I'd = like to request the document enter WGLC. Changes indicated inline below. > On Jan 17, 2021, at 4:27 PM, Tero Kivinen wrote: >=20 > First, thanks for the Joe for very good TSV review for this draft. >=20 > I am now going through this draft to see whether it is ready for WGLC, > and while reviewing it I have some comments on it. On the other hand I > think it is starting to get ready for WGLC... >=20 > In section 2.2.3 fragmentation etc, the draft talks about replay > protection, but in the ESP replay attack protection is optional, and > does not need to be done by the receiver, altough the sequence number > generation MUST be done by sender. Modified the text to include "optional" and make more clear we are only = referring to the window method that is commonly used for this. > Also normally in ESP seqeuence numbers are not required to be back to > back, there could be cases where they would be incrementing by larger > value, and cases where the sequence numbers are not sent out in order. > This can happen for example if multiple encryption boards are used, > and each of them have separate coordinated sequence number generation. > This can also cause reordering in some cases. The draft now says that > "sender MUST Send the inner-packet fragments back-to-back", which > adds a new requirement for ESP. It might be good idea to add note, > that says this changes requirement from RFC4303, which only requires > that sequence numbers are incremented, not by how much (for example > draft-ietf-lwig-minimal-esp proposes that in some enviroments it might > be better to use time for sequence number generation so they do not > need to store sequence number while sleeping). Added paragraph on new "incrementing sequence numbers by one" = requirement. > Section 2.2.3 does not change the replay protection parts, just talks > about that similar method than what is used in the replay protection > can be used for reassembly. This may cause issues if the ESP level > does not do replay protection, but the reassembly code assumes it is > done. The text also seems to indicate that the window sizes for the > reassembly and replay protection could be different. The lack of the assumption is also more clear with the additional text = about the window sizes when both IP-TFS and replay protection are in = use. > If reassembly and replay windows are not same, I think the smaller one > of them is used, as if replay window is smaller, then too old packets > are dropped before they would reach the larger reassembly window, and > same happens for other way around. Added text to point this out. > I think we could just say that when using this detection of replays is > mandatory and that replay window and the reassembly window are same. Continued to leave the option to use replay protection or not to the = user. This change isn't required so I'd rather leave it as optional as = the base ESP spec does. > Also note, that increasing replay window size does not have that much > effect on the memory consumption of the SA, but increasing reassembly > window size does have. I.e., if the quite often used 1024 packet > replay window size is matched with same sized reassembly window of > 1024 * 1024 byte packets, that will mean each SA could consume up to 1 > MB for reassembly window. >=20 > Also even when the 2.2.3 says in that there is no need for timers, I > disagree with that, as during rekey or other operations it might be > possible that the traffic from the SA is moved to the newly created > SA, and then few minutes later the old SA is deleted. Keeping the > reassembly buffers for that long just because there is no incoming > packets is just wasting data. Added a more text saying timers are OK and could save some memory. > In section 2.2.2 and 2.2.3.1 the draft tries to fill the packets to > full, even when there would only be one byte fitting on the frame, and > I think this is bad idea. I would think it would be better to say that > if less than 5% (or some other fixed configurable amount) of the > packet is available and the packet to be added would be fragmented, > then packet is padded instead of fragmenting, and the packet to be > added is moved to next outer packet. >=20 > I think there is too much emphasis on not wasting the bandwidth and > too much emphasis on the robustness of the protocol. Small amount of > padding that will avoid fragmentation is much more desirable than not > wasting few % of the bandwidth. Added sentence describing a method for minimum fragment size = configuration as well. > In section 2.2.5 it says that ECN value is not mapped, because of > constant-send-rate, but it leaves out the other part, i.e., if some > device is sending inner data faster than the constant-send-rate then > the IPTFS should set the ECN for inner packets when adding them to the > aggregated frame, just to indicate this information to the other end. Added paragraph indicating ECN can still be set on inner fragments = according to RFC3168. > In section 2.2.7 the draft says there is no effective MTU, which is > true, but the question is that should there be one? I mean even if the > original sender will automatically detect that 63kB UDP packets go > through without fragmentation that does not mean that it will be good > idea to use 63kB packets as that will cause latency for all other > packets sharing the same SA. I think it would be useful to be able to > restrict the effective MTU of the tunnel. Added sentence indicating MTU MAY still be explicitly configured on the = tunnel. > In section 2.3 why does the text say: >=20 > In other words, an SA that has > AGGFRAG_PAYLOAD enabled MUST NOT have non-AGGFRAG_PAYLOAD payloads > such as IP (IP protocol 4), TCP transport (IP protocol 6), or ESP = pad > packets (protocol 59) intermixed with non-empty AGGFRAG_PAYLOAD > payloads. >=20 > why is that restriction with only non-empty AGGFRAG_PAYLOAD payloads? > When can empty AGGFRAG_PAYLOAD used intermixed with other payloads? Added sentence explaining this and referring back to "Empty Payload" = section which also explains this. > The rekeying of the SA is not specified fully. It does say that > rekeying cannot change the USE_AGGFRAG information, but it does not > say that rekeyed SA actually inherits the USE_AGGFRAG flag. It should > explictly mention that. Added sentence indicating the inheritance. > Also it does not mention whether frame is allowed to to be fragmented > across the old and new SA. It should say that as sequence numbers are > different for the SAs, the packet can never be fragmented so that part > of it is in old SA, and part of it is in the newly created SA. Added sentence saying inner packets should not be fragmented across = different SAs. > In section 2.2.4 draft says: ESP payload length is equal to the > AGGFRAG_PAYLOAD header length. This would indicate that this packet is > not the same length than other frames. I think it would be better to > say that this has just the AGGFRAG_PAYLOAD header, and then rest of > the frame is padding. These are only used to transmit congestion control information back to = the sender on non-IP-TFS SAs, there's no reason to pad them out. Once again I believe we are ready for WGLC. Thanks, Chris. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 --Apple-Mail=_A69913A9-31E2-4F13-B812-AD30EB6EF861 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmAHCeMACgkQLh2DDte4 MCXsoA/9EiLYm8/tFII9jLIxGrjyEuJFMBDvkS4qZdBdpEvYhzs8t4YZDLbVDCkP Pqiym0N7hzrDAR5nOkI5fMKCgJzp2lOIMLa0/RZ75+T2Er3IXQCxCcTAGxUAcwlN Fibe0I08NaPS7jYr+J64gjhLHtki6yb6ikT/mrR2GNiarjSu7z7UVKzHK6nJd45G yqEAUPvxoyNaIzUzg2Qb3uANwHHwkzQXmR4ppTYnNGUyg/Yb//Ldu/2YN2KWaF26 usC3QqfFeF6aumvaOU41lp+Mh7iz2AqKObqm2msyD/9d2g/AGj7tPkVkM/0+7d8l nEUvAwPv8yzhJpiWBqHwI51E7+ZuHNgYgll28kvD/5XSk81+0I4dJEZKdzqz0hu2 sZchAO2auukJ5peqsg5jMBwYNIXyYa3DMY9vIyx8ujMEMdCLG42bYlsy6oT5/gvV /I1tqYuv2Il1qD6OkJzDIq8N8JsbbwTwgnZ4Z78UQs8uTuu5Icy36cCzi9PCpUcs zlBwFr5tmDxZ+BPcJ9Tj+ZZrsR3YsF9DrK7FaOotehiqJ5x33RirdyV1dhZx3X6X aCJ+ju0/dXwkxWd1S9L3kcfOX/pD3cENN34SaP0NXFiZXsI1Li6DriNKm3LCVSTp UfLd0/DI15zN4CTFS/lJ7xztzNj9QeIy1txUoAIeFedZdC5GUpk= =NqOq -----END PGP SIGNATURE----- --Apple-Mail=_A69913A9-31E2-4F13-B812-AD30EB6EF861-- From nobody Wed Jan 20 05:09:56 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0713A1200 for ; Wed, 20 Jan 2021 05:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DQGS8rFwYRqL for ; Wed, 20 Jan 2021 05:09:50 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC2D3A1201 for ; Wed, 20 Jan 2021 05:09:50 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id x23so25955848lji.7 for ; Wed, 20 Jan 2021 05:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=jFiEWWvwldOzF/DIhT+y1E+aFvxuNmDTJnUq2XGzPSM=; b=N0T9SpDsqJNTkULlwj5ibuiuV6rJuhJ9buAuF8yBwZaWpTxT+7Bmg48Wl+ZNHdZ20o KBC1QQSCMW49fPl7QDpFF2fFqz8v3O184s4TBaGD4Mf1wY44VnPFyhWP9l40HptE/aiG Vg73yuIICgsxDAmiK0C61qWu188tYZgO1/MvdmxcEYJgxWgwR+3jXCbjVDzkoEUdE3xa 9TReKtkLLFOyV6iEllAIN6+1N6HaZozCLc8DEv6n4bDuo59Rp41/rPgQDdWRUIqjJb+t QjF/wx8Tzy8EhwMH8k3A1qoJwKI/rWX2StD5eeVHsejCS7E31kt8MHYDJyKomc59klZU 1Mmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=jFiEWWvwldOzF/DIhT+y1E+aFvxuNmDTJnUq2XGzPSM=; b=bc6AcpTYH/N7+ZEUpom2+dCcPOd4chUmSadgODTTvCEuYsOgj1foChJTi02PovqbVS vwlPAAkzIUevQXA1Ydy+OtiZxpmY2sw1HhMeM3AA6+Ci16s9mvVt/RYSabQwtxtODoMh dqS81jhAokpJWf+F7XVFk4DKq+/TKGkJI0QIDzMNcNJkwV7DRuqy885TFlzcwc14+Y1J gvsDzG0N9b7hYnwENJ9UOJdI5tsurVBnpZu79mx3aUExbsXM6WgPftuc/hjsigwr7Rm7 RmCN77t4oUm7Te4yVn++Lh7Vha9kJpsCYo3sJ3GxRT8hF3LUc3meSbk5UUd2nDlGildy 227w== X-Gm-Message-State: AOAM532IRqfNaEgEFyp+vjZs+e/Cq/j2qQO/Dp4JfZUP1hjkyA/1ILMb KlUmzTIfovaPqhGCMx9QWGdOngghAB4= X-Google-Smtp-Source: ABdhPJwANRdKDrtBVkA0lXA5oG0wzcYWxM22XcHZRC9lbdWe94ZgLgHhS3s3e/icY5Oy6v6zDsr4yg== X-Received: by 2002:a2e:9b1a:: with SMTP id u26mr4406717lji.187.1611148187581; Wed, 20 Jan 2021 05:09:47 -0800 (PST) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id 70sm195069lfb.165.2021.01.20.05.09.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jan 2021 05:09:45 -0800 (PST) From: "Valery Smyslov" To: "IPsecME WG" Cc: "Paul Wouters" , "Sahana Prasad" Date: Wed, 20 Jan 2021 16:09:49 +0300 Message-ID: <03e801d6ef2d$88820f00$99862d00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdbvLX9B4gzHloX0Qk2ypVqkmsDHEw== Content-Language: ru Archived-At: Subject: [IPsec] Comments for draft-ietf-ipsecme-labeled-ipsec-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2021 13:09:55 -0000 Hi, after reading draft-ietf-ipsecme-labeled-ipsec-04 I have a couple of comments. First, it's not clear for me why zero length TS_SECLABLE is prohibited. The draft currently says A zero length Security Label MUST NOT be used. If a received TS payload contains a TS_TYPE of TS_SECLABEL with a zero length Security Label, that specific Traffic Selector MUST be ignored. I wonder what's rational behind this restriction. From my point of view zero length TS_SECLABLE can be used to express that using Security Labels is optional. I.e. initiator can include zero length TS_SECLABEL Traffic Selector along with other TS_SECLABEL Traffic Selectors to indicate that responder is free to not use security labels for the SA. Currently draft suggests the initiator to perform several attempts to establish IPsec SA with and without TS_SECLABEL Traffic Selectors in such situation, which is more complicated and less efficient. Am I missing something? Another my concern is that draft allows security labels to differ in TSi and TSr without giving any possible semantic interpretation for this. This looks weird. I think that at least some possible interpretation of such situation must be given, e.g. TS_SECLABEL in TSi is used for traffic from initiator to responder and TS_SECLABEL in TSr is used for the return traffic. In this case it is clear that they can differ in some situations. And the last (but not the least). It seems to me that Section 3 (which aims to update Section 2.9 of RFC 7296) oversimplifies the negotiation process. In particular, the sentence A responder MUST create its TS response by selecting one of each TS_TYPE present in the offered TS by the initiator. is inaccurate in my opinion, since it implies (as I read it) that responder can pick exactly one traffic selector of each TS_TYPE and can only return it unmodified. If fact, with regard to TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, all the proposed traffic selectors are semantically combined and represent the set of traffic the initiator believes is appropriate for the SA. The responder then can select several traffic selectors from the proposed list and even modify some or all of them provided that the resulted set of traffic they represent is a subset of set of traffic proposed by the initiator. This logic is lost in the draft and since the draft intends to update RFC 7296 in this regard, readers may decide that this logic is no more actual. In this Section 3 must be rewritten to describe the changes more accurately. Regards, Valery. From nobody Wed Jan 20 18:28:30 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD70C3A16B3 for ; Wed, 20 Jan 2021 18:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 WMdnVlKwM6jA for ; Wed, 20 Jan 2021 18:28:27 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 D5D7E3A16B1 for ; Wed, 20 Jan 2021 18:28:25 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DLmXQ2fN3zDtk; Thu, 21 Jan 2021 03:28:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1611196102; bh=R9QWFYhVtk4oJtXnlt9+bN4ZYqZX4DVWC+FV0Li9kQ8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hk+fK64IXghev4yFAcL2aGffu3B8g2HtF3WwEyZ6gNVAz7DKu0y8MFz8GWI75uBiK bbdAZ1+9JY8JVELlyGsk3JpzCiBLrI+FaP1mvO1tzrFWte0ZA8FgrfgwG+45sriR3G f2VYxYwyuwLPPaaxNPzUbRkMtsbgGq/Lmc8Bh22c= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id pd4JtBO9is_b; Thu, 21 Jan 2021 03:28:20 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 21 Jan 2021 03:28:20 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 039946029B62; Wed, 20 Jan 2021 21:28:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EF01B66A9A; Wed, 20 Jan 2021 21:28:18 -0500 (EST) Date: Wed, 20 Jan 2021 21:28:18 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: IPsecME WG , Sahana Prasad In-Reply-To: <03e801d6ef2d$88820f00$99862d00$@gmail.com> Message-ID: References: <03e801d6ef2d$88820f00$99862d00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Comments for draft-ietf-ipsecme-labeled-ipsec-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 02:28:30 -0000 On Wed, 20 Jan 2021, Valery Smyslov wrote: > First, it's not clear for me why zero length TS_SECLABLE is prohibited. > The draft currently says > > A zero length Security Label MUST NOT be used. If a received TS > payload contains a TS_TYPE of TS_SECLABEL with a zero length Security > Label, that specific Traffic Selector MUST be ignored. > > I wonder what's rational behind this restriction. From my point of view > zero length TS_SECLABLE can be used to express that using Security Labels > is optional. I.e. initiator can include zero length TS_SECLABEL Traffic Selector > along with other TS_SECLABEL Traffic Selectors to indicate that responder > is free to not use security labels for the SA. We did discuss this earier in the WG. There is no use case of "optional" security labels. You either insist on these, or you don't use these. Implementing "optional" ones by using a zero length label is asking for implementation problems. Especially when people consider these labels as strings and run strlen() on the empty (but NULL terminated string) and interpret that as wildcard. Since there is no use case, and significant implementation danger, the document makes an explicit case to reject these. Our implementation will return TS_UNAVAILABLE if it encounters any zero length TS_SECLABEL. > Currently draft suggests > the initiator to perform several attempts to establish IPsec SA > with and without TS_SECLABEL Traffic Selectors in such situation, > which is more complicated and less efficient. Am I missing something? It was what the WG preferred to do. The reasoning was that labels are surely very much preconfigured and connections will not be migrated from "no security" to "security label" where the operator wants to operate insecurely first. That is, opportunistic security labels is not a thing. The case you describe is very unlikely. Either the endpoints wants a label or doesn't want one. optional security is not security. > Another my concern is that draft allows security labels to differ > in TSi and TSr without giving any possible semantic interpretation for this. Correct. But the label is clearly defines as opaque to the IKE layer. The IKE layer should not be making any kindds of assumptions or interpretations, but just relay this to the underlying label security consumer (eg in our case the LSM of SElinux). Note that our implementation only supports symmetrical labels so far, because that is how SElinux labeling works. But the protocol can accept other methods. > This looks weird. I think that at least some possible interpretation > of such situation must be given, e.g. TS_SECLABEL in TSi is used > for traffic from initiator to responder and TS_SECLABEL in TSr > is used for the return traffic. In this case it is clear that > they can differ in some situations. I'm not sure why this is not clear? TSi and TSr entries apply to one direction. TS_SECLABEL does not change that. > And the last (but not the least). It seems to me that Section 3 > (which aims to update Section 2.9 of RFC 7296) oversimplifies > the negotiation process. Again, we followed the consensus of the group here. > In particular, the sentence > > A responder MUST create its TS response by selecting one of each > TS_TYPE present in the offered TS by the initiator. > > is inaccurate in my opinion, since it implies (as I read it) that responder can pick > exactly one traffic selector of each TS_TYPE and can only return it unmodified. How about this clarification: A responder MUST create its TS response by selecting at least one of each TS Type. One exception is that a responder MAY omit a TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE as long as at least one TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE is selected. Furthermore, a narrowed TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE content set MAY be selected. Note that this is mentioned already in section 1.2: A Traffic Selector payload (TS) is a set of one or more Traffic Selectors of the same or different TS_TYPEs, but MUST include at least one TS_TYPE of TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. If you prefer other text, please provide your suggestion. Paul From nobody Thu Jan 21 04:46:27 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E1A3A09F5 for ; Thu, 21 Jan 2021 04:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 IkSBvKfOsZCD for ; Thu, 21 Jan 2021 04:46:24 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D233A09EA for ; Thu, 21 Jan 2021 04:46:23 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id s11so2302555edd.5 for ; Thu, 21 Jan 2021 04:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=Sa1C/jjSc04/78Lpr0YjrF0545mD+rUxrjNU2EOXbe8=; b=DhdgFu6mx1V5SHJIzh/X9LHyxVu6QS/QA8iOAIklVQd8KkZGb0R8nKG/VejvyBAAbS sN7Xstdy46JdCf91Nz9Xk38tXM47pwmpctbxucPdj58zaWPa79GZZWZEXFdMxIHrKt2f uiS8CsrigPPACyipF/gMbu0Fc90/4KOATLp5YVb7R2QdXq3BEyKVQ82++rcpZPpA1h6L YmAML4WLul0ONffBV7FrLM4oTUh22CG9rcTV3qzuRrebGIOz5IIf3Qd0cl5FY/taP7uy qr3nuw7lfBeWGqgV/Hez/1oCC98AABD+7u7ntuvh6LeeqKkXojVRSCN+3TJqyMkemADe ZjoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Sa1C/jjSc04/78Lpr0YjrF0545mD+rUxrjNU2EOXbe8=; b=DlYS+Wyn5Aj0KTJ9hD5qfDbTj7vFnLrV5hx6oCGU/FeWtGgvxbjU+IxmkoJ2UmiXgX T13kFaS3y34wQVSkhHtWiGAzvkw2StGioj+gd7JI7I4Ovbrtr9PRhszq9QCSyia58GQ1 TqfcqMxDFeMNELn2ynav/KUISDXU7nrL7auaf5EUjaRxaAvKgIIOIHs8iVXImmDODWlk dfxliBxdAgB47poYuJ/XAvONfWOpUcmq7eYhuo7iBXwXmvC6Jc6zYDCsEETymEVF+dGl S2hl/cerpwlVcCyIt+kga3aKhB5iqdupAOhOn7zqdxZEz6/oD0jLE0r0cgh2KSkbfCrI JfTw== X-Gm-Message-State: AOAM532U3l7Z05UPtJobmgPMr+OZg7gQxVn1ra6HtNnJIEUlg4UuRSy6 SdrFzVTlMFAK/9MOAGoOlhnTIa7SfjI= X-Google-Smtp-Source: ABdhPJzw5Noskm/EuyribzicWK8QB5dBw+Gx3uXGVYOmBtUxbwE5+Kfzsv5Y3+U819SIqqWl3H5fOA== X-Received: by 2002:a05:6402:50c6:: with SMTP id h6mr10924854edb.117.1611233181581; Thu, 21 Jan 2021 04:46:21 -0800 (PST) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id re19sm2126050ejb.111.2021.01.21.04.46.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jan 2021 04:46:20 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: "'IPsecME WG'" , "'Sahana Prasad'" References: <03e801d6ef2d$88820f00$99862d00$@gmail.com> In-Reply-To: Date: Thu, 21 Jan 2021 15:46:24 +0300 Message-ID: <055901d6eff3$6ddf7220$499e5660$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGBSOOV+wJ6j63zYWXgPX4dM31iBwISkvkYqsyruwA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Comments for draft-ietf-ipsecme-labeled-ipsec-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 12:46:25 -0000 Hi Paul, > > First, it's not clear for me why zero length TS_SECLABLE is prohibited. > > The draft currently says > > > > A zero length Security Label MUST NOT be used. If a received TS > > payload contains a TS_TYPE of TS_SECLABEL with a zero length Security > > Label, that specific Traffic Selector MUST be ignored. > > > > I wonder what's rational behind this restriction. From my point of view > > zero length TS_SECLABLE can be used to express that using Security Labels > > is optional. I.e. initiator can include zero length TS_SECLABEL Traffic Selector > > along with other TS_SECLABEL Traffic Selectors to indicate that responder > > is free to not use security labels for the SA. > > We did discuss this earier in the WG. There is no use case of "optional" > security labels. You either insist on these, or you don't use these. Well, it contradicts what draft says (Section 2.2): If the Security Label traffic selector is optional from a configuration point of view, the initiator will have to choose which TS payload to attempt first. If it includes the Security Label and receives a TS_UNACCEPTABLE, it can attempt a new Child SA negotiation without that Security Label. So you do allow security label to be optional, but negotiate its usage this with most complex and ineffective way. It's very strange. > Implementing "optional" ones by using a zero length label is asking for > implementation problems. Especially when people consider these labels > as strings and run strlen() on the empty (but NULL terminated string) > and interpret that as wildcard. Well, people will consider meaning of the security labels in accordance to what is written in the draft. If we try to envision every possible mis-reading of the documents we'd better not to start writing them... And BTW zero length means that there are no any content, including NULL terminator :-) > Since there is no use case, and significant implementation danger, the > document makes an explicit case to reject these. Our implementation > will return TS_UNAVAILABLE if it encounters any zero length TS_SECLABEL. No, the document does allow optional security labels, see above. > > Currently draft suggests > > the initiator to perform several attempts to establish IPsec SA > > with and without TS_SECLABEL Traffic Selectors in such situation, > > which is more complicated and less efficient. Am I missing something? > > It was what the WG preferred to do. The reasoning was that labels are > surely very much preconfigured and connections will not be migrated > from "no security" to "security label" where the operator wants to > operate insecurely first. That is, opportunistic security labels is > not a thing. > > The case you describe is very unlikely. Either the endpoints wants a > label or doesn't want one. optional security is not security. Then why text in 2.2 allows the initiator to choose between using them and omitting them? Isn't it exactly what you just described as "not security"? > > Another my concern is that draft allows security labels to differ > > in TSi and TSr without giving any possible semantic interpretation for this. > > Correct. But the label is clearly defines as opaque to the IKE layer. > The IKE layer should not be making any kindds of assumptions or > interpretations, but just relay this to the underlying label security > consumer (eg in our case the LSM of SElinux). Note that our > implementation only supports symmetrical labels so far, because > that is how SElinux labeling works. But the protocol can accept > other methods. I still prefer _some_ words to be added about _possible_ semantics when seclabels are different in TSi and TSr. > > This looks weird. I think that at least some possible interpretation > > of such situation must be given, e.g. TS_SECLABEL in TSi is used > > for traffic from initiator to responder and TS_SECLABEL in TSr > > is used for the return traffic. In this case it is clear that > > they can differ in some situations. > > I'm not sure why this is not clear? TSi and TSr entries apply to > one direction. TS_SECLABEL does not change that. It's unclear what this case could mean: TSi = ((0,0,198.51.0-198.51.255), TS_SECLABEL1) TSr = (((0,0,203.0.113.0-203.0.113.255), TS_SECLABEL2) It's true that IKE doesn't interpret seclabels, but it usually does some sanity checks and as implementer I'm not sure whether this is allowed (what does it mean?) or not. > > And the last (but not the least). It seems to me that Section 3 > > (which aims to update Section 2.9 of RFC 7296) oversimplifies > > the negotiation process. > > Again, we followed the consensus of the group here. > > > In particular, the sentence > > > > A responder MUST create its TS response by selecting one of each > > TS_TYPE present in the offered TS by the initiator. > > > > is inaccurate in my opinion, since it implies (as I read it) that responder can pick > > exactly one traffic selector of each TS_TYPE and can only return it unmodified. > > How about this clarification: > > A responder MUST create its TS response by selecting at least > one of each TS Type. One exception is that a responder MAY omit > a TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE as long as at least > one TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE is selected. > Furthermore, a narrowed TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE content > set MAY be selected. Much better, thank you. For best clarity I would have added a sentence that this draft doesn't change a logic described in Section 2.9 of RFC 7296 for types TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, it only defines additional rules for how TS_SECLABEL traffic selectors are negotiated. Regards, Valery. > Note that this is mentioned already in section 1.2: > > A Traffic Selector payload (TS) is a set of one or more Traffic > Selectors of the same or different TS_TYPEs, but MUST include at > least one TS_TYPE of TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. > > If you prefer other text, please provide your suggestion. > > Paul From nobody Thu Jan 21 09:50:46 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAD43A1383 for ; Thu, 21 Jan 2021 09:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 fjYIDIkm04QD for ; Thu, 21 Jan 2021 09:50:42 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 5E1533A1384 for ; Thu, 21 Jan 2021 09:50:42 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DM90b36vHz3FJ; Thu, 21 Jan 2021 18:50:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1611251439; bh=MD9HADUN6U7xu2ulzrfRs9r1r48GskLNj3PJRIVWqPc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sEKJ9g1Gs+7WmRH9Bwg7+PLHV9r/CFb6URrxiZ575sMMVse9cbDxvaBXD3mPl6ejk S2pgeo4gRMYRMFjR3/nCWfAsPSE2LsTpO6fLAI9xyKzZRUbdcwZ7at/EsfH/W9Bpug vjDO42JRrfI0aqbddHBGn+AmkRIWBYGaiSZYs0qI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LVdEJj_gLrJL; Thu, 21 Jan 2021 18:50:37 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 21 Jan 2021 18:50:37 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C21086029B62; Thu, 21 Jan 2021 12:50:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B980A66A9A; Thu, 21 Jan 2021 12:50:35 -0500 (EST) Date: Thu, 21 Jan 2021 12:50:35 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: 'IPsecME WG' , 'Sahana Prasad' In-Reply-To: <055901d6eff3$6ddf7220$499e5660$@gmail.com> Message-ID: <63cf1275-c7a6-c9e0-c29d-04a11cdbd7f@nohats.ca> References: <03e801d6ef2d$88820f00$99862d00$@gmail.com> <055901d6eff3$6ddf7220$499e5660$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Comments for draft-ietf-ipsecme-labeled-ipsec-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 17:50:45 -0000 On Thu, 21 Jan 2021, Valery Smyslov wrote: >>> I wonder what's rational behind this restriction. From my point of view >>> zero length TS_SECLABLE can be used to express that using Security Labels >>> is optional. I.e. initiator can include zero length TS_SECLABEL Traffic Selector >>> along with other TS_SECLABEL Traffic Selectors to indicate that responder >>> is free to not use security labels for the SA. >> >> We did discuss this earier in the WG. There is no use case of "optional" >> security labels. You either insist on these, or you don't use these. > > Well, it contradicts what draft says (Section 2.2): > > If the Security Label traffic selector is optional from a > configuration point of view, the initiator will have to choose which > TS payload to attempt first. If it includes the Security Label and > receives a TS_UNACCEPTABLE, it can attempt a new Child SA negotiation > without that Security Label. > > So you do allow security label to be optional, but negotiate its usage this > with most complex and ineffective way. It's very strange. Again, this was the result of discussion in the WG where you were very insistent on how to interpret and send TS payloads. So I'm a little confused about this being an issue now. The text above shows how you could implement optional labels, which is deemed a rare or not needed feature for most implementations. It tells you to basicaly reconfigure on the fly. The advantage is that the whole discusion of "optional" does not leak into the IKE TS negotiation protocol. If you think it would be more clear if we don't describe the above option, I'm fine with removing that text. >> Implementing "optional" ones by using a zero length label is asking for >> implementation problems. Especially when people consider these labels >> as strings and run strlen() on the empty (but NULL terminated string) >> and interpret that as wildcard. > > Well, people will consider meaning of the security labels in accordance > to what is written in the draft. If we try to envision every possible mis-reading > of the documents we'd better not to start writing them... It is not about misreading the document. It is to ensure there are less conditions where there is ambiguity. Does a NULL TS_SECLABEL mean "no sec label" or "optional sec label" or "wildcard sec_label". We can write it clearly in the draft, but it is still a flawed concept. The clearest solution is if you want no restructions on sec_label, to not include any TS_SECLABEL traffic selector. Removing the zero length from being valid makes it very clear this cannot be used for anything, including meaning "a wildcard" or "nothing". If you want a wildcard, you can send a TS_SECLABEL containing the string "*" (and then figure out whether it is a single character label or has a string NUL termination :P ) > And BTW zero length means that there are no any content, including NULL terminator :-) I bring it up because it is a real danger this will get badly implemented. And it already is. The Linux kernel takes these values in a struct: struct xfrm_user_sec_ctx { __u16 len; __u16 exttype; __u8 ctx_alg; /* LSMs: e.g., selinux == 1 */ __u8 ctx_doi; __u16 ctx_len; }; So you specify the label with ctx_len. Yet the "ip xfrm state" output shows a trailing @ character, suggesting it is already treating this as a NUL terminated string. Oddly enough, the output of "ip xfrm policy" shows the same label without the trailing @. This is why I originally had stated that the label could not contain a NULL, but during the process, all this got removed for treating it as an opaque blob. The libreswan implementation, which uses "strings" of SElinux values, checks for embedded NULLs and rejects these. But that is arguably part of the "label consumer" and not IKE. >> Since there is no use case, and significant implementation danger, the >> document makes an explicit case to reject these. Our implementation >> will return TS_UNAVAILABLE if it encounters any zero length TS_SECLABEL. > > No, the document does allow optional security labels, see above. Not really. It says you first try negotiating "with labels" and if that fails try to negotiate "without labels". That is different from supporting a negotiation with optional labels. Again, it was you who was very strongly of the belief that optional traffic selectors should not be allowed and that one MUST pick one of each TS type. And that you must be _selecting_ on something, and you cannot select on nothing. Additionally, an implementation accidentally outputting an empty label into the TS_SECLABEL payload should not introduce a wildcard label in my opinion. It is just a little safer for them to need to create a "*" payload. >> The case you describe is very unlikely. Either the endpoints wants a >> label or doesn't want one. optional security is not security. > > Then why text in 2.2 allows the initiator to choose between using them > and omitting them? Isn't it exactly what you just described as "not security"? It just describes something you can do with any new Traffic Selector that will ever be introduced to IKE. You can always try it with it first, and without it as fallback. It is not a propery of TS_SECLABEL. >>> Another my concern is that draft allows security labels to differ >>> in TSi and TSr without giving any possible semantic interpretation for this. >> >> Correct. But the label is clearly defines as opaque to the IKE layer. >> The IKE layer should not be making any kindds of assumptions or >> interpretations, but just relay this to the underlying label security >> consumer (eg in our case the LSM of SElinux). Note that our >> implementation only supports symmetrical labels so far, because >> that is how SElinux labeling works. But the protocol can accept >> other methods. > > I still prefer _some_ words to be added about _possible_ > semantics when seclabels are different in TSi and TSr. Please provide text, but be aware that the document treats the label as opaque to IKE. >>> This looks weird. I think that at least some possible interpretation >>> of such situation must be given, e.g. TS_SECLABEL in TSi is used >>> for traffic from initiator to responder and TS_SECLABEL in TSr >>> is used for the return traffic. In this case it is clear that >>> they can differ in some situations. >> >> I'm not sure why this is not clear? TSi and TSr entries apply to >> one direction. TS_SECLABEL does not change that. > > It's unclear what this case could mean: > > TSi = ((0,0,198.51.0-198.51.255), > TS_SECLABEL1) > > TSr = (((0,0,203.0.113.0-203.0.113.255), > TS_SECLABEL2) > > It's true that IKE doesn't interpret seclabels, but it usually > does some sanity checks and as implementer I'm not sure whether > this is allowed (what does it mean?) or not. It just tells you that both endpoints will apply the specific label to the specific IP/proto/ports range when receiving these packets. I mean, it could even mean a specific group, eg group "seclabel1" and group "seclabel2". eg: TSi = ((0,0,198.51.0.0-198.51.0.255), "jeeps") TSr = (((0,0,203.0.113.0-203.0.113.255), "awacs-plane") And the jeeps could only accept awacs-plane traffic, and the awacs-plane could only accept jeeps traffic. Sure, in my use case, these will be symmetric, eg: system_u:object_r:ipsec_spd_t:s0 >> How about this clarification: >> >> A responder MUST create its TS response by selecting at least >> one of each TS Type. One exception is that a responder MAY omit >> a TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE as long as at least >> one TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE is selected. >> Furthermore, a narrowed TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE content >> set MAY be selected. > > Much better, thank you. For best clarity I would have added a sentence that this draft > doesn't change a logic described in Section 2.9 of RFC 7296 for > types TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, it only > defines additional rules for how TS_SECLABEL traffic selectors are negotiated. The idea was to update the TS handling in general for new TS types, not just TS_SECLABEL. So that new TS Types in the future do not need to update RFC 7296. So how about this change: A responder MUST create its TS response by selecting at least one of each TS Type. For this selection, TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE are considered one (IP) type. That is, it is valid to choose 1 TS of type TS_IPV4_ADDR_RANGE and zero TS of type TS_IPV6_ADDR_RANGE. TS Types supporting narrowing may be narrowed down upon their selection, as it described in Section 2.9 of RFC 7296. Paul From nobody Thu Jan 21 23:59:43 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13993A11C0 for ; Thu, 21 Jan 2021 23:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DAcBAKnxijc9 for ; Thu, 21 Jan 2021 23:59:39 -0800 (PST) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3873A11BF for ; Thu, 21 Jan 2021 23:59:39 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id w1so6315555ejf.11 for ; Thu, 21 Jan 2021 23:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=M9Ge9XQr4Q8yVwRWaJEVKGcoB/rUoclFGGeDFmzn3xo=; b=XuBIQIfJVEtMtXX9ADADnpZV89htu386hXVtCBtH+LYyLPw3hffNEsnJWXqRxWtGj+ 07aVkOtCLjgoMHfNQdq2UqGzHElTHQMQVFwnxafav6yirnp1gfdIYE/cXk4FOpyzgN2j SjlU/CZ3YHiIQxM7te0kLEZcsmI2T8PeZw3vmB0PssrdwbQm+03URFgcUIpIbgdQMj1F kAOapzO2XX6HxLshX4CLQGoP/W/STDn3COTFmUeqdI+hPOF5oEqv2t5IfoFY6uWL6GCh SmriapKUNEmliAuCf2s0KhAz98ipdJYqfyAtq6xMwtDGyTVRm18UO15YB8JTtHZ9nbnI NNCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=M9Ge9XQr4Q8yVwRWaJEVKGcoB/rUoclFGGeDFmzn3xo=; b=S0AHA2cFUxVBC5m/nQ3qJLrbZLtbLxAM71qfwMNhME4hBh02NhFHlYGuB+bu8CzJSP QnARnQcqa1jPSAsPZzKGgTELz8iTt3rTyAOU5wXx6For/sWD0N0RT/dZ51slSyQG2Z8a IL3L+iHPVM03FsI6rbtyEhHt/Q0NyxqkTmORl5D2Jc3PQ0WLxylI7JqlveAeMsC44ZjT zVLzvQfZUeT4xWV+Y8q4AJJ3rJE+fZ7HpuNzuycyEvn8CMPvcvKImLDOXUYfvLqE7ci5 gy/aL8qJ8scy4kw0kFn6YO1S8tmpACToFdCCVDcsX7L9YEiNAXgekbRROAW3jJxCdpH9 BIcg== X-Gm-Message-State: AOAM533vjdngnDleEttB3JRega+6JFZfVpTs8iUAufUyplHsyo8+iyH6 CPjFerk9Kd140rMoiFZilI3+citbfS8= X-Google-Smtp-Source: ABdhPJyspVYcAPe2EeWkS5nhDcU5b5RgjxeInfPvqODYl1uLqod8BELzGVP8KXn9dyIJDdbZwdCDFQ== X-Received: by 2002:a17:906:3899:: with SMTP id q25mr2132136ejd.173.1611302377566; Thu, 21 Jan 2021 23:59:37 -0800 (PST) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id da26sm4659568edb.36.2021.01.21.23.59.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jan 2021 23:59:36 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: "'IPsecME WG'" , "'Sahana Prasad'" References: <03e801d6ef2d$88820f00$99862d00$@gmail.com> <055901d6eff3$6ddf7220$499e5660$@gmail.com> <63cf1275-c7a6-c9e0-c29d-04a11cdbd7f@nohats.ca> In-Reply-To: <63cf1275-c7a6-c9e0-c29d-04a11cdbd7f@nohats.ca> Date: Fri, 22 Jan 2021 10:59:40 +0300 Message-ID: <061b01d6f094$8a53ebb0$9efbc310$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGBSOOV+wJ6j63zYWXgPX4dM31iBwISkvkYAkiCe2sAQts9daq5lLHw Content-Language: ru Archived-At: Subject: Re: [IPsec] Comments for draft-ietf-ipsecme-labeled-ipsec-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 07:59:42 -0000 Hi Paul, > Again, this was the result of discussion in the WG where you were very > insistent on how to interpret and send TS payloads. So I'm a little > confused about this being an issue now. > > The text above shows how you could implement optional labels, which is > deemed a rare or not needed feature for most implementations. It tells > you to basicaly reconfigure on the fly. The advantage is that the whole > discusion of "optional" does not leak into the IKE TS negotiation > protocol. If you think it would be more clear if we don't describe > the above option, I'm fine with removing that text. Then I would remove it for the sake of consistency. Instead I would add few words about the situation when one peer supports TS_SECLABLE, while the other one doesn't. RFC7296 isn't clear what to do if unknown TS_TYPE is present in TS payload. I think some implementations would return TS_UNACCEPTABLE, while other may omit unknown traffic selectors in response. > >> Implementing "optional" ones by using a zero length label is asking for > >> implementation problems. Especially when people consider these labels > >> as strings and run strlen() on the empty (but NULL terminated string) > >> and interpret that as wildcard. > > > > Well, people will consider meaning of the security labels in accordance > > to what is written in the draft. If we try to envision every possible mis-reading > > of the documents we'd better not to start writing them... > > It is not about misreading the document. It is to ensure there are less > conditions where there is ambiguity. Does a NULL TS_SECLABEL mean "no > sec label" or "optional sec label" or "wildcard sec_label". We can write > it clearly in the draft, but it is still a flawed concept. The clearest > solution is if you want no restructions on sec_label, to not include any > TS_SECLABEL traffic selector. Removing the zero length from being valid > makes it very clear this cannot be used for anything, including meaning > "a wildcard" or "nothing". If you want a wildcard, you can send a > TS_SECLABEL containing the string "*" (and then figure out whether it is > a single character label or has a string NUL termination :P ) > > > And BTW zero length means that there are no any content, including NULL terminator :-) > > I bring it up because it is a real danger this will get badly > implemented. And it already is. The Linux kernel takes these values in > a struct: > > struct xfrm_user_sec_ctx { > __u16 len; > __u16 exttype; > __u8 ctx_alg; /* LSMs: e.g., selinux == 1 */ > __u8 ctx_doi; > __u16 ctx_len; > }; > > So you specify the label with ctx_len. Yet the "ip xfrm state" output > shows a trailing @ character, suggesting it is already treating this > as a NUL terminated string. Oddly enough, the output of "ip xfrm policy" > shows the same label without the trailing @. > > This is why I originally had stated that the label could not contain a > NULL, but during the process, all this got removed for treating it as > an opaque blob. The libreswan implementation, which uses "strings" of > SElinux values, checks for embedded NULLs and rejects these. But that > is arguably part of the "label consumer" and not IKE. > > >> Since there is no use case, and significant implementation danger, the > >> document makes an explicit case to reject these. Our implementation > >> will return TS_UNAVAILABLE if it encounters any zero length TS_SECLABEL. > > > > No, the document does allow optional security labels, see above. > > Not really. It says you first try negotiating "with labels" and if that > fails try to negotiate "without labels". That is different from > supporting a negotiation with optional labels. What is the difference? If using security labels were mandatory for the initiator it should have failed after the first negotiation and never started the second. > Again, it was you who was very strongly of the belief that optional > traffic selectors should not be allowed and that one MUST pick one > of each TS type. And that you must be _selecting_ on something, and > you cannot select on nothing. I don't see any contradiction here :-) If you allowed zero length TS_SECLABEL to mean "no security label" and initiator included such a traffic selector (along with non-empty TS_SECLABEL traffic selectors) then the responder which didn't want to use security labels for this SA would pick and return an empty TS_SECLABEL. If it returned no TS_SECLABEL at all, it would have been an error. Since you strongly object, I'm not insisting on this capability to negotiate "no security labels", it's only an illustration that I'm consistent in my considerations :-) > Additionally, an implementation accidentally outputting an empty label > into the TS_SECLABEL payload should not introduce a wildcard label in > my opinion. It is just a little safer for them to need to create a "*" > payload. > > >> The case you describe is very unlikely. Either the endpoints wants a > >> label or doesn't want one. optional security is not security. > > > > Then why text in 2.2 allows the initiator to choose between using them > > and omitting them? Isn't it exactly what you just described as "not security"? > > It just describes something you can do with any new Traffic Selector > that will ever be introduced to IKE. You can always try it with it > first, and without it as fallback. It is not a propery of TS_SECLABEL. No, the text in 2.2 refers to Security Label traffic selector only and not to any new TS_TYPE. > >>> Another my concern is that draft allows security labels to differ > >>> in TSi and TSr without giving any possible semantic interpretation for this. > >> > >> Correct. But the label is clearly defines as opaque to the IKE layer. > >> The IKE layer should not be making any kindds of assumptions or > >> interpretations, but just relay this to the underlying label security > >> consumer (eg in our case the LSM of SElinux). Note that our > >> implementation only supports symmetrical labels so far, because > >> that is how SElinux labeling works. But the protocol can accept > >> other methods. > > > > I still prefer _some_ words to be added about _possible_ > > semantics when seclabels are different in TSi and TSr. > > Please provide text, but be aware that the document treats the label as > opaque to IKE. Please, see below. > >>> This looks weird. I think that at least some possible interpretation > >>> of such situation must be given, e.g. TS_SECLABEL in TSi is used > >>> for traffic from initiator to responder and TS_SECLABEL in TSr > >>> is used for the return traffic. In this case it is clear that > >>> they can differ in some situations. > >> > >> I'm not sure why this is not clear? TSi and TSr entries apply to > >> one direction. TS_SECLABEL does not change that. > > > > It's unclear what this case could mean: > > > > TSi = ((0,0,198.51.0-198.51.255), > > TS_SECLABEL1) > > > > TSr = (((0,0,203.0.113.0-203.0.113.255), > > TS_SECLABEL2) > > > > It's true that IKE doesn't interpret seclabels, but it usually > > does some sanity checks and as implementer I'm not sure whether > > this is allowed (what does it mean?) or not. > > > It just tells you that both endpoints will apply the specific label > to the specific IP/proto/ports range when receiving these packets. > > I mean, it could even mean a specific group, eg group "seclabel1" and > group "seclabel2". eg: > > TSi = ((0,0,198.51.0.0-198.51.0.255), > "jeeps") > > TSr = (((0,0,203.0.113.0-203.0.113.255), > "awacs-plane") > > And the jeeps could only accept awacs-plane traffic, and the awacs-plane > could only accept jeeps traffic. Well, that exactly the sort of explanation I'd like to see in the draft. Can you please add some words along the lines of the text above (and with an example)? > Sure, in my use case, these will be symmetric, eg: system_u:object_r:ipsec_spd_t:s0 > > >> How about this clarification: > >> > >> A responder MUST create its TS response by selecting at least > >> one of each TS Type. One exception is that a responder MAY omit > >> a TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE as long as at least > >> one TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE is selected. > >> Furthermore, a narrowed TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE content > >> set MAY be selected. > > > > Much better, thank you. For best clarity I would have added a sentence that this draft > > doesn't change a logic described in Section 2.9 of RFC 7296 for > > types TS_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, it only > > defines additional rules for how TS_SECLABEL traffic selectors are negotiated. > > The idea was to update the TS handling in general for new TS types, not > just TS_SECLABEL. So that new TS Types in the future do not need to > update RFC 7296. So how about this change: > > A responder MUST create its TS response by selecting at least > one of each TS Type. For this selection, TS_IPV4_ADDR_RANGE > and TS_IPV6_ADDR_RANGE are considered one (IP) type. That is, > it is valid to choose 1 TS of type TS_IPV4_ADDR_RANGE and zero > TS of type TS_IPV6_ADDR_RANGE. TS Types supporting narrowing > may be narrowed down upon their selection, as it described in > Section 2.9 of RFC 7296. I think the text is good. But I'm a bit concerned with the idea to define general rules for handling new TS types. In particular, you draft says Each TS payload (TSi and TSr) MUST contain at least one TS_TYPE of TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. which is a wrong requirement, since IKEv2 is already used for negotiation of non-IP traffic (see RFC 4595). I think it is better if you only define rules for negotiation of TS_SECLABEL. If you still want to define general rules, then the text must be more accurate, not breaking the status quo. Regards, Valery. > Paul From nobody Sun Jan 24 17:54:03 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740023A0B56; Sun, 24 Jan 2021 17:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 h_GtstsG7nhp; Sun, 24 Jan 2021 17:53:57 -0800 (PST) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (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 2BD303A0B55; Sun, 24 Jan 2021 17:53:54 -0800 (PST) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4AC861B0011D; Mon, 25 Jan 2021 03:53:51 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1611539631; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oUDg3MkYOwaJE3rGDdwJJnVPNz2QWtjk349ms7wVTKM=; b=Tf4Glvgay/t0z9MKV0cHZLkO9sdR4XjJ8wRqOuVY4Tjvq8xWTQXUduZDd2kMQpruOr6Xhv 3sy0I9tID0D9shLhTU18603VFcCoGM3fv19QqyRZ/iDu2pw4u4K/fU/iCpGG9SVBu1meWS Wgyc3+oDiYbEd0jlXC008pRx0yQnOD5/pNp12dRpP2r/N7l82zqvw797meZrqBfXyd4BXi /TFlwkdAkyl//RSeX2u2cq06ZsggUvb3jTqObLYGvyZdHrsns+Dp4eyPDDpSDuvzyXSvrn MUEDGyZ1g8tF1HsuSesVH+K6R3Y+WzHeLIRAak0ehumyGCf6jGjwSwQPhJlScA== Received: by fireball.acr.fi (Postfix, from userid 15204) id EA52225C0EDC; Mon, 25 Jan 2021 03:53:50 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24590.9390.935661.778409@fireball.acr.fi> Date: Mon, 25 Jan 2021 03:53:50 +0200 From: Tero Kivinen To: Christian Hopps Cc: ipsec@ietf.org, draft-ietf-ipsecme-iptfs@ietf.org, Joseph Touch In-Reply-To: <35741F85-18EC-4460-A320-316BD216A083@chopps.org> References: <24580.43954.709072.153522@fireball.acr.fi> <35741F85-18EC-4460-A320-316BD216A083@chopps.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 13 min ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1611539631; a=rsa-sha256; cv=none; b=A0JwAoebwBzyLqSBCtOW00d1cNFCplJaa1cerIenHZDO795RYpn78tK+ZAToiIsO2S+Td5 y25z/q8rtVoAP6aNxgUTjXjyl97/MUV3NavNUSAJdxjJX4v7zZyW7K68QlkRbk+sFKF0Wo g5JqntHX0/Y1C4xMNGpgZNpxEGo9by0ubptHIwpQZOsvYxGsZdG28rqf+1f4IlD4OLX9V1 52jlwBnODNUjYukAFBcS0AdzuTkpasjRVUyvV72WqyGORx9GWfBf28hcYhatrGNIP2a/tJ angAV5/DydnKmClc6/OGDrFEhETOvK4DCgclxDkwcE8Z/xJ+OrygeotBHeUVhw== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1611539631; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oUDg3MkYOwaJE3rGDdwJJnVPNz2QWtjk349ms7wVTKM=; b=epBydxxrgoHngd5lpd2PXpJ1T+CGul0uEfXzpVystI1MK9VwhQI3KlvMPrYpmOGsTyRsGp SnJyh+2WP/H/uqyo1ZLIp+9/Fes8TdWHYSuSk/77mEdn9+IflH9MrFkjjmskOyMPTBQEey ycPvCOqN4ajvNVYOAlPCyLdsxkj8DWqmi+yfF7ODiYOTrt6PbiV1aE6v0GjePYcK0qhnJ/ zgi9dIUiCpduoTv9mEc2IWuELgx9+jELwClm5j0wCXGmmAhCHU9qqq/No90r4Cr6TlV9hu zVOi12ezUlZ35maFoaJ59UWgKWQOMQU2JWwtWqHjAZlw72Ea8OjgJ8Yn/YUJFA== Archived-At: Subject: Re: [IPsec] My review of the draft-ietf-ipsecme-iprfs-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 01:54:02 -0000 Christian Hopps writes: > I have published a new version of the draft which I believe > addresses the issues you raise in your WGLC readiness review below. > As such, I'd like to request the document enter WGLC. Thanks, I will start WGLC soon. > The lack of the assumption is also more clear with the additional > text about the window sizes when both IP-TFS and replay protection > are in use. Yes, the new text seems much better. > > I think we could just say that when using this detection of replays is > > mandatory and that replay window and the reassembly window are same. > > Continued to leave the option to use replay protection or not to the > user. This change isn't required so I'd rather leave it as optional > as the base ESP spec does. Actually the way you do reassembly already does replay protection, as if you receive frame with same sequence number you have already received you drop it. Or can you explain when there would not be effective replay protection enabled when IPTFS is enabled. It does not matter whether the replay protection happens in the IPsec replay protection window or in the reassembly algorith, the offered functionality is same. > > In section 2.3 why does the text say: > > > > In other words, an SA that has > > AGGFRAG_PAYLOAD enabled MUST NOT have non-AGGFRAG_PAYLOAD payloads > > such as IP (IP protocol 4), TCP transport (IP protocol 6), or ESP pad > > packets (protocol 59) intermixed with non-empty AGGFRAG_PAYLOAD > > payloads. > > > > why is that restriction with only non-empty AGGFRAG_PAYLOAD payloads? > > When can empty AGGFRAG_PAYLOAD used intermixed with other payloads? > > Added sentence explaining this and referring back to "Empty Payload" > section which also explains this. This I do not understand. I assumed the congestion control only covered the IPTFS SA, and it was done per SA bases. How does this congestion control work when it is controlling non IPTFS SAs? Why do you need it if you are not doing traffic flow confidentiality, but are only sending frames based on the normal traffic patterns, and the normal congestion control functions should work normally without issues? > > Also it does not mention whether frame is allowed to to be fragmented > > across the old and new SA. It should say that as sequence numbers are > > different for the SAs, the packet can never be fragmented so that part > > of it is in old SA, and part of it is in the newly created SA. > > Added sentence saying inner packets should not be fragmented across > different SAs. I think it should say that implementations MUST NOT send initial fragments of an inner packet using one SA and subsequent fragments in a different SA, as allowing this would make reassembly much harder, as it needs to check that the older frames are the last ones to be sent on that old SA, and there must not be any others after them etc... I think it would be better to just assume that those SAs do have separate windows, thus fragments can never cross over from one SA to other. > > In section 2.2.4 draft says: ESP payload length is equal to the > > AGGFRAG_PAYLOAD header length. This would indicate that this packet is > > not the same length than other frames. I think it would be better to > > say that this has just the AGGFRAG_PAYLOAD header, and then rest of > > the frame is padding. > > These are only used to transmit congestion control information back > to the sender on non-IP-TFS SAs, there's no reason to pad them out. So these packets are not same size than others, thus outsiders can see that these are congestion control information frames, and not real traffic. Can they also get some other information of the inner flows by analysing those empty frames? > Once again I believe we are ready for WGLC. I will start 3 week WGLC on the document, ending 2021-02-15. -- kivinen@iki.fi From nobody Sun Jan 24 17:55:20 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34503A0B58 for ; Sun, 24 Jan 2021 17:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 qc18ekkGNTBJ for ; Sun, 24 Jan 2021 17:55:15 -0800 (PST) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (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 C3B943A0B56 for ; Sun, 24 Jan 2021 17:55:15 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4EB721B0011D for ; Mon, 25 Jan 2021 03:55:12 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1611539712; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=dR12nc/xRNvqYMklSEG8nN6eMPSqRtsBEEZ9by4wXAU=; b=fMUc+98G51AD9Sm9agDCnmH7JUTYEgIdjh2M61C6yT2scqz80xTfRyZbjQcUWXN2iGVIHZ 6O3AskV5WpbD98XSDYvpidymX5P7VIGOZBytqneRjWXseD3sbkBjFOoGksXqquDpav1crl QfTCKULRIAx4OImNUSJ/T4S1Q5qJ3g82tDywo0idM4W4RwmeQczmbZEVtsvcgyEjFJASz/ hYsmcnIAiLl03AApBNGje7jWcx+zrZgqswPVvC45kYgfNXgOBf+8t0/+4Hvww2i2nXYqRL AIMi4CvRUh8jvSj/vnPHmfid6qbMhIH8+/wT6jKQcQT8FUysWGZNRw+Bx6z5Vw== Received: by fireball.acr.fi (Postfix, from userid 15204) id 04EAA25C0EDC; Mon, 25 Jan 2021 03:55:11 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24590.9470.995873.674029@fireball.acr.fi> Date: Mon, 25 Jan 2021 03:55:10 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1611539712; a=rsa-sha256; cv=none; b=ueesYi9Rfznhb36xo1p57CGlpJeAoUR9aTH48ufbna+pE+vxmNlCj+ASs5575anqPfjDuK NJEYxm1Xxp5xvCbh2Ht9EPBk7XxMT619ZgiGGIX0yrJSLYPI7IaTBlztNAqN31HN0/HPDF 4TX+mqd3bqYq5CUOQDRjRSUef/qCnoO3K1Q43M31ckBgOsOKKVHoGcsTJE6GnNP5SjV5tw WHGNW3TSY2/Z8gUC/GjXB4GEXAEwAXeWE3BfW3YPJ24K/Hy34FmGl8ImvzFL98/wLvYXoh HSjtlhzCQT66UxF+8GSOWA2JZfgAhYNvPqDcWoi7/8sdR9UPpKxY6IFyFwtNVg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1611539712; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=dR12nc/xRNvqYMklSEG8nN6eMPSqRtsBEEZ9by4wXAU=; b=YIVxKVAuLyPljQz7AOUNR6EUbqGpg9q1Jy66ei0YQ05PC6C0WC3VRUmuZzOaxZnm64bXZH utPWKWiAhiWYE8cNt9QDecIfAMrEww/v+vPmpdgmKlO4Hjk15gU5FEMM0q/V0Nm8l0uxHy 6lj/ImGpgm2Kj0HypwjCujux8spWdunfLrlFlIsTcplCP/UvFiTkwLclE4aUCZziNncete TL/t6Boa9STH1DqH2fD4/ihssFrAfHyJJcCzyDMiZFXv4FOTt+ylAzOOJ18W2zZnpjiNYD 9z1U59/ZRORSGrBWpMcMYxeyl7oy83wfrwUI6ftv2fxV2vQr+U2FiKzib6P9UQ== Archived-At: Subject: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 01:55:19 -0000 This is the start of 3 week WGLC on the document, ending 2021-02-15. Please submit your comments to the list, also send a note if you have reviewed the document, so we can see how many people are interested in getting this out. -- kivinen@iki.fi From nobody Sun Jan 24 17:56:19 2021 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 019EF3A0B63; Sun, 24 Jan 2021 17:56:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161153977799.31720.5205812267540832766@ietfa.amsl.com> Date: Sun, 24 Jan 2021 17:56:18 -0800 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-fedyk-ipsecme-yang-iptfs in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 01:56:18 -0000 The IPSECME WG has placed draft-fedyk-ipsecme-yang-iptfs in state Call For Adoption By WG Issued (entered by Tero Kivinen) The document is available at https://datatracker.ietf.org/doc/draft-fedyk-ipsecme-yang-iptfs/ From nobody Sun Jan 24 17:59:39 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBC73A0B92 for ; Sun, 24 Jan 2021 17:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 1h-RwHWwgMAU for ; Sun, 24 Jan 2021 17:59:36 -0800 (PST) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (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 255543A0B8F for ; Sun, 24 Jan 2021 17:59:35 -0800 (PST) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id D6C3E20244 for ; Mon, 25 Jan 2021 03:59:31 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1611539972; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=dlrYFNDo29tBkJ91l7Y1kpFtSs4p2EwXX+dUw9fJKjc=; b=hC5gXt1aQLqWpsjlN/YYvIHOIVTmzefExZeSlk0SA25xkL+nfHrItGyWBLneAcAOsOKcdt nOB7NUu1h+polrSHIUpRpYz3A0GvgCm0eDyyUi4KWm8MLKoIe4f2BNYjOaGpCCr9k8EZuU FLhn37NDm0RI7qM3bpWcb5EtdTDkgqc= Received: by fireball.acr.fi (Postfix, from userid 15204) id 9506725C0EDC; Mon, 25 Jan 2021 03:59:31 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24590.9731.586561.210161@fireball.acr.fi> Date: Mon, 25 Jan 2021 03:59:31 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min ARC-Seal: i=1; s=meesny; d=iki.fi; t=1611539972; a=rsa-sha256; cv=none; b=pFchzqeLBRhbMj0F98T51WrfpLmfZB8fZqocxAPPEAZ7nKubzTQRyr0CtISOcocgTHbC+E G2/MLRPPMJAvre9qO5Gss4752VAyGeXE4wrRE2+qEunJYy5Ek595t/XNCfDGyvXcC27T43 9RZmyjnad2bE/VZIFvC0mQzhdYc1BUY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1611539972; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=dlrYFNDo29tBkJ91l7Y1kpFtSs4p2EwXX+dUw9fJKjc=; b=WjdhP+Pdj4JQNX5KYDki233w5gVaVC0T5vs9gvMLgkyBKohaRXfQjyBSyIuLrPreNbD0u4 stpurRwlT8/1UlZjqU4pjjMsyYlHLI7366bbIdMbHGGNgWIKAgayCNTK38ZbNSSo4rrfLM fNWdY22eVm3Scm+ChKuwApbgS+FBYHI= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 01:59:38 -0000 This is the start of 3 week WG adoption call for this document, ending 2021-02-15. Please send your reply about whether you support adopting this document as WG document or not. This document is not explictly mentioned in our charter, but as this is part of the traffic flow confidentiality work that is part of our charter, I think this is something we can and should work on. -- kivinen@iki.fi From nobody Mon Jan 25 02:27:44 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D131B3A0E3B; Mon, 25 Jan 2021 02:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4DKbAv7cEFua; Mon, 25 Jan 2021 02:27:41 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF7D3A0E3A; Mon, 25 Jan 2021 02:27:41 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 75C2E60F67; Mon, 25 Jan 2021 10:27:40 +0000 (UTC) From: Christian Hopps Message-Id: <42C64F26-0893-4E33-9458-A705F478095B@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_84C9AC85-6550-4D63-94B9-BA7A3653F692"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Mon, 25 Jan 2021 05:27:38 -0500 In-Reply-To: <24590.9390.935661.778409@fireball.acr.fi> Cc: Christian Hopps , ipsec@ietf.org, Joseph Touch , draft-ietf-ipsecme-iptfs@ietf.org To: Tero Kivinen References: <24580.43954.709072.153522@fireball.acr.fi> <35741F85-18EC-4460-A320-316BD216A083@chopps.org> <24590.9390.935661.778409@fireball.acr.fi> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [IPsec] My review of the draft-ietf-ipsecme-iprfs-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 10:27:43 -0000 --Apple-Mail=_84C9AC85-6550-4D63-94B9-BA7A3653F692 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 24, 2021, at 8:53 PM, Tero Kivinen wrote: >=20 > Christian Hopps writes: >> I have published a new version of the draft which I believe >> addresses the issues you raise in your WGLC readiness review below. >> As such, I'd like to request the document enter WGLC. >=20 > Thanks, I will start WGLC soon. >=20 >> The lack of the assumption is also more clear with the additional >> text about the window sizes when both IP-TFS and replay protection >> are in use. >=20 > Yes, the new text seems much better. >=20 >>> I think we could just say that when using this detection of replays = is >>> mandatory and that replay window and the reassembly window are same. >>=20 >> Continued to leave the option to use replay protection or not to the >> user. This change isn't required so I'd rather leave it as optional >> as the base ESP spec does. >=20 > Actually the way you do reassembly already does replay protection, as > if you receive frame with same sequence number you have already > received you drop it. Or can you explain when there would not be > effective replay protection enabled when IPTFS is enabled. It does not > matter whether the replay protection happens in the IPsec replay > protection window or in the reassembly algorith, the offered > functionality is same. Right. =46rom an operational point of view I figured it comes down to = whether one gets a specific type of log message/alert. >=20 >>> In section 2.3 why does the text say: >>>=20 >>> In other words, an SA that has >>> AGGFRAG_PAYLOAD enabled MUST NOT have non-AGGFRAG_PAYLOAD payloads >>> such as IP (IP protocol 4), TCP transport (IP protocol 6), or ESP = pad >>> packets (protocol 59) intermixed with non-empty AGGFRAG_PAYLOAD >>> payloads. >>>=20 >>> why is that restriction with only non-empty AGGFRAG_PAYLOAD = payloads? >>> When can empty AGGFRAG_PAYLOAD used intermixed with other payloads? >>=20 >> Added sentence explaining this and referring back to "Empty Payload" >> section which also explains this. >=20 > This I do not understand. I assumed the congestion control only > covered the IPTFS SA, and it was done per SA bases. How does this > congestion control work when it is controlling non IPTFS SAs? Why do > you need it if you are not doing traffic flow confidentiality, but are > only sending frames based on the normal traffic patterns, and the > normal congestion control functions should work normally without > issues? Correct the CC is only covering an IPTFS SA; however, the receiver has = to send back information to the sender for CC to function, that is what = the empty payload is for, to send the CC information back over the = non-IPTFS SA. This is only going to be used when the user has configured = IPTFS in only one direction -- we're covering all the bases here. >=20 >>> Also it does not mention whether frame is allowed to to be = fragmented >>> across the old and new SA. It should say that as sequence numbers = are >>> different for the SAs, the packet can never be fragmented so that = part >>> of it is in old SA, and part of it is in the newly created SA. >>=20 >> Added sentence saying inner packets should not be fragmented across >> different SAs. >=20 > I think it should say that implementations MUST NOT send initial > fragments of an inner packet using one SA and subsequent fragments in > a different SA, as allowing this would make reassembly much harder, as > it needs to check that the older frames are the last ones to be sent > on that old SA, and there must not be any others after them etc... OK. >=20 > I think it would be better to just assume that those SAs do have > separate windows, thus fragments can never cross over from one SA to > other. >=20 >>> In section 2.2.4 draft says: ESP payload length is equal to the >>> AGGFRAG_PAYLOAD header length. This would indicate that this packet = is >>> not the same length than other frames. I think it would be better to >>> say that this has just the AGGFRAG_PAYLOAD header, and then rest of >>> the frame is padding. >>=20 >> These are only used to transmit congestion control information back >> to the sender on non-IP-TFS SAs, there's no reason to pad them out. >=20 > So these packets are not same size than others, thus outsiders can > see that these are congestion control information frames, and not real > traffic. Can they also get some other information of the inner flows > by analysing those empty frames? See above, but these empty payloads are not being protected by IPTFS = they are just for transmitting required info back to the sender. >=20 >> Once again I believe we are ready for WGLC. >=20 > I will start 3 week WGLC on the document, ending 2021-02-15. Thanks! Chris. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 --Apple-Mail=_84C9AC85-6550-4D63-94B9-BA7A3653F692 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmAOnRsACgkQLh2DDte4 MCXnUQ//T5YoqqSFfIM+2h4q8q1xwBCy1RabpuIU3JUV9b9SieJdkH+IlgPYcUVx 9v+st3mnt9uCqOQCuBRIghsFujcF0RIxv73eFbv+eh3xpqaV0P4h6HxvkRR/sI/K o6kflqfxi9/Fb8qQMAlx5AoXgU46np3gpAWjmM2TK64UmrnYcBuA2pswfFUty+Tb sjnuUJDLyx6uANVHyCRqt1KCZ3kIQI0gwCifb20ja6qMAsuQa/N8C3UFdwFCAZvJ ViZKF23Pp9avLLKspEUVGMcClKT3IGxNov5hNhAyQW6eSyQE1h3eVd5W3+zi5Z2G vDORbMnlVD+zGx9+1vbqkZbkauSTjA0hLD+gaWgvToZEaCTr8GIwuUlVzL41urFF qonXr9i3PHJVu2GoXDByVMe963fheEMGUPH2VA9n9MTdk9EECy+OtTKjWouxKMIY mQCOPXmt8v0m0VHO0Kp0Wr3ZiVc1fUoklpl9xaCv98X6KTjVZxU6vlQS/V/3jlyU Ltueq3Y19iw4YO/j+LZCs8P368YrwOffy0LvAlYcjKf/tzM8h2X+QZKs1YWHzEvP KOYXlfe+VlVySkv0o2ezVhNrFwtm+D+H2E3hGtRKXHnhpj/+A02qQm44cOQRlp9U kqQfVuqFcaqUPHK8OitOj/Z6BZZ+XnVRREBS3Vxb5WtP/7pDTWo= =aI6u -----END PGP SIGNATURE----- --Apple-Mail=_84C9AC85-6550-4D63-94B9-BA7A3653F692-- From nobody Mon Jan 25 06:04:21 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9D23A12F3 for ; Mon, 25 Jan 2021 06:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.onmicrosoft.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 NQ3j3LAIJNMa for ; Mon, 25 Jan 2021 06:04:17 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2131.outbound.protection.outlook.com [40.107.244.131]) (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 A6D5F3A12F1 for ; Mon, 25 Jan 2021 06:04:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aJ6gF4tX751FlR+01+4erPgPg9X9VX2GmdRgY+DLlvAEG2DmY/SoADxi4WMv0MydC1U9UHwJydVNGpue1p6x7aaujCuDrOE+ciVjafZnsJoqGiGWLMPc1OqrKky2xfBaEXhOOXxy8hvBPqUTPlBprUgYVYfApTOH7y+VjXfiNZkTa8pbP01sy/+qcRsLXu+oclYELQoRTILsO3uI5A2OqDqxfzn4qmnAdBvt5olI+juRDnnb5pyD4fy9FPJKALX/9u+XVBemSY1nxwslPipsleLGW4yOwmx3HyyUCYN8DJLTPDdEJ/SkC40oxW1cidTS7e0x9nAccjnY6jaRXBSYFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KTq9LKPNfn15mnoaoFKcUVLFp7sg/Wbf2s0neqcOfdI=; b=Q3b2vAle+SI86tzPLwghUu3x+MfdzmbldLL1D3mHginN3fIyiDnD7RoQg0Ru/N7Cny4O7MwVsWTD93my3RUvfX36cENFFFcw2YfELxRQH/ftvRb6RicSUMEH1t7REewiE+Bm9b/Y6bvbZyz5mdzQinkj96cfZPfxMyMC7+ebq28YUQu4Z/cJRZBkTabP0vkSZlpHIF32euC/cdXEavXvf+TnJZGDDh15AUe1o35mUrE9ebANR/nKEqvTgk9KDAJmK6ThgBTh2sfB/EGWGSEMoFN67CzXxjt93YVg+ha7ABKkqfB3op5llui6iPjWDMBW5Ui6Ht78rX9QUVj6GfyU7Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KTq9LKPNfn15mnoaoFKcUVLFp7sg/Wbf2s0neqcOfdI=; b=ghx1qqTliQZhqBZRGU+C12Wgn6PQ4PE8h24GdHM9QDOE6Vrl92pj3lCmAHiFP4P7dIR5exAL3YruvzYIQkvkSjXdZbpPaCodsmLL6WUxV6mW4vgVBHvcrL3/zH8JOpybDH4Gqtk1W3mdBVhmWEuaZFayA4TaQSv5lUyZtrfNfA8= Received: from MN2PR14MB4030.namprd14.prod.outlook.com (2603:10b6:208:1dc::14) by MN2PR14MB3344.namprd14.prod.outlook.com (2603:10b6:208:1a7::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.13; Mon, 25 Jan 2021 14:04:07 +0000 Received: from MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4e7:7c3b:27f7:380a]) by MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4e7:7c3b:27f7:380a%4]) with mapi id 15.20.3784.017; Mon, 25 Jan 2021 14:04:07 +0000 From: Don Fedyk To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs Thread-Index: AQHW8r3CP5T6pbGiZEC5ACQoiUA5ZKo4YD4A Date: Mon, 25 Jan 2021 14:04:07 +0000 Message-ID: References: <24590.9731.586561.210161@fireball.acr.fi> In-Reply-To: <24590.9731.586561.210161@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=labn.net; x-originating-ip: [173.48.105.206] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 090aa4d0-49b4-4857-03e8-08d8c13a14ea x-ms-traffictypediagnostic: MN2PR14MB3344: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xpdzyrA97pULIW3z8+FHNii0aMfAxIi09o3qhRUwxc/w+WhS26ki+DRq26lDSy1Uo5j4oHYlnZCKJGsJSKFh3NtH4TaxHq7gR1qJobbUgw3Ls1Yxw1ZFM8Rw++zUdVJ41a1L6tsCaCgVMigYvn0XpLfLS9yZr8WE0gWUdqvJxCWBgfDW4cBTJd9mydy/ThAvaUT6oks3Y5K62tHL6ho3J+7YEqI3OXok4SETdxzzaGI0umX7lo+xwKGbLkOuzUsilZH6MJmwt6xy5qgZwNAAmtgtT/X/wVjn5PU29IrddwW411qNGETu6PXs/93VvwCvyHG0siObZMpnvngCkwZ8nDYNAzx34ubZ/5ttTbNEoBvrUSR0CWajfhAjpAWbW22SpZXJfogsA/FCg5E+sTs5TCQMT1Lryumw/uFXRNDjJ8xuYWN5VehDNTjU35Ygga8vD4lou+rmqbR8CmDhe5Xnow== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB4030.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39830400003)(396003)(376002)(366004)(346002)(316002)(33656002)(26005)(478600001)(83380400001)(71200400001)(52536014)(8936002)(110136005)(8676002)(5660300002)(55016002)(9686003)(7696005)(66946007)(66446008)(66476007)(66556008)(2906002)(6506007)(53546011)(76116006)(186003)(86362001)(966005)(4744005)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?kSo7Pn014DvIu/XXIYPJ6e4gXdtYhz9TJnEtn4ErihtKWK0vHkTO4c+Yfk9f?= =?us-ascii?Q?C+zv2RwGwPyhiSOmeyizzROpGYcKaDwhiOYosstvbJ7xToa7XRZwWbUw8u4f?= =?us-ascii?Q?zthoVR7/uuz7lFz5u5IpojXrdWi/gnhqwqWD9EbArJa+ix2+E/oAffKoZKe+?= =?us-ascii?Q?LUisxZ97Y1tVaY3R17eHwqZGp1G5IMih8QMlr8yh4VD1skgo7xqg+ut231r7?= =?us-ascii?Q?j96+F4A+rGFkXrDBJo200jlOUbgItcQw9Cew9oVbgv1Rf9J+Q8NDbqKkSF7+?= =?us-ascii?Q?/PSJUkfdHesfImdZu3Gp4RKyY5w3eUqYx7mfVawesBDPOFIsBYaTiDRWhQg7?= =?us-ascii?Q?hoveVex2+0J3frojKvpYqwiM9wpucaJohSy8sJRS9fLIPtLGDE1Y6NSWUqQG?= =?us-ascii?Q?4GNB7mm9Kw8V3Op2B4gnFVWYTYTtPiO1+tVynOuP7QiJ64UVQ4TWlysr5NnU?= =?us-ascii?Q?/ouAoWMHTDgSqkivS8HJ+V3FvsrGMlvIhC6RWNi4/dOY0mEGAOmiza8mOqe6?= =?us-ascii?Q?aFwJcbtG/G5FmNQLQmIal+rv0QonoAjfQ010gcCiVoWBOhNPj846zsme8na3?= =?us-ascii?Q?dwKkDruambtGXc5W7ok9XoojJUODrNO/uofkuPQyGjhtZcq5Hf2LmAPEXDIv?= =?us-ascii?Q?2s5075cD+1U+BDgPwC9CMfFsAtuSvZ4GEwYS3mOedl0tsB0yBpE0+fFFzTXn?= =?us-ascii?Q?9/u4NX+hFwQgTzLOMS1+x+vnBbBQx82xgiyjIgLEYw13aRFiAXuDmk3LpURb?= =?us-ascii?Q?vIXSQ593QEWYhP6k5xf9QL7u0ecjIM03iswgKrAaPN8o7X3kB2kgklqo1oNa?= =?us-ascii?Q?afK5wmOPkE9LCPdizMKCH3kxlxKMWZ+DfkyiVc8pfXFsTQB6/HoZNcUTsFyq?= =?us-ascii?Q?dRuKC7uPzr1t3h90AlP9IOLuOnlOv/w3imGyODq/hqRxZFnYDvGXec66N8nB?= =?us-ascii?Q?Pqt89DbxpdC1NxWap/FfNG1s+oG+4TjMwdHEGASA238DS7FrALDrj8/Qs+Nl?= =?us-ascii?Q?OYOo4WqmYXNQv9DK8pTmKKMSu9scOrLvcj4WbMWZr21xxqadyNUBnfUZiKHe?= =?us-ascii?Q?ZxtPtByz?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: labn.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB4030.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 090aa4d0-49b4-4857-03e8-08d8c13a14ea X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2021 14:04:07.5542 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: eb60ac54-2184-4344-9b60-40c8b2b72561 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iIN6Ou3lI5e+Y87er+25PEFDD397LoMOg/eaAbT2XN1jg+mD/H4AJ1BR2g6WLj6G1D1xNZscQj0uecitR9bP1A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR14MB3344 Archived-At: Subject: Re: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 14:04:19 -0000 Support as an author, Thanks Don Fedyk -----Original Message----- From: IPsec On Behalf Of Tero Kivinen Sent: Sunday, January 24, 2021 9:00 PM To: ipsec@ietf.org Subject: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs This is the start of 3 week WG adoption call for this document, ending 2021= -02-15. Please send your reply about whether you support adopting this docu= ment as WG document or not. This document is not explictly mentioned in our charter, but as this is par= t of the traffic flow confidentiality work that is part of our charter, I t= hink this is something we can and should work on. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jan 26 07:14:20 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4983A0B92 for ; Tue, 26 Jan 2021 07:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 pP318d6XpDN6 for ; Tue, 26 Jan 2021 07:14:18 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 50C213A0B8F for ; Tue, 26 Jan 2021 07:14:18 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id B564A6020B; Tue, 26 Jan 2021 15:14:17 +0000 (UTC) From: Christian Hopps Message-Id: <04C3BB32-71D3-4CBE-AE43-45FCCC914B0B@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_C6225BBB-EFB3-49F8-B8D7-505C6E9D228F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 26 Jan 2021 10:14:03 -0500 In-Reply-To: <24590.9731.586561.210161@fireball.acr.fi> Cc: Christian Hopps , ipsec@ietf.org To: Tero Kivinen References: <24590.9731.586561.210161@fireball.acr.fi> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [IPsec] WG adoption call for draft-fedyk-ipsecme-yang-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2021 15:14:19 -0000 --Apple-Mail=_C6225BBB-EFB3-49F8-B8D7-505C6E9D228F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Support as co-author, and I'm not aware of any IPR for this document. Thanks, Chris. > On Jan 24, 2021, at 8:59 PM, Tero Kivinen wrote: > > This is the start of 3 week WG adoption call for this document, ending > 2021-02-15. Please send your reply about whether you support adopting > this document as WG document or not. > > This document is not explictly mentioned in our charter, but as this > is part of the traffic flow confidentiality work that is part of our > charter, I think this is something we can and should work on. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --Apple-Mail=_C6225BBB-EFB3-49F8-B8D7-505C6E9D228F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmAQMbsACgkQLh2DDte4 MCUnnQ//Za8JbYz4Z/yfSbl76IZoJeFHYmSrmbw/Lxc7JrvNm3Njubz2cJQ82lnh 0fScFiduSLwuwyQdTp1L0ecg4u5AG9uQb+/uniPsgf5k3jUIVsXbE7+7R8Ck2oEj V9mCO8RJe2KQHj99WLRZT7ZXMW5y2oxcTCtJm1dMo2o3j3M38M1ikZSKC5ZowGPd W6OMp6dotNiyZTT9zurbur0uG6aDqmt5bArQSscoPoe9y+y3eL35ssiGXFgYsz7h 1Bg0zrMWgBvjkKRltgEQSg8C1TNjdf/YC0FO302uWZ3atKWMICuCCGvTjjYbl/2N +Ua1Ud29Fi5nHUZfZbdzEwnGrREvwn+mvzz76Sclqg4hIW86ef5FHKhu364IhWaA AJFEySGRFaRd6W2N/xScs04IAm6hXGm30BOq4zlzpbG7ipyttTGidQ9p0CA3SmZO +qQOPu8YOZc95CX8262Ty7n4BEp5G2gkG8DYhu6hFBmqYu1+oSOBrT5hWhMi3mmJ PVZgQgpnGIsSMT8FuPQMiLgYMQhs50m27dQ2FNB7li17ECiuEO3TwX8yqToTJWmW q4RMqY5WYPfufCwHjxt/JsBJUGunKaDv8BCHEMOL6gzaLtY3vkr+1ry+RrychB1O Jh5eAMklL3jbmflhU/968lMAueSX4LXzG5RBp5I9m70eKpUwBJk= =LA8s -----END PGP SIGNATURE----- --Apple-Mail=_C6225BBB-EFB3-49F8-B8D7-505C6E9D228F-- From nobody Thu Jan 28 10:52:17 2021 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EC83A1604 for ; Thu, 28 Jan 2021 10:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=labn.onmicrosoft.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 0w-MyNYVBvEm for ; Thu, 28 Jan 2021 10:52:12 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760131.outbound.protection.outlook.com [40.107.76.131]) (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 C00363A160C for ; Thu, 28 Jan 2021 10:52:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WtxHrEqAgHvJVhucvfulqJUGBaxV9GczUUlefce7GxxR2yV7ZbiboTaJshtJnzM8qe7onV1lPa22R6Lm53MlWfwbYcEyY352cH1twWxGog0xHz4vHvS632WNX/DH2OdMyGlAHli11JNxFj9lkalZDUTeSn3xEclgzjtrI3+IRBZFJko6GptkD+upfZrw6GhurV+AuN14xDxPUYR1NTdPBZQK16UqOKl03xgHx68eTI6lN5fkhhb7rTwJ8qX5B/eUyzPNCZLWqp6tlM7wFTUN0SBgPkpYsjcI4BFQLgGfcpUAPT0QOamEbMJdbC9CzuKRH+J6ENVQItrNbJT32qsNQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZVPNvXeDJGaFu7yXgFDLjIqVjK4QXNGKtsVBqMxvnI8=; b=lv5YTHJ+e5fNaTAEpEauGZ8GHN2NNA+NzFcZuoOS1J+f8I5XZGJVz8ZuJyS93NESnnCk1XncxqZhS3f41npIj88CtVaaJ/lHs6y82XPLKdOu3WYfvsFIp0rnF1cXEjsiVPrQQV5f73E+xOkmEzkhxABfzwNwPEFliB0suSv809TBsBr8dxPYpYQjkNKK8KAcVKMvrT7uL970kfP/oTirdNABsmDv7jFRFRh5xHmVuKovw2yxZLp88+8wuwicCjKFJ0SHtMJLJ1o8r1jMNfJfYLQnjCt9wm+9mzC1huSR5qHxfOz8pCAabuiL/DUrxy8FkTU2rSh8IpRAb0ijQjVM8g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=labn.net; dmarc=pass action=none header.from=labn.net; dkim=pass header.d=labn.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=labn.onmicrosoft.com; s=selector2-labn-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZVPNvXeDJGaFu7yXgFDLjIqVjK4QXNGKtsVBqMxvnI8=; b=tNgWcV06ITnziLBv7LgplXXeCAAq/As1F+atIZBGROWgH9zNrH/d1n6wICXFhfuChpXnnbGPprK9/Bqsi/7pPJrje6+ZL5NgzeAf81eZ+Z5YZDW1TrWm3FfVwAEpMsoV8CcMxmMCixflmFCVYYKExxEz/D66PCPjywExmGQ/ahY= Received: from MN2PR14MB4030.namprd14.prod.outlook.com (2603:10b6:208:1dc::14) by BL0PR14MB3665.namprd14.prod.outlook.com (2603:10b6:208:1cc::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.19; Thu, 28 Jan 2021 18:52:10 +0000 Received: from MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4e7:7c3b:27f7:380a]) by MN2PR14MB4030.namprd14.prod.outlook.com ([fe80::4e7:7c3b:27f7:380a%4]) with mapi id 15.20.3784.019; Thu, 28 Jan 2021 18:52:10 +0000 From: Don Fedyk To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] WGLC for draft-ietf-ipsecme-iptfs Thread-Index: AQHW8r0nevjhey+rv0eOCG8CNVQUfqo9Z4ig Date: Thu, 28 Jan 2021 18:52:10 +0000 Message-ID: References: <24590.9470.995873.674029@fireball.acr.fi> In-Reply-To: <24590.9470.995873.674029@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=labn.net; x-originating-ip: [173.48.105.206] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aee42e2c-547a-4219-baf3-08d8c3bdd1b7 x-ms-traffictypediagnostic: BL0PR14MB3665: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kLrWU9XW7kkfst+jcv8JjqmMxxe9p/Sb98bSfg9bKGCroQzufS7pVjwNPV93/Wr/Ox/Pv5retCZW12DAGH/9+39yK7t0IV1wlTf54HK9R0NTnuI+gBDiFmr8iLA26RPuELR8Um0MyVcqtHRq2xHzg12VBVV3Td19MTN6kc/O8ifYWZ++sYgCycvk517Qt3yiDKs1drLNQJFIh9bnEMjGBCyrUwSp2PCO0AoHmgO7Jf9Sc4jan2OWhrJUKbLf6Iqzejsf6USxUL/atdfqre4HB0nA05iMbcMrFvItpAcbrIRVDbmlsupifQHLFQl/wPSEvua2oiqFsFgfOxIA3XVLXx9A7ybIHViQTgIBu1Lh5ghG7Pw66a02kyiMD8yN14H1tw+QOAZLSaTD5l5iErb9ZHRZncVRF4UIzJ25fMeNj5MyDiychVtYPSIzujyjYphyX9JXgVquoC4OfTgASUGdP1uasBl6J3P0lNrt3mVT9lApq6aWcxKB6K1am5hbvw3CPmYL8SK4Yrbnkf4IHyW+299Gjsqz6BpdkwpfNQpSgRHhFJ3bE5WrXyGtUJR8NRpji3MeryhaJbNJxzjAvOFgXv+CcZApw76mpNr/F986p4o= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR14MB4030.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39830400003)(346002)(366004)(396003)(376002)(6506007)(966005)(53546011)(186003)(110136005)(7696005)(8936002)(26005)(8676002)(55016002)(9686003)(316002)(66476007)(478600001)(2906002)(66556008)(76116006)(64756008)(5660300002)(66946007)(4744005)(86362001)(83380400001)(66446008)(52536014)(71200400001)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?JHBcxRfNgxfG+A7XMKG5HfZsRKaCCEdeyPIHd9JTP1au/riL7GNcR74hJBsx?= =?us-ascii?Q?CZ4A+PaGvOgEe3J2tlo2YVI235ZoXCOIAJvy2JfqvcG+F7hVFCA+p5o/3M5A?= =?us-ascii?Q?++MSCo6L6yofexP25Hli51RPYke6YaqdtCOYwlbP7QW/6udeoQNXCKNHkSrK?= =?us-ascii?Q?NHSYbretLeTAObA4COgPt0KkvcvaJaYhUGrwiHG/l9KxdAJLy6Of/tCILJjr?= =?us-ascii?Q?GxvIu9aUTxvgphMdzBZlB5sTCRjnVTJZK1Lluofo/X9XCqqjKzWvaFbiEIqH?= =?us-ascii?Q?emFjdi70rAL3X5JfPFXipJqBgtiJgUYjJ+3rRGr91NoxW/BQpDFhDLsuWrsC?= =?us-ascii?Q?oft8rsuBDA56Ihv7wKw4niNoMbhcEAIZiTbpDrgs5xwM3zNtfQwx06fWCAcg?= =?us-ascii?Q?Dmwt7gq2x4cHfYFLD1zdPQKb76sPptK2LQkYyBRAtqrKpvhLHuiwNFtO6p0x?= =?us-ascii?Q?csVvpeBkLQAV7D+WdxUtt1IN/jC5TzeQ/5g1/t+n7x7luLYaL7ZB87zalMyM?= =?us-ascii?Q?XL3yf4/r+zccC6bWEJgmbIBtOH/U/xhMrWZP2KiedyMtWskZot5Oo1ekRgTi?= =?us-ascii?Q?I4QC8O98FXoGj6u5DRQDjCoIWvWFAU+/jzWR+bgzj1BSbkgPmcx+8i0MVEA9?= =?us-ascii?Q?DM5St5O6TZTERYb+236EzCB4IrM89IUGGxmnMrCgANvOVc2i5k/OarHlsNxc?= =?us-ascii?Q?r/ZgoNoN9g3I9/7/oc58C/NLSqpQl/3gY9zyM8PisLjSSz2M+WveqMGgOWCD?= =?us-ascii?Q?ZlKGnL2bPCIiZWJcN3x77xey79zwEwAZirKqs7nx0h0ymhkauYkPVcYErK4i?= =?us-ascii?Q?wFQWIWGSQ603PHdxG1jpyyr+tRhV0aZiTTK6H0xkGlYFDrKBnaDzH1qM2F9e?= =?us-ascii?Q?tiG8L0TBqo/17K/Kg4Fo0iiu8RZUKY4Ki6x6oVZEWfsYKvrfzyi3qk8acCxm?= =?us-ascii?Q?6IroWgdkwSAsksZprv6JT5W/zB4wTSeYPA1Q1fKForLFoEEaJpQaxNY4ux1w?= =?us-ascii?Q?pD/Hijqo/rD5t3G/8QZv+0Tmn3YDs+USq8R2rH4YNyXBDBLuGuDwBcE2hxSF?= =?us-ascii?Q?9l1PcOx3?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: labn.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR14MB4030.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: aee42e2c-547a-4219-baf3-08d8c3bdd1b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2021 18:52:10.5877 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: eb60ac54-2184-4344-9b60-40c8b2b72561 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: isk55icx97IBcM7zdCfJ2uLqDY6z8zUo3BGl4Mxb4eUSrbGJ7kqmXMbXdKfUz6Ie0qQjKEFRLI6Es/Z0w2CHhA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR14MB3665 Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-iptfs X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 18:52:15 -0000 I approve. I have reviewed this document.=20 Cheers,=20 Don Fedyk -----Original Message----- From: IPsec On Behalf Of Tero Kivinen Sent: Sunday, January 24, 2021 8:55 PM To: ipsec@ietf.org Subject: [IPsec] WGLC for draft-ietf-ipsecme-iptfs This is the start of 3 week WGLC on the document, ending 2021-02-15. Please submit your comments to the list, also send a note if you have revie= wed the document, so we can see how many people are interested in getting t= his out. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec