From nobody Thu Dec 3 08:37:44 2020 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 D444F3A00E0 for ; Thu, 3 Dec 2020 08:37:42 -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, HTML_MESSAGE=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 rr-2AcE-wVTV for ; Thu, 3 Dec 2020 08:37:41 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2134.outbound.protection.outlook.com [40.107.243.134]) (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 5BEE43A00C9 for ; Thu, 3 Dec 2020 08:37:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Sbv46VfrGCKh5Fce6+pfi7A2AA5Qdcn8uGa88ITxQ9T6flVjTKekQUVvwQWgW/tcWedI16jHdagDuRpJpy37cpLgeAqxuoxmsOfTM8l+t90XLKDmgg9BxH8ofD83WoKYFejBX5GJIrc2zTnsNN2dtmlebHRqQiYAMVdlshR6NY5pGWGTZXkLBvEmKQKOp184haIZgvVnx7nQTP+eJnAIG8AnRgZXzAmf358BWmU44Qn8lhz/yEXp+luFrYWMnQ6dBd4ZyipWHdOEDwUKDxdmQoWvYSyzohlAKyOHv8j7hiLT1VqD7Qq/VVbJeADa/LBY1MfNMkkikFQlbl0GZK+pBQ== 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=R60u7PlkyoQVOJUFeC1CZAu23oOArF0eI+xpnnMqefo=; b=mFg/okjGykBdx+e9uHQ/abVQRDaR0rh+rPtrt/8m295VOtbV1ZBw7Y5aT2B51ZM7m62+gVxyPmdOhpHShRYE/yqZHFRMELdRlGOj59n2luRzth5tilEF6eSrd2y9a4j0ZdHZYyLVWBIMpDcoZNkWrfHa02CZAbfxc/CWb8z+E5TmgR0nRZZL34R0E7d9IDx91KKfFufCKujnmsk2Hwnq2NDUQtZ1ZlWczjmEFYedS24p77lGitHuIE/HwOdFFi+9HhkoJLF+PSwCaemP+eG3RepZFnSM1MBf5pvTFVz6n8EAVvWRDG8wx+sN10/IUdO6X9WKcWC/BtBZ3vQJh0JHZg== 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=R60u7PlkyoQVOJUFeC1CZAu23oOArF0eI+xpnnMqefo=; b=u/bHp0MnXOHetzyLQ3is9MXfjwP8eU9GI6NpQIpSyYfqQJSM1tK18qWD1NbeHoEhTMxomBdnJXWNg+GMhgTDw3zN9OFK+bTgU/xbGJjTgK0PNMLaY45R7DYh47XTmtuvYa7LjR97BrhGMnoGvpZSmd86pG9tPk2jtA7/Zn/see0= Received: from MN2PR14MB4030.namprd14.prod.outlook.com (2603:10b6:208:1dc::14) by BL0PR14MB3572.namprd14.prod.outlook.com (2603:10b6:208:1cb::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Thu, 3 Dec 2020 16:37:37 +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.3632.019; Thu, 3 Dec 2020 16:37:37 +0000 From: Don Fedyk To: "'ipsec@ietf.org'" Thread-Topic: YANG for IP-TFS Thread-Index: AdbJkm2fUepqwVRyQQWCbtXaoONW8g== Date: Thu, 3 Dec 2020 16:37:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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: 20302ab4-f8ca-4e94-4371-08d897a9be9e x-ms-traffictypediagnostic: BL0PR14MB3572: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TDnY3bJjntOx5AYsmDgkjg2j68gbKR45re+AEINoemP/t24a3L8VRw/QK4MYtU4EnSqXjTP/IF4W8Ao4S2Vu4MU+78ncs08tZcDCXBpHCPfWCoD9RRUb+02uxVogdeMB9yr67bR1urPTU2Y0JlGwk9Lz8+80c+uSJXdv9f8C0dY6xB7TrCTdd0TH1uqilYC4ZRfBDXm1cnwZQ9gyxirNXdhT/HyIR3veeKXNlLyFBaW1QUsRzx99a6bXqFuYfec1NhThOdruQkIhgZacivS1TaX4X1LT2k/rRZcteavkYzl1EVdczeuA5XvWONYSKZ5NUrOkv1M69JaXNfNzyrY4FddW/Mbi1yyF4L6OxoFg8A9ECX2/oa/qRV81lcSc3YNUOrK3PINW/YUq0s3BKX8z2ta4XjbriF3HBXBHqPmNTkEy5RdvTBikO51nqNNT1Qmn 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)(376002)(396003)(366004)(9686003)(8936002)(66946007)(26005)(8676002)(6506007)(508600001)(186003)(316002)(86362001)(3480700007)(7696005)(76116006)(5660300002)(33656002)(55016002)(2906002)(66476007)(6916009)(71200400001)(66446008)(52536014)(558084003)(66556008)(166002)(64756008)(9326002)(491001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?OUPKAqMLdTIyJtNibE/Gw/nLwf/wetYFlP1EqnLkOvtQvUsSSXwtd7jHde/V?= =?us-ascii?Q?+evRy6B+yFAuew8qmQALUQwxs2gXbqWMB7MqNrw3SybKIu5bj05M3hnmp4pp?= =?us-ascii?Q?SsrdUQYTTWQS8JO53kQIjWp0dbENGFPbpDF2dppn2yBmGyZoEOUCrvuitAE1?= =?us-ascii?Q?aa5Pb8hZTLLIHLodpYld2PoTKddfhdN9bknD/XNIgZFzaRG3gwnUKN2/9188?= =?us-ascii?Q?7JTHUPFze3tVWqrAodAUin5SjY9QcyPspzpnW22tNUGZlyKF1+BDJX+XCBM3?= =?us-ascii?Q?bxwUZ3sr3IMJDx8AUI9Y4liWBgRgPRjcSBdggU9Q2nucRAKd4ygnNOWbq9Vf?= =?us-ascii?Q?R8FJJB18NXw9aBGd/Z1+9EIptJ2sQnHDNvW2utjXm0uI2TRswDUxEj4NknjA?= =?us-ascii?Q?nAt3pQsJrgGODWJgZ7Ur0uICISDFXD09IwZl4nZSucqWsrAJJTIqbGKNp+1y?= =?us-ascii?Q?GCNTfSKv596rNUeBD12T2s9UmT36XloEViz1VWO3rNGBsqkmwm7/wiPn46EX?= =?us-ascii?Q?LuIV9e1rq4hOcMHqCXS0e9UI9brIJJXBdE4V6YRohvP9M2ap6ampPRdxA6Up?= =?us-ascii?Q?YUT6U1thQjyPZcW5iz1mZvm6YQZbIvB40VBbDOfYuBOnskax08z1KOlgXfte?= =?us-ascii?Q?oSKMa0G+V3mXy2luOz6WhWhoCcGCUZ5w93x3xD0aTFHXgVkcZTSw2cR8OJnl?= =?us-ascii?Q?LZorMyTDobOOx/CpPvKggTQktXnHVAwva4yKSPhAWBsTkkMvCiym2sn5cEdT?= =?us-ascii?Q?rkioCXOqPr95BQzoxE2cyOmJ3FkOa0kLQwv61+J34ZwpRCnGyIPlc6+Rb62c?= =?us-ascii?Q?EP0VmdQ7yEYZQo4vNoGzoIxr21Xln+RQvi3mPn6fZjOcuZM44kXDHz/I87xM?= =?us-ascii?Q?1l4fUhak04pdVPXgUob8mjze2cE/MsIFLkEfBgL58UDpdNXde0nsoEikHxs/?= =?us-ascii?Q?zhueuqehwejwKH7EM0dCHBIC+SuVeEmrPCKm/Tii1Tw=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR14MB4030E6525277DE41509CF5AEBBF20MN2PR14MB4030namp_" 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: 20302ab4-f8ca-4e94-4371-08d897a9be9e X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2020 16:37:37.5707 (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: nuSYGGIVx4Vajd1MuoISmkLPD7IroOQ+vl0qGOqZuVb2BAvEUCubRwpyXdFbgVstewfruRp4xXnIlrWe6aiC1w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR14MB3572 Archived-At: Subject: [IPsec] YANG for IP-TFS 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, 03 Dec 2020 16:37:43 -0000 --_000_MN2PR14MB4030E6525277DE41509CF5AEBBF20MN2PR14MB4030namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi As asked in the 109 meeting, could we start the call for adoption for draft= -fedyk-ipsecme-yang-iptfs-01? Thanks Don --_000_MN2PR14MB4030E6525277DE41509CF5AEBBF20MN2PR14MB4030namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

As asked in the 109 meeting, could we start the call= for adoption for draft-fedyk-ipsecme-yang-iptfs-01?

 

Thanks

Don

--_000_MN2PR14MB4030E6525277DE41509CF5AEBBF20MN2PR14MB4030namp_-- From nobody Thu Dec 3 22:26:15 2020 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 71AD83A13B7; Thu, 3 Dec 2020 22:26:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Joseph Touch via Datatracker To: Cc: ipsec@ietf.org, draft-ietf-ipsecme-iptfs.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160706317241.25013.15326204319913211090@ietfa.amsl.com> Reply-To: Joseph Touch Date: Thu, 03 Dec 2020 22:26:12 -0800 Archived-At: Subject: [IPsec] Tsvart early review of draft-ietf-ipsecme-iptfs-03 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: Fri, 04 Dec 2020 06:26:13 -0000 Reviewer: Joseph Touch Review result: Not Ready This documents most significant transport issue is the use of path MTU discovery. Sec 2 recommends the use of path MTU discovery [RFC1191] [RFC8201], but this is known to be problematic black holing where ICMPs are blocked or filtered (which should be noted everywhere PMTU is suggested, including Sec 4.2). It would be more appropriate to incorporate PLPMTUD [RFC4821] [RFC8899], especially in conjunction with congestion control, as both assume bidirectional stateful ingress/egress coordination. This is particularly important given the sending side’s prerogative to change the size of the tunnel EMTU_S (see below). The most significant concern is not at the transport layer – it is the assumption of in-order delivery and insufficient consideration of the impact of loss at the network layer. Loss could orphan received fragments – for which a timeout should be recommended. Loss or reordering could generate faulty reassembly at the egress – which is actually very likely here, e.g., when a short packet is followed by a sequence of packets that are exactly the tunnel MAP (as defined in draft-ietf-intarea-tunnels). As noted below, persistent fragmentation could make this situation worse, esp. in the presence of frequent reordering or loss. Other significant issues, largely at the network/tunnel layer: There is no clear utility in having the blockoffset point past the end of the current packet. It serves – at best – as only a partially useful check on the next packet. I.e., if the two blockoffsets disagree, presumably a packet is lost – but if they agree, it cannot be concluded that a packet is not lost. It is sufficient that it points to the end of the tunnel packet. Although the mechanism allows for padding, it appears too aggressive in trying to be work-conserving. Consider a tunnel that could support 1000B payloads; if a stream of packets comes in as 200B, 1000B, 1000B, 1000B, etc. (more 1000B packets), EVERY 1000B would be fragmented, which means loss of a single tunnel packet would cause two inner packets to be incomplete. The protocol should allow padding in some cases to avoid fragmentation, e.g., every 100th packet it might allow insertion of padding rather splitting a packet across the stream. The heuristic shown here is just an example. Fig 1 shows the blocksize as always occurring in the latter half of a word; is this always the case? If so, it would be useful to indicate the left side of that word as “ESP – con’t”. If not, other examples should be provided. At the end of Sec 2.2, the blockoffset helps recover the next inner packet, but the term “full” in that sentence implies the inner packet is entirely inside that outer packet (which it may not be). The option of congestion control and the claim of “unidirectional” should be discussed more consistently (i.e., mention the need for bidirectional channels when mentioning thec claim of unidirectionality). Like all tunnels, this approach needs to more clearly indicate a number of different MTU values and how they interact [draft-ietf-intarea-tunnels], both for the underlying network and the tunnel provided: - EMTU_S - EMTU_R - Path MTU - Link MTU It may also be useful to use the terms developed in that doc, e.g., tunnel link packet (the packet that traverses a tunnel) as well as inner vs. outer fragmentation, tunnel maximum atomic packet, etc. 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) - Impact of errors in the tunnel on the ingress - Specification of the EMTU_R of the tunnel itself, and how that is determined - What the ingress should do if an incoming packet exceeds EMTU_R - It should be noted that this is a unicast tunnel - What you expect if there are multiple paths between the tunnel ingress and egress - Does the tunnel itself have a flow ID? (if the outer packet is IPv6) If so, is it fixed or intended to vary arbitrarily (and if so, how)? - If the outer packet is IPv4, do you expect to use DF=1? If not, how are you handling ID issues in RFC 6864? If so, it might be useful to add a reminder that the ID can be anything (including constant, which may be useful in avoiding a covert channel). From nobody Fri Dec 4 00:14:49 2020 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 083FA3A15A8; Fri, 4 Dec 2020 00:14:43 -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 2V1X5DDjSZza; Fri, 4 Dec 2020 00:14:41 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 430B33A15B1; Fri, 4 Dec 2020 00:14:38 -0800 (PST) Received: from [192.168.2.5] (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 6E3526046F; Fri, 4 Dec 2020 08:14:37 +0000 (UTC) From: Christian Hopps Message-Id: <559B100B-4BC2-4E95-AFF8-95BBAE0BDAC8@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_79EBE964-6CFD-4F4D-9B7E-1545C611BB8F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 4 Dec 2020 03:14:36 -0500 In-Reply-To: <160706317241.25013.15326204319913211090@ietfa.amsl.com> Cc: Christian Hopps , tsv-art@ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-iptfs.all@ietf.org To: Joseph Touch References: <160706317241.25013.15326204319913211090@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] 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: Fri, 04 Dec 2020 08:14:43 -0000 --Apple-Mail=_79EBE964-6CFD-4F4D-9B7E-1545C611BB8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Joseph, First, thanks for your review. This is an initial reply to clarify a = couple points [inline]. > On Dec 4, 2020, at 1:26 AM, Joseph Touch via Datatracker = wrote: >=20 > Reviewer: Joseph Touch > Review result: Not Ready >=20 > This documents most significant transport issue is the use of path MTU > discovery. Sec 2 recommends the use of path MTU discovery [RFC1191] = [RFC8201], > but this is known to be problematic black holing where ICMPs are = blocked or > filtered (which should be noted everywhere PMTU is suggested, = including Sec > 4.2). It would be more appropriate to incorporate PLPMTUD [RFC4821] = [RFC8899], > especially in conjunction with congestion control, as both assume = bidirectional > stateful ingress/egress coordination. This is particularly important = given the > sending side=E2=80=99s prerogative to change the size of the tunnel = EMTU_S (see below). Thanks, I will look into adding text on this. An implementation can use = receipt of the time echo in the CC header as an ACK of receipt of a = tunnel packet that included that time val so probing using this method = could be suggested as well. For non-CC the user is expected to be in = control of the path domain (otherwise it wouldn't be able to correctly = set the fixed send rate) so no PMTU (or simple PMTU if they really wish = to use it -- unlikely) should suffice. > The most significant concern is not at the transport layer =E2=80=93 = it is the > assumption of in-order delivery and insufficient consideration of the = impact of > loss at the network layer. Loss could orphan received fragments =E2=80=93= for which a > timeout should be recommended. Loss or reordering could generate = faulty > reassembly at the egress =E2=80=93 which is actually very likely here, = e.g., when a > short packet is followed by a sequence of packets that are exactly the = tunnel > MAP (as defined in draft-ietf-intarea-tunnels). As noted below, = persistent > fragmentation could make this situation worse, esp. in the presence of = frequent > reordering or loss. In-order deliver is not assumed. Correct reordering is required, and is = done on ingress by IPTFS through use of the ESP sequence number. = IPsec/ESP includes a sequence number and a window for anti-replay = protection. This also provides for loss detection (as the sliding window = moves) allowing for reaping of orphaned fragments. Perhaps we should add a bit of text highlight this though? (FWIW my test suite for our implementation of IPTFS includes a fairly = comprehensive set of tests of out-of-order delivery including drops. :) > Other significant issues, largely at the network/tunnel layer: >=20 > There is no clear utility in having the blockoffset point past the end = of the > current packet. It serves =E2=80=93 at best =E2=80=93 as only a = partially useful check on the > next packet. I.e., if the two blockoffsets disagree, presumably a = packet is > lost =E2=80=93 but if they agree, it cannot be concluded that a packet = is not lost. It > is sufficient that it points to the end of the tunnel packet. No harm either though, right? Having implemented this, I can tell you = that it does help detect bugs in ones code while in development. :) > Although the mechanism allows for padding, it appears too aggressive = in trying > to be work-conserving. Consider a tunnel that could support 1000B = payloads; if > a stream of packets comes in as 200B, 1000B, 1000B, 1000B, etc. (more = 1000B > packets), EVERY 1000B would be fragmented, which means loss of a = single tunnel > packet would cause two inner packets to be incomplete. The protocol = should > allow padding in some cases to avoid fragmentation, e.g., every 100th = packet it > might allow insertion of padding rather splitting a packet across the = stream. > The heuristic shown here is just an example. This is allowed by the protocol. There is no restriction specified on = when an implementation can insert padding in the tunnel packet stream. = In fact unless the tunnel is being 100% utilized the expectation is that = it will be sending extra padding often -- that being one key to the = traffic flow security. Your suggestion I think is that it could be beneficial to consider = reducing the available bandwidth by forcing padding to align packets = even if in the presence of an offered load >=3D 100% of the tunnel = capacity . Again, this is certainly allowed, but when and if to do this = seems to be a great topic for research, and would be outside the scope = of this initial protocol specification I think. Do you think we should add text explicitly mentioning that one could do = this if one wanted to though? > Fig 1 shows the blocksize as always occurring in the latter half of a = word; is > this always the case? If so, it would be useful to indicate the left = side of > that word as =E2=80=9CESP =E2=80=93 con=E2=80=99t=E2=80=9D. If not, = other examples should be provided. The "..." is just omitting the details of other IPTFS fields which are = normatively specified in section 6. The intent was to give an overview = of what is being discussed in the text below, but not normatively define = the header format. > At the end of Sec 2.2, the blockoffset helps recover the next inner = packet, but > the term =E2=80=9Cfull=E2=80=9D in that sentence implies the inner = packet is entirely inside > that outer packet (which it may not be). will remove "full". > The option of congestion control and the claim of = =E2=80=9Cunidirectional=E2=80=9D should be > discussed more consistently (i.e., mention the need for bidirectional = channels > when mentioning thec claim of unidirectionality). Will do. > Like all tunnels, this approach needs to more clearly indicate a = number of > different MTU values and how they interact = [draft-ietf-intarea-tunnels], both > for the underlying network and the tunnel provided: - EMTU_S - > EMTU_R - Path MTU - Link MTU >=20 > It may also be useful to use the terms developed in that doc, e.g., = tunnel link > packet (the packet that traverses a tunnel) as well as inner vs. outer > fragmentation, tunnel maximum atomic packet, etc. >=20 > 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) - > Impact of errors in the tunnel on the ingress - Specification of = the > EMTU_R of the tunnel itself, and how that is determined - 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). Will go back through the document keeping this in mind. Thanks again, Chris. --Apple-Mail=_79EBE964-6CFD-4F4D-9B7E-1545C611BB8F 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/J7+wACgkQLh2DDte4 MCW+YA/7B6dC13iaLQqK4uUHssUxmnnHcpjBfGcX7jlAuRWXb2Gp9pBM47/vZfwg ngcuOKecqBzlw9CPO3HS6iWHj34uAbMuLnb7ep16RCQnjbrM24OUsr5VKu3wqRIX 0G4ykViPerECPjToD27G0x0k7qDlimIiGiLg/2lKZ9Wrxwr1n6CvkIvLL/prPrg8 P3XVQRT1unoaMH7XkOSITIJJk2rFacS3bt4FTVs0hXy2zDZUvRblu5Q8DcJi7oz6 Lq1zfvE+6tml1mUiZOiw6kfpLUtAX2jWIXBhCH4kQZHiCgVfO1YNvl2Zi+MO8wnE CrpitTwyuQrCMnaOx0gMTm92SU8YVD8wxHdPO+h7PedDPIltX9PSh4ea/bzukj57 6o2rgaNSmz9+aeKtV71qQ8i/5HGfbIVSFnQXm5xQpBQcj9MojNIxqQjM9zSE3Ndr FgVp9ikl4ev0YJkI98deEkEU//zQnf6r9zhRwKUcfJQ1dpMQfpO+P4tE5Vv2RdRD RdDMRdCfrUKpTTZdlnpSyZ2h2GuuaOOCV4/xITx3F67+rYjricuF3z6v5FgIiTRe BxYqCgkKBRNRf8Mhmju9e1AeFV4P/vHI76eVX2wOA8Zj2okTAjscwrwFTVWyXNGS 2LLs6VjW+LHZxOqwKRbH0u0nmf1RHVEFtCwciWvGnEu0AUA95CY= =AOjq -----END PGP SIGNATURE----- --Apple-Mail=_79EBE964-6CFD-4F4D-9B7E-1545C611BB8F-- From nobody Fri Dec 4 08:42:54 2020 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 4019E3A0E07; Fri, 4 Dec 2020 08:42:49 -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 w-wMynYG1ahQ; Fri, 4 Dec 2020 08:42:46 -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 5DB2E3A0DFA; Fri, 4 Dec 2020 08:42:46 -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=3tiLLRfadGXBvz/zVGj83kNY2hb6V4wQRrBs2yRFCLE=; b=Q2d9w9RYRCQfNymce8/ZmFzio /EPAIRPHi1lt4KQdKQwnvcnHB5qCrSIExYqx21p8jN3dLmFuHHOH/87Xd2h+pcGlPeZhRwbxxPOfj 1/d93jaXvtN1C0AiG0du1tFF3ZGhsr3rhPgi+/n0RQYVIrBeMoRFiXxrzx0qUn+eHmRQUsSq1IN+r VLB6ZHmrXUW1EDxuKK74RO26ywh2rHJkcT0KlD2Eg+OGwUi+BkOux7aCuvmIB4O4XEblgAKIB0ITK q3QXdq1JY55k+2EOeLfnR0bOElq0tdyciTG6ZON19ptNWKbNKKHPTElMlvcTodHc46frsdPL6HY8e Z2iaEVtfQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:57535 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 1klEAK-000ryS-2R; Fri, 04 Dec 2020 11:42:45 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_8DAA3C60-7DBA-4A6C-85BC-B2FBED6C9E8A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: <559B100B-4BC2-4E95-AFF8-95BBAE0BDAC8@chopps.org> Date: Fri, 4 Dec 2020 08:42:38 -0800 Cc: ipsec@ietf.org, tsv-art , draft-ietf-ipsecme-iptfs.all@ietf.org Message-Id: <724B2213-3B5E-4057-8343-4EE039034417@strayalpha.com> References: <160706317241.25013.15326204319913211090@ietfa.amsl.com> <559B100B-4BC2-4E95-AFF8-95BBAE0BDAC8@chopps.org> To: Christian Hopps X-Mailer: Apple Mail (2.3654.20.0.2.21) 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: Fri, 04 Dec 2020 16:42:50 -0000 --Apple-Mail=_8DAA3C60-7DBA-4A6C-85BC-B2FBED6C9E8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Christian, > On Dec 4, 2020, at 12:14 AM, Christian Hopps = wrote: >=20 > Hi Joseph, >=20 > First, thanks for your review. This is an initial reply to clarify a = couple points [inline]. >=20 >> On Dec 4, 2020, at 1:26 AM, Joseph Touch via Datatracker = wrote: >>=20 >> Reviewer: Joseph Touch >> Review result: Not Ready >>=20 >> This documents most significant transport issue is the use of path = MTU >> discovery. Sec 2 recommends the use of path MTU discovery [RFC1191] = [RFC8201], >> but this is known to be problematic black holing where ICMPs are = blocked or >> filtered (which should be noted everywhere PMTU is suggested, = including Sec >> 4.2). It would be more appropriate to incorporate PLPMTUD [RFC4821] = [RFC8899], >> especially in conjunction with congestion control, as both assume = bidirectional >> stateful ingress/egress coordination. This is particularly important = given the >> sending side=E2=80=99s prerogative to change the size of the tunnel = EMTU_S (see below). >=20 > Thanks, I will look into adding text on this. An implementation can = use receipt of the time echo in the CC header as an ACK of receipt of a = tunnel packet that included that time val so probing using this method = could be suggested as well. For non-CC the user is expected to be in = control of the path domain (otherwise it wouldn't be able to correctly = set the fixed send rate) so no PMTU (or simple PMTU if they really wish = to use it -- unlikely) should suffice. Agreed. It would just be useful to not imply =E2=80=9Cjust do PMTU=E2=80=9D= because we know it isn=E2=80=99t a solution. >> The most significant concern is not at the transport layer =E2=80=93 = it is the >> assumption of in-order delivery and insufficient consideration of the = impact of >> loss at the network layer. Loss could orphan received fragments =E2=80=93= for which a >> timeout should be recommended. Loss or reordering could generate = faulty >> reassembly at the egress =E2=80=93 which is actually very likely = here, e.g., when a >> short packet is followed by a sequence of packets that are exactly = the tunnel >> MAP (as defined in draft-ietf-intarea-tunnels). As noted below, = persistent >> fragmentation could make this situation worse, esp. in the presence = of frequent >> reordering or loss. >=20 > In-order deliver is not assumed. Correct reordering is required, and = is done on ingress by IPTFS through use of the ESP sequence number. = IPsec/ESP includes a sequence number and a window for anti-replay = protection. This also provides for loss detection (as the sliding window = moves) allowing for reaping of orphaned fragments. >=20 > Perhaps we should add a bit of text highlight this though? That would help. I checked and reordering doesn=E2=80=99t appear to be = mentioned at all. It will be important to also include limits on reordering - how many = packets to hold back before allowing a drop in the sequence and what to = do if a packet shows up late. I.e., this is a bit more complex than just = saying =E2=80=9Creordering is required=E2=80=9D. > (FWIW my test suite for our implementation of IPTFS includes a fairly = comprehensive set of tests of out-of-order delivery including drops. :) >=20 >> Other significant issues, largely at the network/tunnel layer: >>=20 >> There is no clear utility in having the blockoffset point past the = end of the >> current packet. It serves =E2=80=93 at best =E2=80=93 as only a = partially useful check on the >> next packet. I.e., if the two blockoffsets disagree, presumably a = packet is >> lost =E2=80=93 but if they agree, it cannot be concluded that a = packet is not lost. It >> is sufficient that it points to the end of the tunnel packet. >=20 > No harm either though, right? Having implemented this, I can tell you = that it does help detect bugs in ones code while in development. :) It=E2=80=99s useful as a check, but it=E2=80=99s important to explain = what the check means. There are four cases (BO =3D blockoffsets, seq =3D ESP sequence number) ESP - no gap ESP - gap --------------------------------------------------------------------- BO - aligned OK BO-FP-err BO - misaligned SN-FP-err Typ-err Typ-err is the typical error when a packet is lost, because that should = result in both an ESP seqno gap and blockoffset misalignment. SN-FP-err is when there=E2=80=99s no ESP seq no gap but the blockoffsets = are misaligned. This should only ever happen if the seqno rolls around = and you missed it, which you should have some other mechanism to prevent = (i.e., drop old packets when they=E2=80=99re half the sequence space old = - which is easy to predict because you know the tunnel packet generation = rate). BO-FP-err is when there=E2=80=99s an ESP seq no gap but the blockoffsets = are aligned. This is just a false positive (thus =E2=80=9CFP=E2=80=9D in = my notation). S In any of the error cases, you do not reassemble. So checking blockoffset alignment only helps you know whether your = sequence number check and timeout discard is working correctly. Protocol implementation correctness should be checked by test vectors, = not during normal code operation IMO. At best, it=E2=80=99s unnecessary = complexity. At worst, it gives you a false sense of wanting to = reassemble when you shouldn=E2=80=99t. >> Although the mechanism allows for padding, it appears too aggressive = in trying >> to be work-conserving. Consider a tunnel that could support 1000B = payloads; if >> a stream of packets comes in as 200B, 1000B, 1000B, 1000B, etc. (more = 1000B >> packets), EVERY 1000B would be fragmented, which means loss of a = single tunnel >> packet would cause two inner packets to be incomplete. The protocol = should >> allow padding in some cases to avoid fragmentation, e.g., every 100th = packet it >> might allow insertion of padding rather splitting a packet across the = stream. >> The heuristic shown here is just an example. >=20 > This is allowed by the protocol. There is no restriction specified on = when an implementation can insert padding in the tunnel packet stream. = In fact unless the tunnel is being 100% utilized the expectation is that = it will be sending extra padding often -- that being one key to the = traffic flow security. >=20 > Your suggestion I think is that it could be beneficial to consider = reducing the available bandwidth by forcing padding to align packets = even if in the presence of an offered load >=3D 100% of the tunnel = capacity . Not just then, but also when offered load is <100% too. Even in those = cases, it=E2=80=99s possible that it might be better to add padding than = to try to pack. Think of it this way - - if the remaining space in a tunnel packet is small AND - if the next packet would fit in the tunnel without splitting it up if = it started the next packet AND - if the amount of wasted space doesn=E2=80=99t make the ingress = incoming packet queue backup too much THEN - pad out the current tunnel packet and start a new one I.e., this can all be based on a queue on the ingress. When the queue = backs up, push towards work-conserving. Otherwise, push for = split-reduction. The depth of the queue should be configurable - and a property of the = tunnel, because it adds delay.=20 > Again, this is certainly allowed, but when and if to do this seems to = be a great topic for research, and would be outside the scope of this = initial protocol specification I think. >=20 > Do you think we should add text explicitly mentioning that one could = do this if one wanted to though? I=E2=80=99d suggest mentioning that it=E2=80=99s allowed, describing a = possible way to do it, and explaining its cost (esp. the added delay). = It may be =E2=80=9Cresearch=E2=80=9D to get it right, but having = something like that as part of the system may be important to having it = work over lossy paths. >> Fig 1 shows the blocksize as always occurring in the latter half of a = word; is >> this always the case? If so, it would be useful to indicate the left = side of >> that word as =E2=80=9CESP =E2=80=93 con=E2=80=99t=E2=80=9D. If not, = other examples should be provided. >=20 > The "..." is just omitting the details of other IPTFS fields which are = normatively specified in section 6. The intent was to give an overview = of what is being discussed in the text below, but not normatively define = the header format. That=E2=80=99s not clear. You should put something in that area to say = =E2=80=9CIPFTS Sec 6 HDR=E2=80=9D or something. >> At the end of Sec 2.2, the blockoffset helps recover the next inner = packet, but >> the term =E2=80=9Cfull=E2=80=9D in that sentence implies the inner = packet is entirely inside >> that outer packet (which it may not be). >=20 > will remove "full". Thanks - that=E2=80=99s what I was thinking would suffice. >> The option of congestion control and the claim of = =E2=80=9Cunidirectional=E2=80=9D should be >> discussed more consistently (i.e., mention the need for bidirectional = channels >> when mentioning thec claim of unidirectionality). >=20 > Will do. >=20 >> Like all tunnels, this approach needs to more clearly indicate a = number of >> different MTU values and how they interact = [draft-ietf-intarea-tunnels], both >> for the underlying network and the tunnel provided: - EMTU_S - >> EMTU_R - Path MTU - Link MTU >>=20 >> It may also be useful to use the terms developed in that doc, e.g., = tunnel link >> packet (the packet that traverses a tunnel) as well as inner vs. = outer >> fragmentation, tunnel maximum atomic packet, etc. >>=20 >> 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) - >> Impact of errors in the tunnel on the ingress - Specification = of the >> EMTU_R of the tunnel itself, and how that is determined - 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 > Will go back through the document keeping this in mind. I=E2=80=99ll issue an update to that doc shortly. It=E2=80=99s on my = list to do a deep pass to get that one out the door - it=E2=80=99s been = a long time coming, but it=E2=80=99s already impacted the terminology of = a number of other docs that have been published. FWIW, I=E2=80=99d be glad to provide feedback on an update, esp. on that = last issue. Joe --Apple-Mail=_8DAA3C60-7DBA-4A6C-85BC-B2FBED6C9E8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Christian,

On Dec 4, 2020, at 12:14 AM, Christian Hopps = <chopps@chopps.org> wrote:

Hi Joseph,

First, thanks for your review. This is an initial reply to = clarify a couple points [inline].

On Dec 4, 2020, at 1:26 AM, Joseph = Touch via Datatracker <noreply@ietf.org> wrote:

Reviewer: Joseph Touch
Review result: Not = Ready

This documents most significant = transport issue is the use of path MTU
discovery. Sec 2 = recommends the use of path MTU discovery [RFC1191] [RFC8201],
but this is known to be problematic black holing where ICMPs = are blocked or
filtered (which should be noted everywhere = PMTU is suggested, including Sec
4.2). It would be more = appropriate to incorporate PLPMTUD [RFC4821] [RFC8899],
especially in conjunction with congestion control, as both = assume bidirectional
stateful ingress/egress coordination. = This is particularly important given the
sending side=E2=80=99= s prerogative to change the size of the tunnel EMTU_S (see below).

Thanks, I will look into adding text on this. An = implementation can use receipt of the time echo in the CC header as an = ACK of receipt of a tunnel packet that included that time val so probing = using this method could be suggested as well. For non-CC the user is = expected to be in control of the path domain (otherwise it wouldn't be = able to correctly set the fixed send rate) so no PMTU (or simple PMTU if = they really wish to use it -- unlikely) should suffice.

Agreed. It = would just be useful to not imply =E2=80=9Cjust do PMTU=E2=80=9D because = we know it isn=E2=80=99t a solution.

The most significant concern is not = at the transport layer =E2=80=93 it is the
assumption of = in-order delivery and insufficient consideration of the impact of
loss at the network layer. Loss could orphan received = fragments =E2=80=93 for which a
timeout should be = recommended. Loss or reordering could generate faulty
reassembly at the egress =E2=80=93 which is actually very = likely here, e.g., when a
short packet is followed by a = sequence of packets that are exactly the tunnel
MAP (as = defined in draft-ietf-intarea-tunnels). As noted below, persistent
fragmentation could make this situation worse, esp. in the = presence of frequent
reordering or loss.

In-order deliver is not assumed. Correct reordering is = required, and is done on ingress by IPTFS through use of the ESP = sequence number. IPsec/ESP includes a sequence number and a window for = anti-replay protection. This also provides for loss detection (as the = sliding window moves) allowing for reaping of orphaned = fragments.

Perhaps we = should add a bit of text highlight this though?

That would = help. I checked and reordering doesn=E2=80=99t appear to be mentioned at = all.

It will be important to also = include limits on reordering - how many packets to hold back before = allowing a drop in the sequence and what to do if a packet shows up = late. I.e., this is a bit more complex than just saying =E2=80=9Creorderin= g is required=E2=80=9D.

(FWIW my test suite for our implementation of IPTFS includes = a fairly comprehensive set of tests of out-of-order delivery including = drops. :)

Other = significant issues, largely at the network/tunnel layer:
There is no clear utility in having the blockoffset point = past the end of the
current packet. It serves =E2=80=93 at = best =E2=80=93 as only a partially useful check on the
next = packet. I.e., if the two blockoffsets disagree, presumably a packet = is
lost =E2=80=93 but if they agree, it cannot be = concluded that a packet is not lost. It
is sufficient that = it points to the end of the tunnel packet.

No harm either though, right? = Having implemented this, I can tell you that it does help detect bugs in = ones code while in development. :)

It=E2=80=99s useful as a check, but it=E2=80=99s = important to explain what the check means.

There are four cases (BO =3D blockoffsets, seq =3D = ESP sequence number)

    =                     =       ESP - no gap         ESP - = gap
------------------------------------------------------------= ---------
BO - aligned          OK =                     =     BO-FP-err
BO - misaligned    SN-FP-err =              Typ-err

Typ-err is the typical error when a packet is = lost, because that should result in both an ESP seqno gap and = blockoffset misalignment.

SN-FP-err = is when there=E2=80=99s no ESP seq no gap but the blockoffsets are = misaligned. This should only ever happen if the seqno rolls around and = you missed it, which you should have some other mechanism to prevent = (i.e., drop old packets when they=E2=80=99re half the sequence space old = - which is easy to predict because you know the tunnel packet generation = rate).

BO-FP-err is when there=E2=80=99= s an ESP seq no gap but the blockoffsets are aligned. This is just a = false positive (thus =E2=80=9CFP=E2=80=9D in my notation). = S

In any of the error cases, you do = not reassemble.

So checking = blockoffset alignment only helps you know whether your sequence number = check and timeout discard is working correctly.

Protocol implementation correctness should be = checked by test vectors, not during normal code operation IMO. At best, = it=E2=80=99s unnecessary complexity. At worst, it gives you a false = sense of wanting to reassemble when you shouldn=E2=80=99t.

Although the mechanism allows for padding, it appears too = aggressive in trying
to be work-conserving. Consider a = tunnel that could support 1000B payloads; if
a stream of = packets comes in as 200B, 1000B, 1000B, 1000B, etc. (more 1000B
packets), EVERY 1000B would be fragmented, which means loss = of a single tunnel
packet would cause two inner packets to = be incomplete. The protocol should
allow padding in some = cases to avoid fragmentation, e.g., every 100th packet it
might allow insertion of padding rather splitting a packet = across the stream.
The heuristic shown here is just an = example.

This is allowed by the protocol. There is no restriction = specified on when an implementation can insert padding in the tunnel = packet stream. In fact unless the tunnel is being 100% utilized the = expectation is that it will be sending extra padding often -- that being = one key to the traffic flow security.

Your suggestion I think is that it could be beneficial to = consider reducing the available bandwidth by forcing padding to align = packets even if in the presence of an offered load >=3D 100% of the = tunnel capacity .

Not just then, but also when offered load is = <100% too. Even in those cases, it=E2=80=99s possible that it might = be better to add padding than to try to pack. Think of it this way = -
- if the remaining space in a tunnel packet is = small
AND
- if the next packet would fit in the = tunnel without splitting it up if it started the next = packet
AND
- if the amount of wasted space doesn=E2=80= =99t make the ingress incoming packet queue backup too = much
THEN
- pad out the current tunnel packet and = start a new one

I.e., this can all = be based on a queue on the ingress. When the queue backs up, push = towards work-conserving. Otherwise, push for = split-reduction.

The depth of the = queue should be configurable - and a property of the tunnel, because it = adds delay. 

Again, this is certainly allowed, but when and if to do this = seems to be a great topic for research, and would be outside the scope = of this initial protocol specification I = think.

Do you think = we should add text explicitly mentioning that one could do this if one = wanted to though?

I=E2=80=99d suggest mentioning that it=E2=80=99s = allowed, describing a possible way to do it, and explaining its cost = (esp. the added delay). It may be =E2=80=9Cresearch=E2=80=9D to get it = right, but having something like that as part of the system may be = important to having it work over lossy paths.

Fig 1 = shows the blocksize as always occurring in the latter half of a word; = is
this always the case? If so, it would be useful to = indicate the left side of
that word as =E2=80=9CESP =E2=80=93= con=E2=80=99t=E2=80=9D. If not, other examples should be provided.

The "..." is just omitting the details of other IPTFS fields = which are normatively specified in section 6. The intent was to give an = overview of what is being discussed in the text below, but not = normatively define the header format.

That=E2=80=99s not clear. You should put something = in that area to say =E2=80=9CIPFTS Sec 6 HDR=E2=80=9D or = something.

At = the end of Sec 2.2, the blockoffset helps recover the next inner packet, = but
the term =E2=80=9Cfull=E2=80=9D in that sentence = implies the inner packet is entirely inside
that outer = packet (which it may not be).

will remove "full".

Thanks - = that=E2=80=99s what I was thinking would suffice.

The =  option of congestion control and the claim of =E2=80=9Cunidirectiona= l=E2=80=9D should be
discussed more consistently (i.e., = mention the need for bidirectional channels
when = mentioning thec claim of unidirectionality).

Will do.

Like all tunnels, this approach needs = to more clearly indicate a number of
different MTU values = and how they interact [draft-ietf-intarea-tunnels], both
for= the underlying network and the tunnel provided: - =       EMTU_S -
EMTU_R - =       Path MTU - =       Link MTU

It may also be useful to use the terms developed in that doc, = e.g., tunnel link
packet (the packet that traverses a = tunnel) as well as inner vs. outer
fragmentation, tunnel = maximum atomic packet, etc.

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) -
Impact of errors in the tunnel on the = ingress -       Specification of the
EMTU_R of the tunnel itself, and how that is determined - =       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).

Will go back through the document keeping this in = mind.

I=E2=80=99ll = issue an update to that doc shortly. It=E2=80=99s on my list to do a = deep pass to get that one out the door - it=E2=80=99s been a long time = coming, but it=E2=80=99s already impacted the terminology of a number of = other docs that have been published.

FWIW, I=E2=80=99d be glad to provide feedback on = an update, esp. on that last issue.

Joe

= --Apple-Mail=_8DAA3C60-7DBA-4A6C-85BC-B2FBED6C9E8A-- From nobody Sun Dec 6 15:12:06 2020 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 65A813A0D07 for ; Sun, 6 Dec 2020 15:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 rEhkox0Saag3 for ; Sun, 6 Dec 2020 15:12:03 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 27A883A0D05 for ; Sun, 6 Dec 2020 15:12:02 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0B6NBkEr026063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 6 Dec 2020 18:11:51 -0500 Date: Sun, 6 Dec 2020 15:11:46 -0800 From: Benjamin Kaduk To: ipsec@ietf.org Cc: ynir.ietf@gmail.com, simon@josefsson.org, rdd@cert.org, kivinen@iki.fi, christian.tschudin@unibas.ch Message-ID: <20201206231146.GG64351@kduck.mit.edu> References: <20201117184621.11715F40741@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201117184621.11715F40741@rfc-editor.org> Archived-At: Subject: Re: [IPsec] [Technical Errata Reported] RFC8031 (6339) 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, 06 Dec 2020 23:12:05 -0000 Can anyone speak to the history of the examples here (or the content of the report itself)? Thanks, Ben On Tue, Nov 17, 2020 at 10:46:21AM -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC8031, > "Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6339 > > -------------------------------------- > Type: Technical > Reported by: Christian Tschudin > > Section: Appendix A > > Original Text > ------------- > The public keys are generated from this using the formula in > Section 2: > > pub_i = X25519(d_i, G) = > 48 d5 dd d4 06 12 57 ba 16 6f a3 f9 bb db 74 f1 > a4 e8 1c 08 93 84 fa 77 f7 90 70 9f 0d fb c7 66 > > pub_r = X25519(d_r, G) = > 0b e7 c1 f5 aa d8 7d 7e 44 86 62 67 32 98 a4 43 > 47 8b 85 97 45 17 9e af 56 4c 79 c0 ef 6e ee 25 > > And this is the value of the Key Exchange Data field in the Key > Exchange payload described in Section 3.1. The shared value is > calculated as in Section 2: > > SHARED_SECRET = X25519(d_i, pub_r) = X25519(d_r, pub_i) = > c7 49 50 60 7a 12 32 7f-32 04 d9 4b 68 25 bf b0 > 68 b7 f8 31 9a 9e 37 08-ed 3d 43 ce 81 30 c9 50 > > > Corrected Text > -------------- > The public keys are generated from this using the formula in > Section 2: > > pub_i = X25519(d_i, G) = > a7 07 b3 bc 0f 37 56 fc 0a cf 33 55 85 c5 f7 7b > 9f 29 ff a4 24 70 14 af 84 70 5b eb 50 46 26 29 > > pub_r = X25519(d_r, G) = > 0e 57 7e 11 5d 6c 08 59 b8 51 36 d2 1b 1c fd 74 > 67 9f 91 14 61 1d 79 c6 81 ba d0 8a 7e 1f 0a 04 > > And this is the value of the Key Exchange Data field in the Key > Exchange payload described in Section 3.1. The shared value is > calculated as in Section 2: > > SHARED_SECRET = X25519(d_i, pub_r) = X25519(d_r, pub_i) = > d6 8d 8c ea fd 2c d3 ce 25 34 43 33 c8 9e 35 54 > 9e 0f c6 1a 98 87 39 34 b1 8a 18 70 f0 3a 17 0c > > > Notes > ----- > The test vector values given both for the public keys and for the shared secret are wrong. It turns out that they were derived from the unchanged random input, instead of d_X. An explanation could be that a first text version did not include the fixing of the random bits and that after inserting the respective paragraph (introducing fixed_X and d_X), it was forgotten to update pub_X and SHARED_SECRET. > > This discrepancy came to my attention when testing the Yubikey 5 hardware and comparing it with the NaCl library and RFC8031. While the NaCl library works as expected, it is disturbing to see that the Yubikey can only be made to produce the desired (above and corrected) shared secret if you let it compute X25519(fixed_i,pub_r). That is, the secret must be presented to the Yubikey in big-endian format which could be "inspired" by the (not very detailed) Smartcard spec 3.4.1 that refers to ANSI X9.62 where curve parameters, prefixed with 0x04, are encoded in big-endian order - clearly the ANSI encoding is not useful here as we only need one parameter u. I wonder whether RFC8031 should spell out that input parameters (d_X and pub_X) SHOULD be presented in encoded form (and thus little-endian), hence putting manufacturers in charge of documenting any deviation. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8031 (draft-ietf-ipsecme-safecurves-05) > -------------------------------------- > Title : Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement > Publication Date : December 2016 > Author(s) : Y. Nir, S. Josefsson > Category : PROPOSED STANDARD > Source : IP Security Maintenance and Extensions > Area : Security > Stream : IETF > Verifying Party : IESG From nobody Tue Dec 8 06:39:26 2020 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 6C5823A0F0C; Tue, 8 Dec 2020 06:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=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 wZ0WKOrF5Qun; Tue, 8 Dec 2020 06:39:19 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60047.outbound.protection.outlook.com [40.107.6.47]) (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 93DDD3A0F0F; Tue, 8 Dec 2020 06:39:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YVFp748CO0Fm9Vw41u9tgDJ9Ch+IYcWLusaBQIcW526WkNwghx48aNnntfTv7FphfkjGusCJ99NiOSSfw48E3nRN/PCfAAGO5h7wrFgV0Mu2W93tZ2Yz7J+BWTKFDgxV5mVp8BFjzjEOPAcA9dBULw4TX72DqM7NXjY/By9BfW7ldF0pG81qT5sJa+Kw0qow3MhkwgL2jW6A8TMuwVrC5njark3CdXDovB01E3SmQYf7KbynkhInGRp+hKydTihSE3Qenxw9kTAu2dfhhQfzDIzti+EE2HtjFSHsmL6j9hLsIAMKPEc51/cl/Mlbkhmn/TBXcLrY2a7hIj5tM4zSNg== 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=h4eCfIbrOxfUVbmbmIhWwyeR0oZ1KS3gnXdSaXMlW6o=; b=Jt5Z9gST9hAZJBYGtVJpV8Dckgg2L7qtpS/IjbSAr7XYZzpe++/iQNn79pBYwTx66GP0mTsnESy/lpQVFOKlSDf3fx+ALtlzbcw6Xbmy6ve4LpxN6sBzqZlPLWaINU/+pAJjheyE58t2FIFb+J4lm5BoxJBcTvr6ECSTaZ/udaTTS2dwA3wuWeepoGqb7Ouw1wUvVK+ltvxXDqNN5UN18gLgEfdlIGPu+vmYXk2tqSMRkUO4QA8yKNEKdLUV7ZhPahGhz3b7S1CNp+2b8vpa2T/A1vXcwbhKQtUNkWoLZCPtf2Ww9SlhfEYGj6y0FpHbKAkkQTYxjyTO8k/AOWtI/g== 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=h4eCfIbrOxfUVbmbmIhWwyeR0oZ1KS3gnXdSaXMlW6o=; b=Dz8EUKJSWC+Yk/L8ErvvemuP3PGdye7iTMs4nAJ7mZYm4w3/hMQpSfbwGFtiqDBCft9y1JX7aDVMzo/axq44KgbnK31j46e5kuYaYxpyFyOjFBGlrwGS5MN2xCCncvp0jzvkgZTRfWfG04KPmKlF4GKrPYhIxvV4FVbMhW/FVkM= Received: from VI1PR0701MB2191.eurprd07.prod.outlook.com (2603:10a6:800:23::18) by VI1PR07MB6542.eurprd07.prod.outlook.com (2603:10a6:800:179::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.8; Tue, 8 Dec 2020 14:39:17 +0000 Received: from VI1PR0701MB2191.eurprd07.prod.outlook.com ([fe80::d8f0:1b05:8f59:1e74]) by VI1PR0701MB2191.eurprd07.prod.outlook.com ([fe80::d8f0:1b05:8f59:1e74%12]) with mapi id 15.20.3654.012; Tue, 8 Dec 2020 14:39:17 +0000 From: Mohit Sethi M To: "lwip@ietf.org" CC: "ipsec@ietf.org" Thread-Topic: WGLC for draft-ietf-lwig-minimal-esp Thread-Index: AQHWzW/nc7TsWEEK4ESAP7bU/vR2aw== Date: Tue, 8 Dec 2020 14:39:17 +0000 Message-ID: <59deb3e5-82f8-ea8d-0c39-011188810fe7@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.67.7.120] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e40421cd-d628-45e0-3780-08d89b870ab5 x-ms-traffictypediagnostic: VI1PR07MB6542: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: d69OkySyfP09pQy0IfjNU7fE7XmFPDAf8A7ZEiauyTIQB3yf84XQn3t3HTBzeilSw0fjALZTHH/HzVOL5/x9rxHShS1a7bUjz51JL4OhVQfenvvbxjkmwKNeoS1anQORh4OD72U0ZVLwPP6NU6cu6nXojJTBK7nxEZ+/vAUaxaY0GRkKoixcMz8K1w08SUdhh941NdR4BJXS21bY+jABeRQErUKprbEwZ6UqGFwWj20auoiuSYgrlkwIqGutdRB2pM65VYlj+8opYeqhLrzg8WIjLk3GdekDdaIHJmCQpEBQ8k3XRYsuxOOxWZqLwSdwaDhyB1ZhbebrBq/kXWMVh7ajTK1HNhIF6G+PkmoX+tXO2nCm8B83lSNgSF4ADa3wqYXmLb2lmUFdSxVnmDn46HSoM01khV1CRnc1HTHGEUFud4P2y/HkHSH9LlOBl6um6/n/RysnWR7teKe4fykwG8No7bgXuj4P+wLJ2spWjhA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0701MB2191.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(376002)(366004)(966005)(91956017)(66446008)(508600001)(8676002)(8936002)(31686004)(86362001)(6506007)(166002)(26005)(186003)(2906002)(2616005)(31696002)(76116006)(6916009)(66946007)(71200400001)(4326008)(83380400001)(6486002)(450100002)(36756003)(6512007)(64756008)(66556008)(5660300002)(66476007)(4744005)(43740500002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?NXQzZG1CSndweC9xOGlBYVp0QmZSWDVWZCtqNDBlZTRDWG8yMjBpRjRpODU0?= =?utf-8?B?cWxNYXBUc2JCNG1XOVBzeDh1cEZ0b3ZYV0dyekJJWHMzZHIwSk05M3lhUkJS?= =?utf-8?B?WFFueTlCa0wrKzdaTldGdHVhdlc4TUF6VDNTOWZUVTJ4M0toejJZY29RM0NK?= =?utf-8?B?YUJBaFhrblFSWEFDRWdkWW9vNDhveTE3TC9yM3hPRStOb3VCMEFwYVRvb04x?= =?utf-8?B?ZHRZYlJNdFBxQ2U1WHZOQkhGWHZSeWM5VER0QmtBS1VRUzJwRU15b29QNTZM?= =?utf-8?B?VW95Y3VJejFFRGVrZEx4ZWRyVkJadHlya3ZJY0k2a1lrZzNLdjV5OFEwd2xi?= =?utf-8?B?VzlkUkVtQmFnK3JISmFuOENNSVJkdWFCdlpuMlJ1NHdlaDB0Z01ialVWcSs2?= =?utf-8?B?ZEFvWjRpNVBKaytHTHpUVmZlSWtQbE5ocEZRZ2J2ZTAwcmhQTmlyQUszR1Z1?= =?utf-8?B?RWZPVjk3T3FMbWlBeisxN2lJOWJiaGp5eUlmOGlGQ3BTTm1CaExTS21qMWJQ?= =?utf-8?B?endYUEpOTmllTEFZa1RITWFLWHlPa0NMNGg4ZzFPaE1oMDdWRUFvMzNFaTBp?= =?utf-8?B?S3duQ1B6bU8xbHdRMHI5SzVnWnJiQjRUWEVLQXRwMkh6dlQ3T2ZhRnRJbEJ4?= =?utf-8?B?d3hibXcyVG5leVhEWGxxR0swS21TQ3pDdTNNb0YxemRCQjB5cHYxdGl2N1Bq?= =?utf-8?B?bmRkbzJMWnk4S1BJQmZueFc5a0Q4TmY1cmtpSlVRckRqNExSWFJLVEI0VGdL?= =?utf-8?B?VzJGcnZHbE91K251WVc3L0lraW1WM0d4RXNGQzlaVGhyWnJhMm1sMUo3MU1G?= =?utf-8?B?YWFNSzJ6MUYra1NTVWxiTXUzNW55cXFaaFZDTDh1ZlR6SWpiaHhadEcrU281?= =?utf-8?B?clVuNmhwam5OZEExT3ZyUGFVSFg4Y1FsWkZkYUhaTGZjeTFJZUp2alRRMU5p?= =?utf-8?B?N3REaTF4clpDd1l2dGNLelkyem00N2NnL1lzWHdySDhXUW93eUtldmlBUjJY?= =?utf-8?B?Wjd1RWdRZ3dHY1JPMVdvTU9DcWtXSWxkdEFCRmM4K0h6R0s2SkVZeXFJelNT?= =?utf-8?B?ZUh4V1U3L0t0TGxqME5POVZOU2d6UVdkWlNJSjNkSWpadXN6a2V3Y1V0SW1C?= =?utf-8?B?andqaW9tYm42OS9sUXduVzhUc2huMnJkd2NoOUNxWldPZ3g4aS9CZkdSSS9Y?= =?utf-8?B?MTN2RHdvbVlqVTNGNnlmdG5BazRLVkR6WWl3cWtITTNFUVdIaGhwZUZENG5J?= =?utf-8?B?ZEZUWFRkRE96TnZqRlF5U2VMb1g4R3NMMVZTdzJYOEZtSFFlR0NPczFlaVdH?= =?utf-8?Q?g/iGjU6sxP0GM=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_59deb3e582f8ea8d0c39011188810fe7ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR0701MB2191.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e40421cd-d628-45e0-3780-08d89b870ab5 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2020 14:39:17.4504 (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: CFGk9O7Aht/60Vc23c6uK1JNrhQfAaYMJxFszye7sC2zvi3znGueqlsTXAQQGnVLpltXSgoxfOIbv1uh5JDYQFJRp2fzs0/TEIn0u6ZLpN8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6542 Archived-At: Subject: [IPsec] WGLC for draft-ietf-lwig-minimal-esp 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, 08 Dec 2020 14:39:24 -0000 --_000_59deb3e582f8ea8d0c39011188810fe7ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNClRoaXMgZW1haWwgaW5pdGlhdGVzIHRoZSB3b3JraW5nIGdyb3VwIGxhc3Qg Y2FsbCAoV0dMQykgZm9yIGRyYWZ0LWlldGYtbHdpZy1taW5pbWFsLWVzcDoNCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWx3aWctbWluaW1hbC1lc3AtMDINCg0KVGhlIGRy YWZ0IGhhcyBiZWVuIHJldmlld2VkIGJ5IFRlcm8sIFNjb3R0LCBhbmQgVmFsZXJ5IGluIHRoZSBw YXN0Lg0KDQpJZiB5b3UgaGF2ZSBhbnkgcmVtYWluaW5nIGNvbmNlcm5zIG9yIGlzc3VlcywgcGxl YXNlIGNvbW1lbnQgb24gdGhlIG1haWxpbmcgbGlzdCBiZWZvcmUgdGhlIFdHTEMgZXhwaXJlcyBv biBEZWNlbWJlciAyMiwgMjAxOS4gSWYgeW91IGhhdmUgcHJldmlvdXNseSByZXZpZXdlZCB0aGUg ZG9jdW1lbnQgYW5kIGZlZWwgdGhhdCBpdCBpcyByZWFkeSBmb3IgSUVTRyByZXZpZXcsIHBsZWFz ZSBleHByZXNzIHN1cHBvcnQgb24gdGhlIG1haWxpbmcgbGlzdC4gVGhlIGRvY3VtZW50IHNoZXBo ZXJkIGNhbiB1c2UgdGhpcyBpbmZvcm1hdGlvbiBpbiB0aGUgd3JpdGV1cC4NCg0KVGhpcyBXR0xD IGlzIGFsc28gQ0NlZCB0byBpcHNlY21lLg0KDQpaaGVuIGFuZCBNb2hpdA0K --_000_59deb3e582f8ea8d0c39011188810fe7ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <0F3366EC8BBEF54D96F7FCA684D2315B@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+RGVhciBhbGws PGJyPg0KPC9wPg0KPHA+VGhpcyBlbWFpbCBpbml0aWF0ZXMgdGhlIHdvcmtpbmcgZ3JvdXAgbGFz dCBjYWxsIChXR0xDKSBmb3IgZHJhZnQtaWV0Zi1sd2lnLW1pbmltYWwtZXNwOg0KPGJyPg0KPGEg bW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1sd2lnLW1pbmltYWwtZXNwLTAyIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1sd2lnLW1pbmltYWwtZXNwLTAyPC9hPjwvcD4NCjxwPlRoZSBkcmFmdCBo YXMgYmVlbiByZXZpZXdlZCBieSBUZXJvLCA8c3BhbiBpZD0ibXNnLWZyb20iIGNsYXNzPSJwaXBl Ij5TY290dCw8L3NwYW4+IGFuZCBWYWxlcnkgaW4gdGhlIHBhc3QuDQo8YnI+DQo8YnI+DQpJZiB5 b3UgaGF2ZSBhbnkgcmVtYWluaW5nIGNvbmNlcm5zIG9yIGlzc3VlcywgcGxlYXNlIGNvbW1lbnQg b24gdGhlIG1haWxpbmcgbGlzdCBiZWZvcmUgdGhlIFdHTEMgZXhwaXJlcyBvbiBEZWNlbWJlciAy MiwgMjAxOS4gSWYgeW91IGhhdmUgcHJldmlvdXNseSByZXZpZXdlZCB0aGUgZG9jdW1lbnQgYW5k IGZlZWwgdGhhdCBpdCBpcyByZWFkeSBmb3IgSUVTRyByZXZpZXcsIHBsZWFzZSBleHByZXNzIHN1 cHBvcnQgb24gdGhlIG1haWxpbmcgbGlzdC4NCiBUaGUgZG9jdW1lbnQgc2hlcGhlcmQgY2FuIHVz ZSB0aGlzIGluZm9ybWF0aW9uIGluIHRoZSB3cml0ZXVwLjwvcD4NCjxwPlRoaXMgV0dMQyBpcyBh bHNvIENDZWQgdG8gaXBzZWNtZS48YnI+DQo8YnI+DQpaaGVuIGFuZCBNb2hpdDxicj4NCjwvcD4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_59deb3e582f8ea8d0c39011188810fe7ericssoncom_-- From nobody Sun Dec 13 22:12:49 2020 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 D66133A0978; Sun, 13 Dec 2020 22:12:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-ipsecme-ipv6-ipv4-codes@ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org, David Waltermire , Yoav Nir X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <160792636485.7399.15746504036447365714@ietfa.amsl.com> Date: Sun, 13 Dec 2020 22:12:44 -0800 Archived-At: Subject: [IPsec] Murray Kucherawy's No Objection on draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT) 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, 14 Dec 2020 06:12:45 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-ipsecme-ipv6-ipv4-codes-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 4, "repsonser" should be "responder". From nobody Sun Dec 13 23:59:56 2020 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 2762E3A0978; Sun, 13 Dec 2020 23:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 jHCZskaYmtKB; Sun, 13 Dec 2020 23:59:49 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024263A0989; Sun, 13 Dec 2020 23:59:48 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 4CvYhM2JVwz5vYG; Mon, 14 Dec 2020 08:59:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607932787; bh=875LarHXD6Ty9G64vxZyD5g28+js93Tvm0DeVmjL6Wo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=AOKRERpkkQC72VpWcGzur3NBorCfc0aromgC6XkogtYQcaDOGsNijqe3leps32FRL sD4kBuu7KnmlR7KplXq1Bt1/PwPifVbx0FpEmTo4UwGp0nFbOnkpP5WlJQfsqmFQwC G2Hhe5JoMrLNIUilQGElEnTgiGBZzksQGSKGWCcbUtMNJzwvrdpzaFve5LYYCUlf2A 783mBpjy6mmYXL2JR4noS7Kr2ZVG2zrViGUc/99zdh1lURrJCSIFdvUWMgij80qK5m 46qgDt6z08XtsdeIQvcqyJPKl0Yr/dHQMdItwZ5PKf4MF5GFXskv1xbcMDoozjcful HoqvlhwFUb+Tw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4CvYhM0XszzBrLw; Mon, 14 Dec 2020 08:59:47 +0100 (CET) From: To: Murray Kucherawy , The IESG CC: "draft-ietf-ipsecme-ipv6-ipv4-codes@ietf.org" , "ipsecme-chairs@ietf.org" , "ipsec@ietf.org" , "David Waltermire" , Yoav Nir Thread-Topic: Murray Kucherawy's No Objection on draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT) Thread-Index: AQHW0eAk+8ENMsNwKEWf84ZZt48luqn2Ogqg Date: Mon, 14 Dec 2020 07:59:46 +0000 Message-ID: <4162_1607932787_5FD71B73_4162_68_1_787AE7BB302AE849A7480A190F8B93303159CB23@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160792636485.7399.15746504036447365714@ietfa.amsl.com> In-Reply-To: <160792636485.7399.15746504036447365714@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Murray Kucherawy's No Objection on draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT) 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, 14 Dec 2020 07:59:51 -0000 SGkgTXVycmF5LA0KDQpUaGFuayB5b3UuIA0KDQpGaXhlZC4gU2VlIHRoZSBkaWZmIGF0OiBodHRw czovL3Rpbnl1cmwuY29tL2lrZS12NHY2LWNvZGVzDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBNdXJyYXkgS3VjaGVyYXd5IHZpYSBEYXRh dHJhY2tlciBbbWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmddDQo+IEVudm95w6nCoDogbHVuZGkgMTQg ZMOpY2VtYnJlIDIwMjAgMDc6MTMNCj4gw4DCoDogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+ IENjwqA6IGRyYWZ0LWlldGYtaXBzZWNtZS1pcHY2LWlwdjQtY29kZXNAaWV0Zi5vcmc7IGlwc2Vj bWUtDQo+IGNoYWlyc0BpZXRmLm9yZzsgaXBzZWNAaWV0Zi5vcmc7IERhdmlkIFdhbHRlcm1pcmUN Cj4gPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+OyBZb2F2IE5pciA8eW5pci5pZXRmQGdtYWls LmNvbT4NCj4gT2JqZXTCoDogTXVycmF5IEt1Y2hlcmF3eSdzIE5vIE9iamVjdGlvbiBvbiBkcmFm dC1pZXRmLWlwc2VjbWUtaXB2Ni0NCj4gaXB2NC1jb2Rlcy0wNTogKHdpdGggQ09NTUVOVCkNCj4g DQo+IE11cnJheSBLdWNoZXJhd3kgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9z aXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtaXBzZWNtZS1pcHY2LWlwdjQtY29kZXMtMDU6IE5vIE9i amVjdGlvbg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBs aW5lIGludGFjdCBhbmQgcmVwbHkgdG8NCj4gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBp biB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvDQo+IGN1dCB0aGlzIGludHJvZHVj dG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRw czovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLQ0KPiBjcml0ZXJpYS5odG1s DQo+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBw b3NpdGlvbnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWlwc2VjbWUtaXB2Ni1pcHY0LWNvZGVzLw0KPiANCj4gDQo+ IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0K PiANCj4gSW4gU2VjdGlvbiA0LCAicmVwc29uc2VyIiBzaG91bGQgYmUgInJlc3BvbmRlciIuDQo+ IA0KPiANCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSBy ZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxz aWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29w aWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Dec 14 00:17:33 2020 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 2B4DE3A0ABA; Mon, 14 Dec 2020 00:17:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-ipsecme-ipv6-ipv4-codes@ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org, David Waltermire , Yoav Nir , ynir.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <160793384784.17963.2226708165812902988@ietfa.amsl.com> Date: Mon, 14 Dec 2020 00:17:28 -0800 Archived-At: Subject: [IPsec] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-ipsecme-ipv6-ipv4-codes-05=3A_=28with_COMMENT=29?= 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, 14 Dec 2020 08:17:28 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-ipv6-ipv4-codes-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Bonjour Med, Thank you for the work put into this document. The shepherd write-up is really terse but reflects that it was a rough consensus. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- The one-line abstract does not really explain/summarize what this document is about. E.g., nothing is mentioned about 3GPP origin. Expanding the abstract with something like "by allowing the responder to signal to the initiator which address families are supported". -- Section 1 -- The sentence "When the UE attaches the network using a WLAN access by means of IKEv2 capabilities, there are no equivalent notification codes ..." looks cryptic to me. What is the link with WLAN access and IKEv2 ? -- Section 5 -- "If a dual-stack initiator requests only an IPv6 prefix (or an IPv4 address) but only receives IP4_ALLOWED (or IP6_ALLOWED) notification status type from the responder, the initiator MUST send a request for IPv4 address(es) (or IPv6 prefix(es))." Is it really a "MUST" and not a "SHOULD" or even "MAY" ? A constrained UE may have IPv6-only applications and, even if OS is dual-stack, not bothers to have a useless IPv4 address. The paragraph after this one mimics the 3GPP PDP behavior, but, does it make sense for IKEv2 ? == NITS == In several places, the word "responder" is misspelled. In some places, a ':' is followed by a capitalized word which looks weird to my French-reading eyes... From nobody Mon Dec 14 01:01:38 2020 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 CC3003A0DCD; Mon, 14 Dec 2020 01:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 9Nou9mvMIW0Q; Mon, 14 Dec 2020 01:01:29 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA3A3A08AB; Mon, 14 Dec 2020 01:01:29 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 4Cvb3W55Cjz4wwH; Mon, 14 Dec 2020 10:01:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607936487; bh=R9GF1cPAwSWvfPV4rzbkGCHqpT3Qsk0bK6AdLa+fmzs=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=CF2+a07AJ9sk/6/KN88INnD/xr5CG87BAiLhDoeCqlYdgrdDOX4+hqv2jMtwjB6QX wYNyDJdxm/ucQmz587xIonysQTPZtRi2I7vwMiunx+mD43E2EFPVfA9jl6wvdyBPQ0 ftG+/8/AFU/hFtNpnn5Xvmc3SFnhqZmFbThMx45avG5a/PpUy95oXYifRBjVP/KXbW tpNz4Oo3HFTFtqv0ZxIFGpJ0dZ8BmAxwJrc0j/lRrA8JzljIkvgkgXp3Rzl9CaGz3X Fuo6ECMLq3g0mR7ZDLa0v8gP+R+uIFaO/6ZVXL1kjuTM0z4CVl2WIiKfmiqs0WvoXU LjG48dpbBlCYA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4Cvb3W4767zDq82; Mon, 14 Dec 2020 10:01:27 +0100 (CET) From: To: =?utf-8?B?w4lyaWMgVnluY2tl?= , The IESG CC: "draft-ietf-ipsecme-ipv6-ipv4-codes@ietf.org" , "ipsecme-chairs@ietf.org" , "ipsec@ietf.org" , "David Waltermire" , Yoav Nir Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtaXBz?= =?utf-8?Q?ecme-ipv6-ipv4-codes-05:_(with_COMMENT)?= Thread-Index: AQHW0fGRRnC9y6f7akesGSC2Etu1man2Rg7Q Date: Mon, 14 Dec 2020 09:00:05 +0000 Message-ID: <5783_1607936487_5FD729E7_5783_96_26_787AE7BB302AE849A7480A190F8B93303159CC01@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160793384784.17963.2226708165812902988@ietfa.amsl.com> In-Reply-To: <160793384784.17963.2226708165812902988@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-ipsecme-ipv6-ipv4-codes-05=3A_=28with_COMMENT=29?= 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, 14 Dec 2020 09:01:32 -0000 Qm9uam91ciBFcmljLCANCg0KVGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMuIA0KDQpQbGVhc2Ug c2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiBEZcKgOiDDiXJpYyBWeW5ja2UgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBs eUBpZXRmLm9yZ10NCj4gRW52b3nDqcKgOiBsdW5kaSAxNCBkw6ljZW1icmUgMjAyMCAwOToxNw0K PiDDgMKgOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2PCoDogZHJhZnQtaWV0Zi1pcHNl Y21lLWlwdjYtaXB2NC1jb2Rlc0BpZXRmLm9yZzsgaXBzZWNtZS0NCj4gY2hhaXJzQGlldGYub3Jn OyBpcHNlY0BpZXRmLm9yZzsgRGF2aWQgV2FsdGVybWlyZQ0KPiA8ZGF2aWQud2FsdGVybWlyZUBu aXN0Lmdvdj47IFlvYXYgTmlyIDx5bmlyLmlldGZAZ21haWwuY29tPjsNCj4geW5pci5pZXRmQGdt YWlsLmNvbQ0KPiBPYmpldMKgOiDDiXJpYyBWeW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQt aWV0Zi1pcHNlY21lLWlwdjYtaXB2NC0NCj4gY29kZXMtMDU6ICh3aXRoIENPTU1FTlQpDQo+IA0K PiDDiXJpYyBWeW5ja2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yDQo+IGRyYWZ0LWlldGYtaXBzZWNtZS1pcHY2LWlwdjQtY29kZXMtMDU6IE5vIE9iamVjdGlv bg0KPiANCj4gV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGlu dGFjdCBhbmQgcmVwbHkgdG8NCj4gYWxsIGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUg VG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvDQo+IGN1dCB0aGlzIGludHJvZHVjdG9yeSBw YXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3 dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLQ0KPiBjcml0ZXJpYS5odG1sDQo+IGZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuDQo+IA0KPiANCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3Np dGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWlwc2VjbWUtaXB2Ni1pcHY0LWNvZGVzLw0KPiANCj4gDQo+IA0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiAtLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLQ0KPiANCj4g Qm9uam91ciBNZWQsDQo+IA0KPiBUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1dCBpbnRvIHRoaXMg ZG9jdW1lbnQuIFRoZSBzaGVwaGVyZCB3cml0ZS11cA0KPiBpcyByZWFsbHkgdGVyc2UgYnV0IHJl ZmxlY3RzIHRoYXQgaXQgd2FzIGEgcm91Z2ggY29uc2Vuc3VzLg0KPiANCj4gUGxlYXNlIGZpbmQg YmVsb3cgIHNvbWUgbm9uLWJsb2NraW5nIENPTU1FTlQgcG9pbnRzIChidXQgcmVwbGllcw0KPiB3 b3VsZCBiZSBhcHByZWNpYXRlZCksIGFuZCBzb21lIG5pdHMuDQo+IA0KPiBJIGhvcGUgdGhhdCB0 aGlzIGhlbHBzIHRvIGltcHJvdmUgdGhlIGRvY3VtZW50LA0KPiANCj4gUmVnYXJkcywNCj4gDQo+ IC3DqXJpYw0KPiANCj4gPT0gQ09NTUVOVFMgPT0NCj4gDQo+IC0tIEFic3RyYWN0IC0tDQo+IFRo ZSBvbmUtbGluZSBhYnN0cmFjdCBkb2VzIG5vdCByZWFsbHkgZXhwbGFpbi9zdW1tYXJpemUgd2hh dCB0aGlzDQo+IGRvY3VtZW50IGlzIGFib3V0LiBFLmcuLCBub3RoaW5nIGlzIG1lbnRpb25lZCBh Ym91dCAzR1BQIG9yaWdpbi4NCj4gRXhwYW5kaW5nIHRoZSBhYnN0cmFjdCB3aXRoIHNvbWV0aGlu ZyBsaWtlICJieSBhbGxvd2luZyB0aGUNCj4gcmVzcG9uZGVyIHRvIHNpZ25hbCB0byB0aGUgaW5p dGlhdG9yIHdoaWNoIGFkZHJlc3MgZmFtaWxpZXMgYXJlDQo+IHN1cHBvcnRlZCIuDQoNCltNZWRd IEZpeGVkIHdpdGggcy9zdXBwb3J0ZWQvYWxsb3dlZC4gVGhhbmtzLiANCg0KPiANCj4gLS0gU2Vj dGlvbiAxIC0tDQo+IFRoZSBzZW50ZW5jZSAiV2hlbiB0aGUgVUUgIGF0dGFjaGVzIHRoZSBuZXR3 b3JrIHVzaW5nIGEgV0xBTiBhY2Nlc3MNCj4gYnkgbWVhbnMgb2YNCj4gSUtFdjIgY2FwYWJpbGl0 aWVzLCB0aGVyZSBhcmUgbm8gZXF1aXZhbGVudCBub3RpZmljYXRpb24gY29kZXMgLi4uIg0KPiBs b29rcyBjcnlwdGljIHRvIG1lLiBXaGF0IGlzIHRoZSBsaW5rIHdpdGggV0xBTiBhY2Nlc3MgYW5k IElLRXYyID8NCj4gDQoNCltNZWRdIFdMQU4gaXMgYW4gZXhhbXBsZSBvZiB3aGF0IDNHUFAgY2Fs bHMgIm5vbi10cnVzdGVkIGFjY2VzcyBuZXR3b3JrIi4gSW4gc3VjaCBjYXNlLCBhbiBJS0V2Mi9J UHNlYyBpcyB1c2VkIHRvIGNvbm5lY3QgdG8gdGhlICIzR1BQIG5ldHdvcmsiLiBXZSB3YW50ZWQg dG8gYXZvaWQgb3ZlcmxvYWRpbmcgdGhlIHRleHQgd2l0aCAzR1BQIHRlcm1zICsgYXZvaWQgZGlz dHJhY3RpbmcgdGhlIHJlYWRlciBhYm91dCB0cnVzdGVkL25vbi10cnVzdGVkIGFjY2Vzc2VzLiAN Cg0KU2VlIHRoZSB1cGRhdGVkIHRleHQgYXQ6IGh0dHBzOi8vdGlueXVybC5jb20vaWtlLXY0djYt Y29kZXMuIEJldHRlcj8gDQoNCj4gLS0gU2VjdGlvbiA1IC0tDQo+ICAgICJJZiBhIGR1YWwtc3Rh Y2sgaW5pdGlhdG9yIHJlcXVlc3RzIG9ubHkgYW4gSVB2NiBwcmVmaXggKG9yIGFuDQo+IElQdjQN Cj4gICAgYWRkcmVzcykgYnV0IG9ubHkgcmVjZWl2ZXMgSVA0X0FMTE9XRUQgKG9yIElQNl9BTExP V0VEKQ0KPiBub3RpZmljYXRpb24NCj4gICAgc3RhdHVzIHR5cGUgZnJvbSB0aGUgcmVzcG9uZGVy LCB0aGUgaW5pdGlhdG9yIE1VU1Qgc2VuZCBhIHJlcXVlc3QNCj4gZm9yDQo+ICAgIElQdjQgYWRk cmVzcyhlcykgKG9yIElQdjYgcHJlZml4KGVzKSkuIg0KPiANCj4gSXMgaXQgcmVhbGx5IGEgIk1V U1QiIGFuZCBub3QgYSAiU0hPVUxEIiBvciBldmVuICJNQVkiID8gQQ0KPiBjb25zdHJhaW5lZCBV RSBtYXkgaGF2ZSBJUHY2LW9ubHkgYXBwbGljYXRpb25zIGFuZCwgZXZlbiBpZiBPUyBpcw0KPiBk dWFsLXN0YWNrLCBub3QgYm90aGVycyB0byBoYXZlIGEgdXNlbGVzcyBJUHY0IGFkZHJlc3MuDQo+ IA0KDQpbTWVkXSBTdWNoIGNvbnN0cmFpbmVkIFVFIHNob3VsZCBiZSB0d2Vha2VkIHRvIGJlaGF2 ZSBhcyBhbiAiSVB2Ni1vbmx5IGluaXRpYXRvciIuIFRoYXQgaXMgbG9jYWwgdG8gdGhlIFVFLiAg IA0KDQo+IFRoZSBwYXJhZ3JhcGggYWZ0ZXIgdGhpcyBvbmUgbWltaWNzIHRoZSAzR1BQIFBEUCBi ZWhhdmlvciwgYnV0LCBkb2VzDQo+IGl0IG1ha2Ugc2Vuc2UgZm9yIElLRXYyID8NCg0KW01lZF0g V2Ugd2FudCB0byBoYXZlIGEgZnVuY3Rpb25hbCBwYXJpdHkgZm9yIGFuIFVFIGluZGVwZW5kZW50 bHkgb2YgdGhlIGFjY2VzcyBpdCB1c2VzIHRvIGdyYWZ0IHRvIGEgM0dQUCBuZXR3b3JrLiANCg0K PiANCj4gPT0gTklUUyA9PQ0KPiANCj4gSW4gc2V2ZXJhbCBwbGFjZXMsIHRoZSB3b3JkICJyZXNw b25kZXIiIGlzIG1pc3NwZWxsZWQuDQoNCltNZWRdIEZpeGVkIHRoZSBvbmUgcmVwb3J0ZWQgYnkg TXVycmF5LiBXaWxsIGRvdWJsZSBjaGVjay4NCg0KPiANCj4gSW4gc29tZSBwbGFjZXMsIGEgJzon IGlzIGZvbGxvd2VkIGJ5IGEgY2FwaXRhbGl6ZWQgd29yZCB3aGljaCBsb29rcw0KPiB3ZWlyZCB0 byBteSBGcmVuY2gtcmVhZGluZyBleWVzLi4uDQoNCltNZWRdIFRoYXQncyBPSyBmb3IgdGhlIFJG QyBFZGl0b3IuIFlvdSBtYXkgY2hlY2sgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg4 MDEgOi0pIA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZh bHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFu Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo YW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Mon Dec 14 01:39:44 2020 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 04DBB3A0E90; Mon, 14 Dec 2020 01:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.698 X-Spam-Level: X-Spam-Status: No, score=-7.698 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=AvEIfMcL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ze2BGYLv 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 Ygm1yAH08BSf; Mon, 14 Dec 2020 01:39:40 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5B63A1077; Mon, 14 Dec 2020 01:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8524; q=dns/txt; s=iport; t=1607938754; x=1609148354; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8Z+MQG5XWVqRb3XG1M/uQjgGTAa+T9Vaxpebm304js0=; b=AvEIfMcLTN5EB1qBCAe+zp7iEIJvNcd4jbiJNdIOa761wmV1n9BYTV9o UFF3bxqsz4av87r0Kl7/7ClAMpktXEpk9Ea1m8qLrS18f3mmof5xnGNj7 AP1YPoNem1JrFJxldoTDDx5eHXT+ahTHX4caB/Hrg3WAvYq4vkf6kL3N5 k=; X-IPAS-Result: =?us-ascii?q?A0AHAAB/MNdfkJtdJa1iGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQFAgT0CAQEBAQELAYFRUXxbLy6EPoNIA40wJQOKGYRyi?= =?us-ascii?q?X+BLhSBEQNUCwEBAQ0BASMGBAIEAQGESgIXgWoCJTYHDgIDAQEBAwIDAQEBA?= =?us-ascii?q?QUBAQECAQYEFAEBAQEBAYY4DIVyAQEBAwESEREMAQE3AQsEAgEIEQMBAgMCI?= =?us-ascii?q?wMCAgIfERQBBQMIAgQBDQUigwQBglUDDiABDqAOAoE8iGl2gTKDBAEBBYFHQ?= =?us-ascii?q?YMSDQuCEAMGgQ4qAYJ0gmmBEIIphDAbgUE/gREnDBCCVT6CG0IBAQMBgSYBE?= =?us-ascii?q?gGDODOCLIFZEFgHAV4EFA4ZCAgGAg1CLwQUOy0IKEECjwkIHIJrAT6kNFcKg?= =?us-ascii?q?nSJIo0KBIUYAx+DJoomlHCEaY8aiwyCd44qLg8JhDMCBAIEBQIOAQEFgV0OI?= =?us-ascii?q?2lYEQdwFWUBgj4hLxcCDY4hGh2DOoUUhUR0GgEcAgYBCQEBAwkBe4oAAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AsnL5OhVItnjKLlNTLwq4rKOazzXV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyFufVeguzZvubrXmlTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBpWe76zEfXB?= =?us-ascii?q?74MFk9KuH8AIWHicOx2qi78IHSZAMdgj27bPtyIRy6oB+XuNMRhN5pK706zV?= =?us-ascii?q?3CpX4bdg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,418,1599523200"; d="scan'208";a="614036124" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Dec 2020 09:39:13 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BE9dDcG012793 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Dec 2020 09:39:13 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 14 Dec 2020 03:39:12 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 14 Dec 2020 04:39:12 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 14 Dec 2020 04:39:12 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GGo0eVWlkyaXHs9SiLnDrQ10d7glR5km2RjS0OV9FP9jZHlOYEM5ZUtcmqrahx67/ZpiAKatO71JxSz5Jvfkyzz2v/RPJe/XDs3YrPYf+sIYbDFBu6yWzmPA4DbBXT8qKmbvC3DRQaoS9k+IoGSHRzl9NyGH8PdzkDxT8XMLr309st6rX8HIQ9AMyMt6+3TOPGx2h0mMJgR/xz1b0umBSA31xZqF6jwDBsdnP+XSnakCkVcULhigwo2//2guEqi4lf8zjbQknk6lBUbImGcLRUDWVdUVP+FdHcxeY/BNWF5pnIPXeFJgdK1bjwJxBIamb6AmsDss5kZJGNogfWO4Cw== 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=8Z+MQG5XWVqRb3XG1M/uQjgGTAa+T9Vaxpebm304js0=; b=YMQc0MHTjyrl/tddgQ67HrDk73hsgbaQrK4ECK5m/5NQFKvrVPAflIDMF44Wz09gwpqPwhkBdn/DHHCTTjrrdSfheGdpha8ei4JMWfGApTc18jIfIV8QxbGL6Fq/1Ka6t/YL4nVNcwtxF0TVS4snzZSfcuh923CsYWAXwbKdZ9R1NMPP1i2mgfO4KIlZghEFqPsNR0gsSrG19cjvI8KUoGAbfYgjgge1s7q1uMjHlHRXqaMHVie1vDos4T5tVuI/8kAPffGzTsccHdGjYg/lB4/aB4ZB7RhMujkAfsb2tLT0qhiTt4q0yv6RP2TjEkx640IzgZZJMwE/hN59YQr+nQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8Z+MQG5XWVqRb3XG1M/uQjgGTAa+T9Vaxpebm304js0=; b=ze2BGYLv1LsOxn1TMUJKWk304QD+R0dxx60DGqtr6C1Uuu5ej8SSByLyGZsrhPGuUhjAbghSjZxRXy5pZ5AIem5/A7Dye8/d5Dsv/oqmwl4QhAuVKXYeRXQl1MTtyc1c9Xm4guAZ+Hm6ouJ+MBxaxZ6G9fuNTQIwpiQLld5WL1Q= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4902.namprd11.prod.outlook.com (2603:10b6:510:37::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Mon, 14 Dec 2020 09:39:10 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::65a1:e6a9:7932:e680]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::65a1:e6a9:7932:e680%2]) with mapi id 15.20.3632.021; Mon, 14 Dec 2020 09:39:10 +0000 From: "Eric Vyncke (evyncke)" To: "mohamed.boucadair@orange.com" , The IESG CC: "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "draft-ietf-ipsecme-ipv6-ipv4-codes@ietf.org" , Yoav Nir , David Waltermire Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtaXBz?= =?utf-8?Q?ecme-ipv6-ipv4-codes-05:_(with_COMMENT)?= Thread-Index: AQHW0fGYb1Eh7lfElUOpPamKzc7bQKn2SySAgAAbrYA= Date: Mon, 14 Dec 2020 09:39:10 +0000 Message-ID: References: <160793384784.17963.2226708165812902988@ietfa.amsl.com> <5783_1607936487_5FD729E7_5783_96_26_787AE7BB302AE849A7480A190F8B93303159CC01@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <5783_1607936487_5FD729E7_5783_96_26_787AE7BB302AE849A7480A190F8B93303159CC01@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:b5db:edb:3a0f:efc8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 74c7aa79-c589-495b-840d-08d8a0141c3b x-ms-traffictypediagnostic: PH0PR11MB4902: 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: P4/fAv6I07QnNN37ipNhqveDmnCwv5qqpT78U8lvFuz7o1fUk7TW5QtEI9R1peNWumb38F7qAaygxJu4ajDRpjFsey44IfIKKGMPHiTdk3zpDme6CgbjkT6eYlnMQE9BSWTCuwNP8+vTCzgvOjpaQNbNGf5/ql1P6KjULZQP8t4Og5x3yv0y/d/ZVMAfZpFaP8xWHtVUPPlw/fh17mPnuFFbUyz4bWGpZjV1wfPOMgGuU9rdViKGaWY+PRz7Fy/8kiex9Ssl+Tq2uU4T1dd2UNLTIlZXR30vyIBrpeZRR45n/Ugpp2u9ycxOR1LyyARquVcXsNGqEaSSnDKNzoLbRKW2sc8TdhTKruWyYpCCT27uz+nNwdXheFSnlKx5w+J12Zo8HWsYUtbzfQybglWSqUoZEP3TafGxd/TS44rNMwUh3Li3TMWCLzQYKnX0gbB/ulRn+kWIdB6Vww60vr+L5g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(366004)(376002)(66946007)(66476007)(66556008)(64756008)(66446008)(86362001)(2616005)(36756003)(71200400001)(186003)(5660300002)(8936002)(110136005)(508600001)(6512007)(83380400001)(6486002)(6506007)(53546011)(91956017)(224303003)(2906002)(54906003)(4326008)(966005)(66574015)(33656002)(76116006)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?ZWNlUGdEUkRTOWkrbGhUY3BoZ1A1emhNSjc1VzYvMTlDeGdrZ2xMSDQvOElU?= =?utf-8?B?QzcvYmd5cjFReTVWOHh3M1ZnOTFuMFhFVERrTWJTSnJ4L1QvY3lqOUFZYlhi?= =?utf-8?B?b3hrbUdTRFpSUUw0cmZMczhvRkFTL3JSR05aeXZiTk9IVmRoVVZ0RE9yRGZr?= =?utf-8?B?TmF4MGFzaTZUWExST0hJRUZpMlhLcGl3MitTYnoyUkMxd3grQTROL1M0enNC?= =?utf-8?B?YnM0K3prWFlaV20rNUpzeTVhR216RndCRVhtMTJ6YmwvNFBQL2VQZXJxLzZ5?= =?utf-8?B?R1ZqVVlHd2NhbmhmTzd6WXVkMzhOOU1aYmpoUmdRcitRU1pQZnhtUzlHT2Yw?= =?utf-8?B?ZFRsdUdKOEtrUnhFK2JMSmtlZE1IV2NSME9udHNQV1AwSUpReksvUFQvVWh3?= =?utf-8?B?QklQTG5CbDJMTzRxZXo4LzBzblFIK0tncnBHeXRUMy9udXhVZmt2cWk1Mnl0?= =?utf-8?B?d3BpWGZiRVVKazhjcVBCMjd1c3ZONWJtd01SMmV3TTJWaVMxRE0vNVUwcm9K?= =?utf-8?B?SkNkZWNURUhOcDdNTDIxYlVsTUR4ZTBBTTZySFRuSUFpRWJKbHJOdGRxdmF6?= =?utf-8?B?TkMwcmNqQklqOE9KVUs1WEtZV1lSdXNkSGlXTTZ0U2UzUkU3Rk01czBCUlhv?= =?utf-8?B?RW9iTEhpS09wUkFpSkN4bE9tNFRBZlpLOHdGSVM5a2xkL3poclFHRUl5aWJI?= =?utf-8?B?VXc3c2UrMUJPeEM4OHh1R2VnTWFYK0lCVzkxSlJKa0FhK3NOM1NNR0RCRlg3?= =?utf-8?B?VnFiUXNJREhXbXcyYWRLUHo2Sm5LNzhhL0R2ZThoanRIRzZwMkxBa1JuWjNz?= =?utf-8?B?LzROT3FvWWcxdDg2WStyTk5MN1RHUGdtM1BYd0RYMFJYL2VJWm8vUnlza0gz?= =?utf-8?B?aVlXVmxYanhlQUcxRmhHWnY5dWNMUk1pV2c3alVSMWQzV3lUZnBCZWs0dXVW?= =?utf-8?B?bUthend2RzR0Z241c280RUtObUEvUmo0d1hPV0RMQUN6MUt2c1R3QWt1TTh3?= =?utf-8?B?ZUMxWExMb2JWRU9WOGZrTFY1YnlMSE1XcTgxYUtmdk5CTkp3eDhIQnk5cjVF?= =?utf-8?B?OXFURG5lWG5TVmIweGhGcGcyZ29KOUxkYy9MUEdzTWVlR2czVEM4UTU5TUlp?= =?utf-8?B?ZXZqSXVSVUk0Z2F3WWYvSWxZZHRJMzZQL1lCbmE0VkdXdzFMUHpqZE9TY3NX?= =?utf-8?B?NzRGaUhkSTRZek9RUUdxeGZGdEducm5QNmIvWDRldEsyMTFLY3FBVG8zVFh6?= =?utf-8?B?SGRjVzlPNGlJTWd2ZlpOMGVtWUVGdUdQQVF6bVRRT3FPVDBpdHFKOUg1ekhB?= =?utf-8?B?VXR2cjFpV0JJQUhUMXhQNnpBMnVOaWRsNlRGdjlkQXhQazU2dzd4clRoQXA4?= =?utf-8?B?MXJvRmRYUFluWTV1NlNuc0tUZVFFOC9yYWVDNWtuZmhvU0NkY2ZtVUFjOUlv?= =?utf-8?Q?JuR9pXTy?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 74c7aa79-c589-495b-840d-08d8a0141c3b X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2020 09:39:10.5362 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lO26YimUzWXHXG+aE+k5+7bgCcwYwBVibFRoUjX3eckXEc3fh9rObhk6XRmZk8J3k2TP91/kQj8eIERN5yjNEQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4902 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [IPsec] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-ipsecme-ipv6-ipv4-codes-05=3A_=28with_COMMENT=29?= 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, 14 Dec 2020 09:39:42 -0000 UmUtYm9uam91ciBNZWQsDQoNClRoZSBzdWdnZXN0ZWQgdGV4dCBzb3VuZHMgZ29vZCB0byBtZS4g QWJvdXQgdGhlICJNVVNUIiBpbiBzZWN0aW9uIDUsIGxldCdzIGFncmVlIHRoYXQgd2UgZGlzYWdy ZWUgb24gdGhpcyBvbmUgYnV0IHRoaXMgaXMgTk9UIGJsb2NraW5nLg0KDQpUaGVyZSBpcyBhbm90 aGVyICJyZXBzb25kZXIiIGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiA1IGFuZCBJIGxvdmVkIHlvdXIg cmVmZXJlbmNlIHRvIFJGQyA4ODAxIChNb25kYXkgbW9ybmluZyBzbWlsZSEpDQoNClJlZ2FyZHMN Cg0KLcOpcmljDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpZXNnIDxp ZXNnLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAibW9oYW1lZC5ib3VjYWRhaXJAb3Jh bmdlLmNvbSIgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpEYXRlOiBNb25kYXksIDE0 IERlY2VtYmVyIDIwMjAgYXQgMTA6MDENClRvOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5j b20+LCBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiAiaXBzZWNAaWV0Zi5vcmciIDxpcHNl Y0BpZXRmLm9yZz4sICJpcHNlY21lLWNoYWlyc0BpZXRmLm9yZyIgPGlwc2VjbWUtY2hhaXJzQGll dGYub3JnPiwgImRyYWZ0LWlldGYtaXBzZWNtZS1pcHY2LWlwdjQtY29kZXNAaWV0Zi5vcmciIDxk cmFmdC1pZXRmLWlwc2VjbWUtaXB2Ni1pcHY0LWNvZGVzQGlldGYub3JnPiwgWW9hdiBOaXIgPHlu aXIuaWV0ZkBnbWFpbC5jb20+LCBEYXZpZCBXYWx0ZXJtaXJlIDxkYXZpZC53YWx0ZXJtaXJlQG5p c3QuZ292Pg0KU3ViamVjdDogUkU6IMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFm dC1pZXRmLWlwc2VjbWUtaXB2Ni1pcHY0LWNvZGVzLTA1OiAod2l0aCBDT01NRU5UKQ0KDQogICAg Qm9uam91ciBFcmljLCANCg0KICAgIFRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzLiANCg0KICAg IFBsZWFzZSBzZWUgaW5saW5lLiANCg0KICAgIENoZWVycywNCiAgICBNZWQNCg0KICAgID4gLS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQogICAgPiBEZSA6IMOJcmljIFZ5bmNrZSB2aWEgRGF0 YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3JnXQ0KICAgID4gRW52b3nDqSA6IGx1bmRp IDE0IGTDqWNlbWJyZSAyMDIwIDA5OjE3DQogICAgPiDDgCA6IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPg0KICAgID4gQ2MgOiBkcmFmdC1pZXRmLWlwc2VjbWUtaXB2Ni1pcHY0LWNvZGVzQGlldGYu b3JnOyBpcHNlY21lLQ0KICAgID4gY2hhaXJzQGlldGYub3JnOyBpcHNlY0BpZXRmLm9yZzsgRGF2 aWQgV2FsdGVybWlyZQ0KICAgID4gPGRhdmlkLndhbHRlcm1pcmVAbmlzdC5nb3Y+OyBZb2F2IE5p ciA8eW5pci5pZXRmQGdtYWlsLmNvbT47DQogICAgPiB5bmlyLmlldGZAZ21haWwuY29tDQogICAg PiBPYmpldCA6IMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWlwc2Vj bWUtaXB2Ni1pcHY0LQ0KICAgID4gY29kZXMtMDU6ICh3aXRoIENPTU1FTlQpDQogICAgPiANCiAg ICA+IMOJcmljIFZ5bmNrZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlv biBmb3INCiAgICA+IGRyYWZ0LWlldGYtaXBzZWNtZS1pcHY2LWlwdjQtY29kZXMtMDU6IE5vIE9i amVjdGlvbg0KICAgID4gDQogICAgPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBz dWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0bw0KICAgID4gYWxsIGVtYWlsIGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvDQogICAgPiBj dXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCiAgICA+IA0KICAgID4g DQogICAgPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l bnQvZGlzY3Vzcy0NCiAgICA+IGNyaXRlcmlhLmh0bWwNCiAgICA+IGZvciBtb3JlIGluZm9ybWF0 aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQogICAgPiANCiAg ICA+IA0KICAgID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlv bnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KICAgID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1pcHNlY21lLWlwdjYtaXB2NC1jb2Rlcy8NCiAgICA+IA0KICAgID4g DQogICAgPiANCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPiAtLQ0KICAgID4gQ09NTUVOVDoNCiAg ICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQogICAgPiAtLQ0KICAgID4gDQogICAgPiBCb25qb3VyIE1lZCwNCiAg ICA+IA0KICAgID4gVGhhbmsgeW91IGZvciB0aGUgd29yayBwdXQgaW50byB0aGlzIGRvY3VtZW50 LiBUaGUgc2hlcGhlcmQgd3JpdGUtdXANCiAgICA+IGlzIHJlYWxseSB0ZXJzZSBidXQgcmVmbGVj dHMgdGhhdCBpdCB3YXMgYSByb3VnaCBjb25zZW5zdXMuDQogICAgPiANCiAgICA+IFBsZWFzZSBm aW5kIGJlbG93ICBzb21lIG5vbi1ibG9ja2luZyBDT01NRU5UIHBvaW50cyAoYnV0IHJlcGxpZXMN CiAgICA+IHdvdWxkIGJlIGFwcHJlY2lhdGVkKSwgYW5kIHNvbWUgbml0cy4NCiAgICA+IA0KICAg ID4gSSBob3BlIHRoYXQgdGhpcyBoZWxwcyB0byBpbXByb3ZlIHRoZSBkb2N1bWVudCwNCiAgICA+ IA0KICAgID4gUmVnYXJkcywNCiAgICA+IA0KICAgID4gLcOpcmljDQogICAgPiANCiAgICA+ID09 IENPTU1FTlRTID09DQogICAgPiANCiAgICA+IC0tIEFic3RyYWN0IC0tDQogICAgPiBUaGUgb25l LWxpbmUgYWJzdHJhY3QgZG9lcyBub3QgcmVhbGx5IGV4cGxhaW4vc3VtbWFyaXplIHdoYXQgdGhp cw0KICAgID4gZG9jdW1lbnQgaXMgYWJvdXQuIEUuZy4sIG5vdGhpbmcgaXMgbWVudGlvbmVkIGFi b3V0IDNHUFAgb3JpZ2luLg0KICAgID4gRXhwYW5kaW5nIHRoZSBhYnN0cmFjdCB3aXRoIHNvbWV0 aGluZyBsaWtlICJieSBhbGxvd2luZyB0aGUNCiAgICA+IHJlc3BvbmRlciB0byBzaWduYWwgdG8g dGhlIGluaXRpYXRvciB3aGljaCBhZGRyZXNzIGZhbWlsaWVzIGFyZQ0KICAgID4gc3VwcG9ydGVk Ii4NCg0KICAgIFtNZWRdIEZpeGVkIHdpdGggcy9zdXBwb3J0ZWQvYWxsb3dlZC4gVGhhbmtzLiAN Cg0KICAgID4gDQogICAgPiAtLSBTZWN0aW9uIDEgLS0NCiAgICA+IFRoZSBzZW50ZW5jZSAiV2hl biB0aGUgVUUgIGF0dGFjaGVzIHRoZSBuZXR3b3JrIHVzaW5nIGEgV0xBTiBhY2Nlc3MNCiAgICA+ IGJ5IG1lYW5zIG9mDQogICAgPiBJS0V2MiBjYXBhYmlsaXRpZXMsIHRoZXJlIGFyZSBubyBlcXVp dmFsZW50IG5vdGlmaWNhdGlvbiBjb2RlcyAuLi4iDQogICAgPiBsb29rcyBjcnlwdGljIHRvIG1l LiBXaGF0IGlzIHRoZSBsaW5rIHdpdGggV0xBTiBhY2Nlc3MgYW5kIElLRXYyID8NCiAgICA+IA0K DQogICAgW01lZF0gV0xBTiBpcyBhbiBleGFtcGxlIG9mIHdoYXQgM0dQUCBjYWxscyAibm9uLXRy dXN0ZWQgYWNjZXNzIG5ldHdvcmsiLiBJbiBzdWNoIGNhc2UsIGFuIElLRXYyL0lQc2VjIGlzIHVz ZWQgdG8gY29ubmVjdCB0byB0aGUgIjNHUFAgbmV0d29yayIuIFdlIHdhbnRlZCB0byBhdm9pZCBv dmVybG9hZGluZyB0aGUgdGV4dCB3aXRoIDNHUFAgdGVybXMgKyBhdm9pZCBkaXN0cmFjdGluZyB0 aGUgcmVhZGVyIGFib3V0IHRydXN0ZWQvbm9uLXRydXN0ZWQgYWNjZXNzZXMuIA0KDQogICAgU2Vl IHRoZSB1cGRhdGVkIHRleHQgYXQ6IGh0dHBzOi8vdGlueXVybC5jb20vaWtlLXY0djYtY29kZXMu IEJldHRlcj8gDQoNCiAgICA+IC0tIFNlY3Rpb24gNSAtLQ0KICAgID4gICAgIklmIGEgZHVhbC1z dGFjayBpbml0aWF0b3IgcmVxdWVzdHMgb25seSBhbiBJUHY2IHByZWZpeCAob3IgYW4NCiAgICA+ IElQdjQNCiAgICA+ICAgIGFkZHJlc3MpIGJ1dCBvbmx5IHJlY2VpdmVzIElQNF9BTExPV0VEIChv ciBJUDZfQUxMT1dFRCkNCiAgICA+IG5vdGlmaWNhdGlvbg0KICAgID4gICAgc3RhdHVzIHR5cGUg ZnJvbSB0aGUgcmVzcG9uZGVyLCB0aGUgaW5pdGlhdG9yIE1VU1Qgc2VuZCBhIHJlcXVlc3QNCiAg ICA+IGZvcg0KICAgID4gICAgSVB2NCBhZGRyZXNzKGVzKSAob3IgSVB2NiBwcmVmaXgoZXMpKS4i DQogICAgPiANCiAgICA+IElzIGl0IHJlYWxseSBhICJNVVNUIiBhbmQgbm90IGEgIlNIT1VMRCIg b3IgZXZlbiAiTUFZIiA/IEENCiAgICA+IGNvbnN0cmFpbmVkIFVFIG1heSBoYXZlIElQdjYtb25s eSBhcHBsaWNhdGlvbnMgYW5kLCBldmVuIGlmIE9TIGlzDQogICAgPiBkdWFsLXN0YWNrLCBub3Qg Ym90aGVycyB0byBoYXZlIGEgdXNlbGVzcyBJUHY0IGFkZHJlc3MuDQogICAgPiANCg0KICAgIFtN ZWRdIFN1Y2ggY29uc3RyYWluZWQgVUUgc2hvdWxkIGJlIHR3ZWFrZWQgdG8gYmVoYXZlIGFzIGFu ICJJUHY2LW9ubHkgaW5pdGlhdG9yIi4gVGhhdCBpcyBsb2NhbCB0byB0aGUgVUUuICAgDQoNCiAg ICA+IFRoZSBwYXJhZ3JhcGggYWZ0ZXIgdGhpcyBvbmUgbWltaWNzIHRoZSAzR1BQIFBEUCBiZWhh dmlvciwgYnV0LCBkb2VzDQogICAgPiBpdCBtYWtlIHNlbnNlIGZvciBJS0V2MiA/DQoNCiAgICBb TWVkXSBXZSB3YW50IHRvIGhhdmUgYSBmdW5jdGlvbmFsIHBhcml0eSBmb3IgYW4gVUUgaW5kZXBl bmRlbnRseSBvZiB0aGUgYWNjZXNzIGl0IHVzZXMgdG8gZ3JhZnQgdG8gYSAzR1BQIG5ldHdvcmsu IA0KDQogICAgPiANCiAgICA+ID09IE5JVFMgPT0NCiAgICA+IA0KICAgID4gSW4gc2V2ZXJhbCBw bGFjZXMsIHRoZSB3b3JkICJyZXNwb25kZXIiIGlzIG1pc3NwZWxsZWQuDQoNCiAgICBbTWVkXSBG aXhlZCB0aGUgb25lIHJlcG9ydGVkIGJ5IE11cnJheS4gV2lsbCBkb3VibGUgY2hlY2suDQoNCiAg ICA+IA0KICAgID4gSW4gc29tZSBwbGFjZXMsIGEgJzonIGlzIGZvbGxvd2VkIGJ5IGEgY2FwaXRh bGl6ZWQgd29yZCB3aGljaCBsb29rcw0KICAgID4gd2VpcmQgdG8gbXkgRnJlbmNoLXJlYWRpbmcg ZXllcy4uLg0KDQogICAgW01lZF0gVGhhdCdzIE9LIGZvciB0aGUgUkZDIEVkaXRvci4gWW91IG1h eSBjaGVjayBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODgwMSA6LSkgDQoNCg0KICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KICAgIENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYw0KICAgIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3Ug Y29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQogICAgYSBsJ2V4cGVkaXRldXIgZXQgbGUg ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCiAgICBPcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVm b3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCiAgICBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlv biB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KICAgIHRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KICAgIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KICAg IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCiAgICBU aGFuayB5b3UuDQoNCg0K From nobody Mon Dec 14 03:06:37 2020 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 CBE953A0FCA; Mon, 14 Dec 2020 03:06:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-ipsecme-ipv6-ipv4-codes@ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org, David Waltermire , Yoav Nir , ynir.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <160794399531.23637.14475252681712118057@ietfa.amsl.com> Date: Mon, 14 Dec 2020 03:06:35 -0800 Archived-At: Subject: [IPsec] Robert Wilton's No Objection on draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT) 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, 14 Dec 2020 11:06:36 -0000 Robert Wilton has entered the following ballot position for draft-ietf-ipsecme-ipv6-ipv4-codes-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Med, Thanks for this document. I found it pretty easy to read and follow. One minor comments and a nit. Minor comment: IPv4v6 PDP-Context - This wasn't defined in the document, and it wasn't obvious to me what this is. Perhaps have a definition or reference to the definition in the terminology section might be helpful. Nit: attaches the network => attaches to the network Regards, Rob From nobody Mon Dec 14 04:23:06 2020 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 599593A0FB0; Mon, 14 Dec 2020 04:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 Yad1AXIlwFYT; Mon, 14 Dec 2020 04:23:00 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBA23A0F7F; Mon, 14 Dec 2020 04:22:59 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 4CvgX21PWRz30Mj; Mon, 14 Dec 2020 13:22:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607948578; bh=aybUd7ENpmFTTXpAipk6qFfeFqCPirf+FF/iMjOhG8A=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=KivKdDFqVgc66R7c1BPtOg4wqSEVIw43Xirkh+g4nsPYZisebPDFPI7A9AEPK8YBw Xo4vbnq+34yfcOLm20HLxXy4IK+5+xlVcwOIrokMenovrO5CfLRrAktXPFaoX9uvRh op0MCtrBUHt98i782zVEWQqQayWcRfS9ymzszo3XflnUxhvuv0DKDWn5JNhT4ytyJ1 8ad5H065QA5GKvT2DMBnWb/l6bVjwSV1qyesAaP6XLKX5+G+KzjLpAcSLhD1qNvT5u Eh0U2GpEOIp4fjt6zU+SIP8J3tvbrStBdTabP7ezE2L1SK/eFOV2ZlYgroUbxoLfju FrB1FlZBfNOBQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 4CvgX16tcHzCqkq; Mon, 14 Dec 2020 13:22:57 +0100 (CET) From: To: Robert Wilton , The IESG CC: "draft-ietf-ipsecme-ipv6-ipv4-codes@ietf.org" , "ipsecme-chairs@ietf.org" , "ipsec@ietf.org" , "David Waltermire" , Yoav Nir Thread-Topic: Robert Wilton's No Objection on draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT) Thread-Index: AQHW0gkyJmDWpFEEm0eNYItlaWA81Kn2gfIA Date: Mon, 14 Dec 2020 12:21:34 +0000 Message-ID: <10095_1607948578_5FD75921_10095_157_7_787AE7BB302AE849A7480A190F8B93303159CE20@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160794399531.23637.14475252681712118057@ietfa.amsl.com> In-Reply-To: <160794399531.23637.14475252681712118057@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Robert Wilton's No Objection on draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT) 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, 14 Dec 2020 12:23:01 -0000 SGkgUm9iLCANCg0KU3VyZS4gQWRkZWQgYSBwb2ludGVyIHRvIHJmYzY0NTkjc2VjdGlvbi0zLjIg d2hlcmUgZGVmaW5pdGlvbnMgb2YgUERQIGNvbnRleHQgKyBQRFAgdHlwZXMgKHY0LCB2NiwgdjR2 NikgY2FuIGJlIGZvdW5kLiANCg0KWW91IGNhbiBzZWUgYSBkaWZmIGhlcmU6IGh0dHBzOi8vdGlu eXVybC5jb20vaWtlLXY0djYtY29kZXMuIA0KDQpUaGFuayB5b3UuIA0KDQpDaGVlcnMsDQpNZWQN Cg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogUm9iZXJ0IFdpbHRvbiB2 aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYub3JnXQ0KPiBFbnZvecOpwqA6IGx1 bmRpIDE0IGTDqWNlbWJyZSAyMDIwIDEyOjA3DQo+IMOAwqA6IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPg0KPiBDY8KgOiBkcmFmdC1pZXRmLWlwc2VjbWUtaXB2Ni1pcHY0LWNvZGVzQGlldGYub3Jn OyBpcHNlY21lLQ0KPiBjaGFpcnNAaWV0Zi5vcmc7IGlwc2VjQGlldGYub3JnOyBEYXZpZCBXYWx0 ZXJtaXJlDQo+IDxkYXZpZC53YWx0ZXJtaXJlQG5pc3QuZ292PjsgWW9hdiBOaXIgPHluaXIuaWV0 ZkBnbWFpbC5jb20+Ow0KPiB5bmlyLmlldGZAZ21haWwuY29tDQo+IE9iamV0wqA6IFJvYmVydCBX aWx0b24ncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1pcHNlY21lLWlwdjYtDQo+IGlwdjQt Y29kZXMtMDU6ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBSb2JlcnQgV2lsdG9uIGhhcyBlbnRlcmVk IHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWlwc2VjbWUt aXB2Ni1pcHY0LWNvZGVzLTA1OiBObyBPYmplY3Rpb24NCj4gDQo+IFdoZW4gcmVzcG9uZGluZywg cGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvDQo+IGFsbCBl bWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJl ZSB0bw0KPiBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+ IA0KPiBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQv ZGlzY3Vzcy0NCj4gY3JpdGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJ RVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVu dCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToN Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHNlY21lLWlw djYtaXB2NC1jb2Rlcy8NCj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gQ09NTUVO VDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gDQo+IEhpIE1lZCwNCj4gDQo+IFRoYW5rcyBmb3Ig dGhpcyBkb2N1bWVudC4gIEkgZm91bmQgaXQgcHJldHR5IGVhc3kgdG8gcmVhZCBhbmQNCj4gZm9s bG93Lg0KPiANCj4gT25lIG1pbm9yIGNvbW1lbnRzIGFuZCBhIG5pdC4NCj4gDQo+IE1pbm9yIGNv bW1lbnQ6DQo+IA0KPiBJUHY0djYgUERQLUNvbnRleHQNCj4gIC0gVGhpcyB3YXNuJ3QgZGVmaW5l ZCBpbiB0aGUgZG9jdW1lbnQsIGFuZCBpdCB3YXNuJ3Qgb2J2aW91cyB0byBtZQ0KPiB3aGF0IHRo aXMgIGlzLiAgUGVyaGFwcyBoYXZlIGEgZGVmaW5pdGlvbiBvciByZWZlcmVuY2UgdG8gdGhlDQo+ IGRlZmluaXRpb24gaW4gdGhlICB0ZXJtaW5vbG9neSBzZWN0aW9uIG1pZ2h0IGJlIGhlbHBmdWwu DQo+IA0KPiBOaXQ6DQo+IA0KPiAgYXR0YWNoZXMgdGhlIG5ldHdvcmsgPT4gYXR0YWNoZXMgdG8g dGhlIG5ldHdvcmsNCj4gDQo+IFJlZ2FyZHMsDQo+IFJvYg0KPiANCj4gDQoNCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRo YW5rIHlvdS4KCg== From nobody Mon Dec 14 08:32:10 2020 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 C2C083A150F for ; Mon, 14 Dec 2020 08:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[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 p68Wzhw3uMeq for ; Mon, 14 Dec 2020 08:32:07 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 771643A1505 for ; Mon, 14 Dec 2020 08:32:07 -0800 (PST) Received: from [192.168.2.5] (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 A6F2460F5D; Mon, 14 Dec 2020 16:32:06 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_19ED718A-DE66-490E-B9D8-07C9C52D637C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 14 Dec 2020 11:32:05 -0500 In-Reply-To: Cc: Christian Hopps , Don Fedyk To: "ipsec@ietf.org" References: X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] YANG for IP-TFS 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, 14 Dec 2020 16:32:09 -0000 --Apple-Mail=_19ED718A-DE66-490E-B9D8-07C9C52D637C Content-Type: multipart/alternative; boundary="Apple-Mail=_63D094D0-9FD8-43FD-A5B3-983FAC5A12E6" --Apple-Mail=_63D094D0-9FD8-43FD-A5B3-983FAC5A12E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Is there anything holding this up? Thanks, Chris. > On Dec 3, 2020, at 11:37 AM, Don Fedyk wrote: >=20 > Hi >=20 > As asked in the 109 meeting, could we start the call for adoption for = draft-fedyk-ipsecme-yang-iptfs-01 = ? >=20 > Thanks > Don > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Apple-Mail=_63D094D0-9FD8-43FD-A5B3-983FAC5A12E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Is there anything holding this up?

Thanks,
Chris.

On Dec 3, 2020, at 11:37 AM, Don Fedyk <dfedyk@labn.net> = wrote:

Hi 
 
As asked in the 109 = meeting, could we start the call for adoption for draft-fedyk-ipsecme-yang-iptfs-01?
 
Thanks
Don
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_63D094D0-9FD8-43FD-A5B3-983FAC5A12E6-- --Apple-Mail=_19ED718A-DE66-490E-B9D8-07C9C52D637C 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/Xk4UACgkQLh2DDte4 MCXn+xAAoekPZvNHbTfwbsJItzkQcwgm/Gu/GzIvLuPbgY9NVxjo6ENpjQfutjAV 3K3MNcK2sy/Uw3xAWHFb6qssfnzTMOjn+d8M9xLojp130uyUwA0DsrJAFsOECUsw zDiHFvHzJzM+Su/cjzaBgmnfKyKhJnhjOa8aTAiwbjRf1+nxPruJonK9MEu/UR5j xQpkOPBEj9dGX2abhyGFSvvv9g+P99L6dceSFzDISLKSordp/GF/AZm07wQ3zcYT wBxnDq1qth2LT5G2y7g28E8nQhMCyJhu+wytnNGd+jo/ZbFDQtNiS/Hz7yXAQvHR DziozKelRJC/I1YLFnUEkmXQgxTRe8EuqRSm1h0jnqEihIvWw10YHhWv5nXHdhgr geRvMmbocMfYihITgp71oT4QJI4x5KQWi97a7PnXoBgbAlWDGtiz3CsBRfUGpFc9 NjjKxQUxHLNyRHfCs1cQws2Ga8dMgnW3d5ZCWtqBR0bJhcJYoUdps4v6pgJtriVp 1nzWt1ZcK32HS5FaQgJxFxYJKShxNNvDDzmrSoqgfQX+lw2HTEDOaLJFGMUNoyry abga4g98/72f3lLC8jtB5TNmJD1CcL/iGf/T2lVM9/R3HMckAmOl2WGOvdnjZnIv sYNHgxWfuwNhaQuL/Pr1vzlso4/QpzkMltH9e5R68w/5o80bup0= =gyqH -----END PGP SIGNATURE----- --Apple-Mail=_19ED718A-DE66-490E-B9D8-07C9C52D637C-- From nobody Wed Dec 16 11:03:14 2020 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 9CDE33A0EC8 for ; Wed, 16 Dec 2020 11:03:00 -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_NONE=-0.0001, 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 X3qpoXtBj0J0 for ; Wed, 16 Dec 2020 11:02:55 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 6BB683A0B44 for ; Wed, 16 Dec 2020 11:02:55 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id s75so28765535oih.1 for ; Wed, 16 Dec 2020 11:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6F6Zz5+W6DTRWUO0ds99IXg1ijbjjDwmnBBjL3R41Kk=; b=ngeh9JKn/EBww05yP55a/YCTtXATeFoQwmLksnL2v0SGyfzaZdRQD/+ybxfBKzOYto q2+tiAD5KkmiAWK0kB3MACThvSZEpOi+wJMxSlE0IMw1DPDVRmyf5D83pyJ6tyFBweCE 6uaAkk7DNphzQ10XGO2+WK+J4MEiGjgsUEpx/BdppFXvKPETTNE+gcgP77j8qZaHpQff nHM5i8w8yceAPS2bqMgs8L74f9XMNJC0vPNmkBmjZ3W/JVk1SZnuw6/QBlysxnSIYvT9 RlIe8SNHO9wC0qr3e4tqnu9LyiYQ8pJIeG94/qQeL42qy4Y3VVOhuRT7LYKwASgM/xQA SOXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6F6Zz5+W6DTRWUO0ds99IXg1ijbjjDwmnBBjL3R41Kk=; b=VKbA0CZW5OIqSxl0A0cpx5SuSFtOp16w3o5oAIrmTgAO0IVlaimupqish9GV6iNhaR aMnGIom/uxoNJiQrNWrgr5EZZhLGJwU6e6TzrEoNVItHvIxYwCO3Gl0SDVhoFrc+MOvW i5IXBTkst8Ccm8rtaSjyDP4f+4rp4w0SQ0gUZ6mMUhJKhMbtbUOpMU/bTGZUkDEkc/iC MR8iiRvh/na8GYChNGs2K6ifkvMroL5tNuNYUUIPqbrJRoyD/0CGAFqCc981L+B7G55L RP/bolVOJNxRy9Yf62gvYR+A2hndaQ/36pAgRmPNztiqHKd98EncRu9b0wkf44Fmxha3 NVYQ== X-Gm-Message-State: AOAM531VyM0SDfLE1EZyiDrriojeY36x4pGa1b/G9d95EAv7ey3sN+eO GHtJ9CskgeQuAzUWRr7A8IKYkaDJI13bksTbckM= X-Google-Smtp-Source: ABdhPJywGabtmLbFPUVrg5SkIYlS2lD0sYczOmWEDj7LMBkzrv8W+ygssq+4Izrk12oee3yHoqyOSkehZpW0mGsUeFU= X-Received: by 2002:aca:c7c2:: with SMTP id x185mr2773785oif.143.1608145374663; Wed, 16 Dec 2020 11:02:54 -0800 (PST) MIME-Version: 1.0 References: <20201117184621.11715F40741@rfc-editor.org> <20201206231146.GG64351@kduck.mit.edu> In-Reply-To: <20201206231146.GG64351@kduck.mit.edu> From: Jonathan Hammell Date: Wed, 16 Dec 2020 14:02:43 -0500 Message-ID: To: Benjamin Kaduk Cc: ipsec@ietf.org, rdd@cert.org, simon@josefsson.org, kivinen@iki.fi, ynir.ietf@gmail.com, christian.tschudin@unibas.ch Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [IPsec] [Technical Errata Reported] RFC8031 (6339) 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, 16 Dec 2020 19:03:07 -0000 I verified that the example in Appendix A of RFC 8031 is incorrect as reported, but I do not believe that updating the values as suggested in this errata completely fixes the example. The corrected values given in the report are valid if they are interpreted as little-endian encoded coordinates (i.e. apply decodeUCoordinate from RFC 7448). However, RFC 8031 (and the reporter) represented pub_i, pub_r and SHARED_SECRET as a byte-separated strings, whereas earlier values in 8031 in this byte-separated format (random_i, random_r, fixed_i, fixed_r) all appear to be in big endian order and the d_i and d_r explicitly encoded in little-endian are given as a single string. Therefore, I think the pub_i, pub_r, SHARED_SECRET values should be in big endian order if they are byte-separated, or as a single little-endian encoded string (i.e. remove the spacings between bytes). Additionally, I believe that fixed_i and fixed_r are incorrect according to the clamping procedure from RFC 7748 (i.e. decodeScalar25519). This decodeScalar25519 can be unambiguously applied directly to the given d_i and this should result in fixed_i. However, the least significant byte of decodeScalar25519(d_i) is 0x50 not matching 0x54 in fixed_i. Similarly, the most significant byte of decodeScalar25519(d_r) is 0x48 not matching 0x08 in fixed_r. It would appear that the clamping was incorrectly applied to the big-endian ordered strings, random_i and random_r, to obtain the fixed_i and fixed_r values in the RFC. So to correct this, we should have fixed_i =3D 70 1f b4 30 86 55 b4 76 b6 78 9b 73 25 f9 ea 8c dd d1 6a 58 53 3f f6 d9 e6 00 09 46 4a 5f 9d 50 fixed_r =3D 48 54 64 52 53 29 0d 60 dd ad d0 e0 30 ba cd 9e 55 01 ef dc 22 07 55 a1 e9 78 f1 b8 39 a0 56 48 and random_i and random_r must be also updated to account for the clamping applied on the little-endian ordered bytes, allowing some freedom in choice of the bits masked out. For example, one could use random_i =3D b0 1f b4 30 86 55 b4 76 b6 78 9b 73 25 f9 ea 8c dd d1 6a 58 53 3f f6 d9 e6 00 09 46 4a 5f 9d 56 random_r =3D 88 54 64 52 53 29 0d 60 dd ad d0 e0 30 ba cd 9e 55 01 ef dc 22 07 55 a1 e9 78 f1 b8 39 a0 56 4a Jonathan On Sun, Dec 6, 2020 at 6:12 PM Benjamin Kaduk wrote: > > Can anyone speak to the history of the examples here (or the content of t= he > report itself)? > > Thanks, > > Ben > > On Tue, Nov 17, 2020 at 10:46:21AM -0800, RFC Errata System wrote: > > The following errata report has been submitted for RFC8031, > > "Curve25519 and Curve448 for the Internet Key Exchange Protocol Version= 2 (IKEv2) Key Agreement". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6339 > > > > -------------------------------------- > > Type: Technical > > Reported by: Christian Tschudin > > > > Section: Appendix A > > > > Original Text > > ------------- > > The public keys are generated from this using the formula in > > Section 2: > > > > pub_i =3D X25519(d_i, G) =3D > > 48 d5 dd d4 06 12 57 ba 16 6f a3 f9 bb db 74 f1 > > a4 e8 1c 08 93 84 fa 77 f7 90 70 9f 0d fb c7 66 > > > > pub_r =3D X25519(d_r, G) =3D > > 0b e7 c1 f5 aa d8 7d 7e 44 86 62 67 32 98 a4 43 > > 47 8b 85 97 45 17 9e af 56 4c 79 c0 ef 6e ee 25 > > > > And this is the value of the Key Exchange Data field in the Key > > Exchange payload described in Section 3.1. The shared value is > > calculated as in Section 2: > > > > SHARED_SECRET =3D X25519(d_i, pub_r) =3D X25519(d_r, pub_i) =3D > > c7 49 50 60 7a 12 32 7f-32 04 d9 4b 68 25 bf b0 > > 68 b7 f8 31 9a 9e 37 08-ed 3d 43 ce 81 30 c9 50 > > > > > > Corrected Text > > -------------- > > The public keys are generated from this using the formula in > > Section 2: > > > > pub_i =3D X25519(d_i, G) =3D > > a7 07 b3 bc 0f 37 56 fc 0a cf 33 55 85 c5 f7 7b > > 9f 29 ff a4 24 70 14 af 84 70 5b eb 50 46 26 29 > > > > pub_r =3D X25519(d_r, G) =3D > > 0e 57 7e 11 5d 6c 08 59 b8 51 36 d2 1b 1c fd 74 > > 67 9f 91 14 61 1d 79 c6 81 ba d0 8a 7e 1f 0a 04 > > > > And this is the value of the Key Exchange Data field in the Key > > Exchange payload described in Section 3.1. The shared value is > > calculated as in Section 2: > > > > SHARED_SECRET =3D X25519(d_i, pub_r) =3D X25519(d_r, pub_i) =3D > > d6 8d 8c ea fd 2c d3 ce 25 34 43 33 c8 9e 35 54 > > 9e 0f c6 1a 98 87 39 34 b1 8a 18 70 f0 3a 17 0c > > > > > > Notes > > ----- > > The test vector values given both for the public keys and for the share= d secret are wrong. It turns out that they were derived from the unchanged = random input, instead of d_X. An explanation could be that a first text ver= sion did not include the fixing of the random bits and that after inserting= the respective paragraph (introducing fixed_X and d_X), it was forgotten t= o update pub_X and SHARED_SECRET. > > > > This discrepancy came to my attention when testing the Yubikey 5 hardwa= re and comparing it with the NaCl library and RFC8031. While the NaCl libra= ry works as expected, it is disturbing to see that the Yubikey can only be = made to produce the desired (above and corrected) shared secret if you let = it compute X25519(fixed_i,pub_r). That is, the secret must be presented to = the Yubikey in big-endian format which could be "inspired" by the (not very= detailed) Smartcard spec 3.4.1 that refers to ANSI X9.62 where curve param= eters, prefixed with 0x04, are encoded in big-endian order - clearly the AN= SI encoding is not useful here as we only need one parameter u. I wonder wh= ether RFC8031 should spell out that input parameters (d_X and pub_X) SHOULD= be presented in encoded form (and thus little-endian), hence putting manuf= acturers in charge of documenting any deviation. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8031 (draft-ietf-ipsecme-safecurves-05) > > -------------------------------------- > > Title : Curve25519 and Curve448 for the Internet Key Exch= ange Protocol Version 2 (IKEv2) Key Agreement > > Publication Date : December 2016 > > Author(s) : Y. Nir, S. Josefsson > > Category : PROPOSED STANDARD > > Source : IP Security Maintenance and Extensions > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Dec 16 18:15:20 2020 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 E1C663A0A4A; Wed, 16 Dec 2020 18:15:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-ipsecme-ipv6-ipv4-codes@ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org, David Waltermire , Yoav Nir , ynir.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <160817131443.8881.5607800924571365314@ietfa.amsl.com> Date: Wed, 16 Dec 2020 18:15:14 -0800 Archived-At: Subject: [IPsec] Erik Kline's Yes on draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT) 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: Thu, 17 Dec 2020 02:15:15 -0000 Erik Kline has entered the following ballot position for draft-ietf-ipsecme-ipv6-ipv4-codes-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ comments/questions ]] [ section 5 ] * I concur with Eric V. w.r.t. MUST vs SHOULD for dualstack initiators. As written it seems to me like it might be overspecified. * I'm confused about the last entry in the table. If there's a policy restriction to only a single address family, are both IP4 and IP6 _ALLOWED returned? Instead of "4,6" should this be "4|6"? From nobody Wed Dec 16 18:19:59 2020 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 8C6623A1377; Wed, 16 Dec 2020 18:19:54 -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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=4WMX5aEE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EvzLAkA8 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 YfBhnXTlorXW; Wed, 16 Dec 2020 18:19:52 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8915B3A0ABB; Wed, 16 Dec 2020 18:19:49 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B7D365C015C; Wed, 16 Dec 2020 21:19:48 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 16 Dec 2020 21:19:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=2 JKfE3cxsQHU4aj5UQ0E1k8lQL8VZCgp+tp6n9f4YpI=; b=4WMX5aEEnqXbKf0vu A12/xnMfHdXavajODbj21I7uIVllg6p6+iTtRXJEFTNQ+clcqBpwukQKn69IZIqT sgGErAjXHO3PJqARnSkHICNCCtoKj1sYqvERl0yz59aCUujpW4g9Xea1Nw1fUhsC QPSQwAmw2F1cF2zucFMrL7jhlPaa7aKA/JD1vtdARIDCm6NPacKg0H2PIoBytBfD 6IRSqpDO5sl+M5zZ9En5y7nUUGWYxblKCf5e33pvYuXDUHTY5I5cfbvGqDoB/09k AUUDfFLvkZ817rbmbVK6p2LXF4BQ8nUqR8//M1eoZXoEqQOF59Z16Qw5+5y2bA1P aeB4g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=2JKfE3cxsQHU4aj5UQ0E1k8lQL8VZCgp+tp6n9f4Y pI=; b=EvzLAkA8ethvCZJ0gqrHY+gAqzgFf0tQJR8mervVlODoEZ6TrwOFR4vBS 8UWh1T3BMiLxRXkU7z0OO/gVuApRhkA6i7ojvZsBiICQdVg3lQF9DNdJCeXvmu8T VDXm7PfTnxbDxKNivnWb0mBiiLaPAIKlP8/LUEeKuGvOEbIUxvs1NHGAVeUIXSMD L57oYhkD+DwdmizcAOiOaNjGG/NlJ/238VtuwSxZbFuHwxJ2zwaGLYdbmkfcJ5zY u3xwJgBOqtJ+jxwE36jFLMoZdA7hPjWQdxxHz8x98597V3ehVRPA3ddtNXu/z5mb MXWYRxQyfgNdogIR7SbfraHZ5rPdg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudelfedggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucggtffrrg htthgvrhhnpeefudfhgfetgfetvddvffeiuddtkeffgedvjeejtdeiheefgfelfeeutdel vdfggfenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedrudduje drledunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rghlihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from rtp-vpn4-1171.cisco.com (unknown [173.38.117.91]) by mail.messagingengine.com (Postfix) with ESMTPA id 2905D24005A; Wed, 16 Dec 2020 21:19:48 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alissa Cooper In-Reply-To: <160538957906.19443.17896302093639658374@ietfa.amsl.com> Date: Wed, 16 Dec 2020 21:19:47 -0500 Cc: gen-art@ietf.org, draft-ietf-ipsecme-ipv6-ipv4-codes.all@ietf.org, last-call@ietf.org, ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <51B02921-C646-4F6A-B7B1-4F5D8BF890D1@cooperw.in> References: <160538957906.19443.17896302093639658374@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] [Gen-art] Genart last call review of draft-ietf-ipsecme-ipv6-ipv4-codes-05 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, 17 Dec 2020 02:19:55 -0000 Robert, thanks for your review. I entered a No Objection ballot. Alissa > On Nov 14, 2020, at 4:32 PM, Robert Sparks via Datatracker = wrote: >=20 > Reviewer: Robert Sparks > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-ipsecme-ipv6-ipv4-codes-05 > Reviewer: Robert Sparks > Review Date: 2020-11-14 > IETF LC End Date: 2020-12-01 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Ready for publication as a Proposed Standard RFC >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Dec 16 21:39:11 2020 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 315F53A147B; Wed, 16 Dec 2020 21:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 E4VEAgYpotLq; Wed, 16 Dec 2020 21:39:04 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B51B3A1474; Wed, 16 Dec 2020 21:39:04 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 4CxLQZ5l04z1yFL; Thu, 17 Dec 2020 06:39:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608183542; bh=Tn/iXfGxLowLvyz5fWHrHQqZLxjwTyyE4gkjczw7KIM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Gtnk6OqzJIAxv9J/Kbetuw41wSkmenCqHTQ/yfVyopLKux85sTGvkelUZVAUcNbRl 44yvibTJ2yAJEaTrOymWZoul5slQ00EN8odYix4kZFkNBwK7zWB3MTfbLesh7ojCT8 chPJkrvjw1Cwnksap86XoQ9SY6KIPAxux0f5aWzkm64FNRyFHDiHYcfN6FTwgDXmlT LwMQhgGI6UJyFKnN9bC1TEKR/rtW0Je8jincBbQNu1vvO6uM5OPLBuxrnmPfp+asWu syYQNuXPUvPeuYX9HVLdi+POtP4/WZaS3LeMqXiLWsafs8G1WW8AnAsvk9idmi+8pW HJ2uSsBR66lsQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 4CxLQZ45nkzDq8r; Thu, 17 Dec 2020 06:39:02 +0100 (CET) From: To: Erik Kline , The IESG CC: "draft-ietf-ipsecme-ipv6-ipv4-codes@ietf.org" , "ipsecme-chairs@ietf.org" , "ipsec@ietf.org" , "David Waltermire" , Yoav Nir Thread-Topic: Erik Kline's Yes on draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT) Thread-Index: AQHW1Bp2mucC70DqgkmssO9/DsEauKn6vYJg Date: Thu, 17 Dec 2020 05:39:01 +0000 Message-ID: <28520_1608183542_5FDAEEF6_28520_376_1_787AE7BB302AE849A7480A190F8B93303159ECDE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160817131443.8881.5607800924571365314@ietfa.amsl.com> In-Reply-To: <160817131443.8881.5607800924571365314@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Erik Kline's Yes on draft-ietf-ipsecme-ipv6-ipv4-codes-05: (with COMMENT) 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, 17 Dec 2020 05:39:06 -0000 SGkgRXJpayAsDQoNClRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzLiANCg0KRm9jdXNpbmcgb24g dGhlIHNlY29uZCBxdWVzdGlvbiBhcyBJIGFscmVhZHkgY2xhcmlmaWVkIHRoZSBmaXJzdCBvbmUu IA0KDQpUaGUgbm90aWZpY2F0aW9uIGNvZGVzIGFyZSBkZXNpZ25lZCBzbyB0aGF0IHRoZSByZXNw b25kZXIgd2lsbCBhbHdheXMgcmVwbHkgd2l0aCB0aGUgc2FtZSB2YWx1ZXMgKHRoYXQgcmVmbGVj dCBpdHMgY2FwYWJpbGl0aWVzKSBhbmQgbm90IGFzIGEgZnVuY3Rpb24gb2YgdGhlIHJlcXVlc3Qu IFNvLCBib3RoIGNvZGVzIHdpbGwgYmUgcmV0dXJuZWQgdG9nZXRoZXIgd2l0aCB0aGUgYXNzaWdu ZWQgYWRkcmVzcy9wcmVmaXguIA0KDQpJZiB0aGUgaW5pdGlhdG9yIGlzIHN0aWxsIGludGVyZXN0 ZWQgaW4gdGhlIG90aGVyIEFGLCBpdCBoYXMgdG8gZm9sbG93OiANCg0KICAgSWYgYSBkdWFsLXN0 YWNrIGluaXRpYXRvciByZXF1ZXN0cyBib3RoIGFuIElQdjYgcHJlZml4IGFuZCBhbiBJUHY0DQog ICBhZGRyZXNzIGJ1dCByZWNlaXZlcyBhbiBJUHY2IHByZWZpeCAob3IgYW4gSVB2NCBhZGRyZXNz KSBvbmx5IHdpdGgNCiAgIGJvdGggSVA0X0FMTE9XRUQgYW5kIElQNl9BTExPV0VEIG5vdGlmaWNh dGlvbiBzdGF0dXMgdHlwZXMgZnJvbSB0aGUNCiAgIHJlc3BvbmRlciwgdGhlIGluaXRpYXRvciBN QVkgc2VuZCBhIHJlcXVlc3QgZm9yIHRoZSBvdGhlciBBRiAoaS5lLiwNCiAgIElQdjQgYWRkcmVz cyAob3IgSVB2NiBwcmVmaXgpKS4gIEluIHN1Y2ggY2FzZSwgdGhlIGluaXRpYXRvciBNVVNUDQog ICBjcmVhdGUgYSBuZXcgSUtFIFNlY3VyaXR5IEFzc29jaWF0aW9uIChTQSkgYW5kIHJlcXVlc3Qg dGhhdCBhbm90aGVyDQogICBhZGRyZXNzIGZhbWlseSB1c2luZyB0aGUgbmV3IElLRSBTQS4NCg0K Q2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IEVy aWsgS2xpbmUgdmlhIERhdGF0cmFja2VyIFttYWlsdG86bm9yZXBseUBpZXRmLm9yZ10NCj4gRW52 b3nDqcKgOiBqZXVkaSAxNyBkw6ljZW1icmUgMjAyMCAwMzoxNQ0KPiDDgMKgOiBUaGUgSUVTRyA8 aWVzZ0BpZXRmLm9yZz4NCj4gQ2PCoDogZHJhZnQtaWV0Zi1pcHNlY21lLWlwdjYtaXB2NC1jb2Rl c0BpZXRmLm9yZzsgaXBzZWNtZS0NCj4gY2hhaXJzQGlldGYub3JnOyBpcHNlY0BpZXRmLm9yZzsg RGF2aWQgV2FsdGVybWlyZQ0KPiA8ZGF2aWQud2FsdGVybWlyZUBuaXN0Lmdvdj47IFlvYXYgTmly IDx5bmlyLmlldGZAZ21haWwuY29tPjsNCj4geW5pci5pZXRmQGdtYWlsLmNvbQ0KPiBPYmpldMKg OiBFcmlrIEtsaW5lJ3MgWWVzIG9uIGRyYWZ0LWlldGYtaXBzZWNtZS1pcHY2LWlwdjQtY29kZXMt MDU6DQo+ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBFcmlrIEtsaW5lIGhhcyBlbnRlcmVkIHRoZSBm b2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiBkcmFmdC1pZXRmLWlwc2VjbWUtaXB2Ni1p cHY0LWNvZGVzLTA1OiBZZXMNCj4gDQo+IFdoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhl IHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvDQo+IGFsbCBlbWFpbCBhZGRyZXNzZXMg aW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0bw0KPiBjdXQgdGhp cyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCj4gDQo+IA0KPiBQbGVhc2UgcmVm ZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy0NCj4gY3Jp dGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5k IENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBv dGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pcHNlY21lLWlwdjYtaXB2NC1jb2Rlcy8N Cj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gLS0NCj4gDQo+IFtbIGNvbW1lbnRzL3F1ZXN0aW9ucyBdXQ0KPiANCj4gWyBzZWN0aW9u IDUgXQ0KPiANCj4gKiBJIGNvbmN1ciB3aXRoIEVyaWMgVi4gdy5yLnQuIE1VU1QgdnMgU0hPVUxE IGZvciBkdWFsc3RhY2sNCj4gaW5pdGlhdG9ycy4NCj4gICBBcyB3cml0dGVuIGl0IHNlZW1zIHRv IG1lIGxpa2UgaXQgbWlnaHQgYmUgb3ZlcnNwZWNpZmllZC4NCj4gDQo+ICogSSdtIGNvbmZ1c2Vk IGFib3V0IHRoZSBsYXN0IGVudHJ5IGluIHRoZSB0YWJsZS4gIElmIHRoZXJlJ3MgYQ0KPiBwb2xp Y3kNCj4gICByZXN0cmljdGlvbiB0byBvbmx5IGEgc2luZ2xlIGFkZHJlc3MgZmFtaWx5LCBhcmUg Ym90aCBJUDQgYW5kIElQNg0KPiAgIF9BTExPV0VEIHJldHVybmVkPyAgSW5zdGVhZCBvZiAiNCw2 IiBzaG91bGQgdGhpcyBiZSAiNHw2Ij8NCj4gDQo+IA0KDQoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Thu Dec 17 01:39:22 2020 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 A8C0C3A1589 for ; Thu, 17 Dec 2020 01:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 cecPKlggAisY for ; Thu, 17 Dec 2020 01:39:18 -0800 (PST) Received: from mail.strongswan.org (sitav-80046.hsr.ch [152.96.80.46]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF38E3A1586 for ; Thu, 17 Dec 2020 01:39:17 -0800 (PST) Received: from [IPv6:2a01:8b81:5401:ba00:65b3:9f81:3aa3:3c02] (unknown [IPv6:2a01:8b81:5401:ba00:65b3:9f81:3aa3:3c02]) by mail.strongswan.org (Postfix) with ESMTPSA id 91D9840369; Thu, 17 Dec 2020 10:39:15 +0100 (CET) To: Jonathan Hammell , Benjamin Kaduk Cc: rdd@cert.org, simon@josefsson.org, christian.tschudin@unibas.ch, kivinen@iki.fi, ipsec@ietf.org, ynir.ietf@gmail.com References: <20201117184621.11715F40741@rfc-editor.org> <20201206231146.GG64351@kduck.mit.edu> From: Tobias Brunner Autocrypt: addr=tobias@strongswan.org; prefer-encrypt=mutual; keydata= xsFNBFNaX0kBEADIwotwcpW3abWt4CK9QbxUuPZMoiV7UXvdgIksGA1132Z6dICEaPPn1SRd BnkFBms+I2mNPhZCSz409xRJffO41/S+/mYCrpxlSbCOjuG3S13ubuHdcQ3SmDF5brsOobyx etA5QR4arov3abanFJYhis+FTUScVrJp1eyxwdmQpk3hmstgD/8QGheSahXj8v0SYmc1705R fjUxmV5lTl1Fbszjyx7Er7Wt+pl+Bl9ReqtDnfBixFvDaFu4/HnGtGZ7KOeiaElRzytU24Hm rlW7vkWxtaHf94Qc2d2rIvTwbeAan1Hha1s2ndA6Vk7uUElT571j7OB2+j1c0VY7/wiSvYgv jXyS5C2tKZvJ6gI/9vALBpqypNnSfwuzKWFH37F/gww8O2cB6KwqZX5IRkhiSpBB4wtBC2/m IDs5VPIcYMCpMIGxinHfl7efv3+BJ1KFNEXtKjmDimu2ViIFhtOkSYeqoEcU+V0GQfn3RzGL 0blCFfLmmVfZ4lfLDWRPVfCP8pDifd3L2NUgekWX4Mmc5R2p91unjs6MiqFPb2V9eVcTf6In Dk5HfCzZKeopmz5+Ewwt+0zS1UmC3+6thTY3h66rB/asK6jQefa7l5xDg+IzBNIczuW6/YtV LrycjEvW98HTO4EMxqxyKAVpt33oNbNfYTEdoJH2EzGYRkyIVQARAQABzSZUb2JpYXMgQnJ1 bm5lciA8dG9iaWFzQHN0cm9uZ3N3YW4ub3JnPsLBdwQTAQgAIQUCU1pfSQIbAwULCQgHAwUV CgkICwUWAgMBAAIeAQIXgAAKCRB2X+Jsa0Z1hMj6EACJPua/RIe0u8ZpD1OPe2dZQGApd6l1 2BRwwYsEtYzwQOaAiB7PUdDyzAZn8amf9/FvgGJLk2AhOz1+zigcKotCoqlGLS/d+vMf2Hxc TlZirtzRes3WlzXSI06MS1IwYS+1Qg5m6L4+mZzMQmbZLgXTuKH3s5/0q5kMhbqGBg7jFpOt 1WdaLDTNYoCwWg+CMfe7kAfSbL21X2XThjLLOE8FA/X50n1NflQ8zGSiM/Pv2RUGG8SQ9K3d dtlvGHzkSgMlaZvarYw5lqiSv0PzxRRcjbpVgdKGyuq5RErMW0rulZq1mKdyGy4Vpnd9mZVZ 7RG04Hi4grrnj4Frfhn9iwvG2t1pzfsr75/BTjlvQFXh35BDBVoc5P7ZOThPSMULr3v/eQiV nEQPjAju1Tz8tY0XaENRP6uj6Y+EdRVZmUrtqJ3DAu6GyzuoxMjPD/4fF+prSL016s7NJFSj 4l7dr409s89DmycwaPyImh4yMzzkqXzt25OyMIFD//oUUJRv+Z72iyZK7hqv/HOw8EdRldWg EXYKRNdt4mO364+AIOwgkGRPT2OY4JikasfQOhV6eba+5eGX0Ddz0JHSzzsmcM3GPPrJGNpV pM9jPcv70/UfStUpgMGLGhgNtS94rLMbJ/7MpXp8Kjq3DmCRAx0o3aflnqywMIE023utMVgm JxSorM7BTQRTWl9JARAA4XJKb3+HvPI9TwAk7c2HcvpCSS8ITi4d+/U1/DfpWzsjTpDevaIi qB36MkURkc9bu3uPnGigrvz66HJoA8+6CAUlkeHOvGGoPUkDBRxamnJFuaWLV8BVM3+OvWJw Av1ZwcX35IIDgmpm874C3MtyzcQVouKWiUUjA5hIz1VjdYy8hBeC/Wm/CLAOlwg/jYiM4l4n Py5a/R4Bk9oOdnHU1kIXL7cwRg9O3uwLAt1WwJfIXmpXAqPKW679nlwufTDm5mfy6rnIMHmx BIDNAqbXnMsqWWwT0k+/tvdcL4v8og5ja+QPPoaYHK9TYLl7PSDhAcvPFDbkFLtU3zGHLw88 vex8ZHydNNWXvPSCb2NN7Gay9L784SM011qbd5zvJxgDAnvW0KcKQDbC597ARTA++P29P9qV yh7rtY7MBFs4b09nPD/NLztyij4d9+OKeCOFYwzx9qAi7GSiJS3h0qH1ZSa14f8vNGo8Y1UY 54j2k1M2Ioatife+MQOw7fWRbBbW6WVaiv4cvC8NfOiuNGvoNgVRCZGLCbBhpHOVcalEEugg jV3PCLZmxYMX7oFRfEq42GT63jkAKWDQa/L44aJaKTrKzu/PCb0PVuSvr/ODgEGx2EfvFb0p a4kX0ia47zkEW5RGWdggTC4iA9S8IubzuZJ258PCXcVuIgNoP5K9vC8AEQEAAcLBXwQYAQgA CQUCU1pfSQIbDAAKCRB2X+Jsa0Z1hEc+D/0dmkUnsDTaDPWIoIDbTSTMdgBXEuB10azvA9up JA5WLbqM3ELNH8UZyRn0GeWD2YcZau3FHcB0TSFikaAqaW0TVvBvy3HWj2SRsNzLVo8TS/HQ DYx3QLKaEQAncJ4kdShV+aHKo5NPpjT6cnkfQu4fHDs8CAZHraChOT3Ajg2/wTvNNnxQwtQW J3GXkCEZzFopRAqfC2/LS8VwJqvS90eHOwsyA8DFlnzjJjKmZ4Z1RAIh/RODveJMB2eB1guA GEIs6oHkbmEFFlsKEgQMxs82oB4Oe8rOqyYsDbbyAt4/q7bqmPSIvHobZYh5VzKJDgFz4Hib rNBB4O5jBTexm5r63UzHRoXR3Xffqm84bgiQTIo7M0+caMS5aisWB/d87MdEhymaevGcmSUM J4ut2ajeT/+KMdPfDNNHlaZMtTy6fZeRAabEB/UJRqvmSzgec8UxRU7rwvTwvzNzqRVF3S6+ 8nPNxcl4eWGxlTSMUePUL+fE9WZinPR9+B99WeikSTxpgs8kMR2Emz/Sg0+Eufw8f/omjA29 RvX3bkgaz8SCE+RhJNwSpB/0qABBbO8cZJY5aIIF3ybtmv6gUwzzc7YnHLL18+VzZ10YmSK2 6TZCfIRNB7qtoHcxwvtIVjMqATSHfXNqN/MuRLb5Ie11jtsnK1tVJc1MzOCld0gyyIXzlA== Message-ID: <2b42d1f3-5efa-f247-c5a7-30ccc887433c@strongswan.org> Date: Thu, 17 Dec 2020 10:39:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [IPsec] [Technical Errata Reported] RFC8031 (6339) 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, 17 Dec 2020 09:39:20 -0000 > I verified that the example in Appendix A of RFC 8031 is incorrect as > reported, but I do not believe that updating the values as suggested > in this errata completely fixes the example. > > The corrected values given in the report are valid if they are > interpreted as little-endian encoded coordinates (i.e. apply > decodeUCoordinate from RFC 7448). However, RFC 8031 (and the reporter) > represented pub_i, pub_r and SHARED_SECRET as a byte-separated > strings, whereas earlier values in 8031 in this byte-separated format > (random_i, random_r, fixed_i, fixed_r) all appear to be in big endian > order and the d_i and d_r explicitly encoded in little-endian are > given as a single string. I think it's the other way around. The byte-separated values are all in little-endian encoding and d_i and d_r are simply given as hex-encoded numbers (in their natural big-endian encoding as you'd write a decimal number). So I think the test vectors are correct. Regards, Tobias From nobody Thu Dec 17 02:30:03 2020 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 289EE3A164C; Thu, 17 Dec 2020 02:29:51 -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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <160820099111.9635.1344500183567716973@ietfa.amsl.com> Date: Thu, 17 Dec 2020 02:29:51 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-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: Thu, 17 Dec 2020 10:29:58 -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 : IKEv2 Notification Status Types for IPv4/IPv6 Coexistence Author : Mohamed Boucadair Filename : draft-ietf-ipsecme-ipv6-ipv4-codes-06.txt Pages : 7 Date : 2020-12-17 Abstract: This document specifies new IKEv2 notification status types to better manage IPv4 and IPv6 co-existence by allowing the responder to signal to the initiator which address families are allowed. This document updates RFC7296. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ipv6-ipv4-codes-06 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ipv6-ipv4-codes-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ipv6-ipv4-codes-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 Thu Dec 17 04:34:20 2020 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 178FC3A03F3 for ; Thu, 17 Dec 2020 04:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 nHk8l8UJcTEO for ; Thu, 17 Dec 2020 04:34:17 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9DAD3A03F1 for ; Thu, 17 Dec 2020 04:34:16 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 4CxWdf3rQnzFq1s; Thu, 17 Dec 2020 13:34:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608208454; bh=4WKkXJzsWR+sU4JRNUaYJBoWoO+ihpzWPf/B/T9zuLg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=kG7VaokGRkT+62MJjMRxvFnhQBEeD4uyExiH0As++Ay9wbhnB5UZ4dqU/tpPZSvn0 /VtcwxnosBostdbvxrSq8hxN6viFkcRJ4aTG9PGXlAV/gKK2eOl+phOhBDZByGtm4U 5t4zo1QpXlOp2/n9AAc4RN0NNGEIqNEkelDL6Q6rQeR6RzhGk79J+YMkbuUQ2CCK7a IiVW3+SXhjbKpZgI2SJSR32F7Leihm22sSfGOz5gRUdqdam6+jSAKkzIM25Wbni8YK 15X4GoQb+eL1yMwisMzs1jSej0xr8bJGmGvb39jn7D5IzQyF/LfiAAMx//CT+9oycH gAYHUfn07g9Rw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4CxWdf2vZCz2xD9; Thu, 17 Dec 2020 13:34:14 +0100 (CET) From: To: "Benjamin Kaduk (kaduk@mit.edu)" , "ipsec@ietf.org" Thread-Topic: New Version Notification for draft-ietf-ipsecme-ipv6-ipv4-codes-06.txt Thread-Index: AQHW1F+QeVKK5JAdfk2VmD1qKvTZ6an7OKjA Date: Thu, 17 Dec 2020 12:34:13 +0000 Message-ID: <17074_1608208454_5FDB5046_17074_18_55_787AE7BB302AE849A7480A190F8B93303159F053@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <160820099137.9635.13267677397453397802@ietfa.amsl.com> In-Reply-To: <160820099137.9635.13267677397453397802@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] New Version Notification for draft-ietf-ipsecme-ipv6-ipv4-codes-06.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: Thu, 17 Dec 2020 12:34:19 -0000 SGkgQmVuLCBhbGwsDQoNClRoaXMgdmVyc2lvbiBpbnRlZ3JhdGVzIHRoZSBjaGFuZ2VzIGFncmVl ZCBkdXJpbmcgdGhlIElFU0cgcmV2aWV3LiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gRW52b3nDqcKgOiBqZXVkaSAxNyBkw6lj ZW1icmUgMjAyMCAxMTozMA0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOIDxtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiBPYmpldMKgOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWlldGYtaXBzZWNtZS1pcHY2LWlwdjQtDQo+IGNvZGVzLTA2LnR4dA0K PiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWlwc2VjbWUtaXB2Ni1p cHY0LWNvZGVzLTA2LnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1v aGFtZWQgQm91Y2FkYWlyIGFuZCBwb3N0ZWQgdG8NCj4gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4g DQo+IE5hbWU6CQlkcmFmdC1pZXRmLWlwc2VjbWUtaXB2Ni1pcHY0LWNvZGVzDQo+IFJldmlzaW9u OgkwNg0KPiBUaXRsZToJCUlLRXYyIE5vdGlmaWNhdGlvbiBTdGF0dXMgVHlwZXMgZm9yIElQdjQv SVB2Ng0KPiBDb2V4aXN0ZW5jZQ0KPiBEb2N1bWVudCBkYXRlOgkyMDIwLTEyLTE3DQo+IEdyb3Vw OgkJaXBzZWNtZQ0KPiBQYWdlczoJCTcNCj4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1pcHNlY21lLQ0KPiBpcHY2LWlwdjQtY29kZXMt MDYudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWlwc2VjbWUtDQo+IGlwdjYtaXB2NC1jb2Rlcy8NCj4gSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi0NCj4g aXBzZWNtZS1pcHY2LWlwdjQtY29kZXMNCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwc2VjbWUtaXB2Ni0NCj4gaXB2NC1jb2Rlcy0wNg0K PiBEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWlldGYtDQo+IGlwc2VjbWUtaXB2Ni1pcHY0LWNvZGVzLTA2DQo+IA0KPiBBYnN0cmFjdDoNCj4g ICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgbmV3IElLRXYyIG5vdGlmaWNhdGlvbiBzdGF0dXMg dHlwZXMgdG8NCj4gYmV0dGVyDQo+ICAgIG1hbmFnZSBJUHY0IGFuZCBJUHY2IGNvLWV4aXN0ZW5j ZSBieSBhbGxvd2luZyB0aGUgcmVzcG9uZGVyIHRvDQo+IHNpZ25hbA0KPiAgICB0byB0aGUgaW5p dGlhdG9yIHdoaWNoIGFkZHJlc3MgZmFtaWxpZXMgYXJlIGFsbG93ZWQuDQo+IA0KPiAgICBUaGlz IGRvY3VtZW50IHVwZGF0ZXMgUkZDNzI5Ni4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdA0KPiB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ IA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFp bnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Fri Dec 18 07:35:41 2020 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 CE6B53A08B1; Fri, 18 Dec 2020 07:35:39 -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: <160830573979.8901.15496843681021055147@ietfa.amsl.com> Date: Fri, 18 Dec 2020 07:35:39 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-04.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: Fri, 18 Dec 2020 15:35:40 -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 Traffic Flow Security Using Aggregation and Fragmentation Author : Christian Hopps Filename : draft-ietf-ipsecme-iptfs-04.txt Pages : 27 Date : 2020-12-18 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-04 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 Fri Dec 18 07:37:43 2020 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 814B23A08EB for ; Fri, 18 Dec 2020 07:37:41 -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 tkvyadn0POQA for ; Fri, 18 Dec 2020 07:37:40 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4DF3A08D6 for ; Fri, 18 Dec 2020 07:37:40 -0800 (PST) Received: from [192.168.2.5] (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 71CB26092B; Fri, 18 Dec 2020 15:37:39 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B4CDA383-4DE6-47F6-A091-B555933267D4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 18 Dec 2020 10:37:38 -0500 In-Reply-To: <0e5501d6c337$585b3bc0$0911b340$@gmail.com> Cc: Christian Hopps , Paul Wouters , ipsec@ietf.org To: Valery Smyslov References: <0e5501d6c337$585b3bc0$0911b340$@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] Some cosmetic cleanup to IPTFS draft. 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, 18 Dec 2020 15:37:42 -0000 --Apple-Mail=_B4CDA383-4DE6-47F6-A091-B555933267D4 Content-Type: multipart/alternative; boundary="Apple-Mail=_330DB6F1-FA09-4867-B179-23033227D860" --Apple-Mail=_330DB6F1-FA09-4867-B179-23033227D860 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I've posted a revision of the draft with the changes. = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-ipsecme-iptfs-03&url2=3Ddra= ft-ietf-ipsecme-iptfs-04 = Thanks, Chris. > On Nov 25, 2020, at 9:29 AM, Valery Smyslov = wrote: >=20 > Hi Paul, >=20 >> No objection from me although not a great fan of =E2=80=9CAGGFRAG=E2=80= =9D :) >=20 > Just for clarification: me too. But it serves its purpose :-) > Can you suggest better variant? >=20 > Regards, > Valery. >=20 >=20 >> Paul >>=20 >> Sent from my iPhone >>=20 >>> On Nov 25, 2020, at 08:35, Christian Hopps = wrote: >>>=20 >>> AGGFRAG >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_330DB6F1-FA09-4867-B179-23033227D860 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I've = posted a revision of the draft with the changes.

https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-ipsecme-iptfs-03= &url2=3Ddraft-ietf-ipsecme-iptfs-04

Thanks,
Chris.

On Nov 25, 2020, at 9:29 AM, Valery Smyslov <smyslov.ietf@gmail.com> wrote:

Hi = Paul,

No= objection from me although not a great fan of =E2=80=9CAGGFRAG=E2=80=9D = :)

Just for clarification: me = too. But it serves its purpose :-)
Can you suggest better = variant?

Regards,
Valery.


Paul

Sent from my iPhone

On Nov = 25, 2020, at 08:35, Christian Hopps <chopps@chopps.org> = wrote:

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

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

= --Apple-Mail=_330DB6F1-FA09-4867-B179-23033227D860-- --Apple-Mail=_B4CDA383-4DE6-47F6-A091-B555933267D4 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/czMIACgkQLh2DDte4 MCUPqw/+LsXVvqtkYVMFhGZqyo3twFdq8Iskqa6usJ5ao2PCOSYF1ClvnsIieiZ+ SMjasbcUROZUJpfu1QaT40bAfRWZdEVQKLyjJDhBG5r+EDx4oMxbGTdbDVkYqPVo Iu8hccqKly0AtCjgKfN81VwyQBjznTEm2Tq+jQX4ecG5PRqZ/YDgEUmg37kFRp2+ 7ag5XHcb/2eYPs9a4O/6b91BXSY7N7ltDQKCeAi9EcabZcWGiCjAkcu/QPDv6mTL U6R1K4FQyBwHKquqhpDhBRIeZ5YDtipctTj5b7j6Gzmelejr/cGOvA6brDu01Gu8 Gr3aaPfsBvcIJ6jZmt0B8J0GD2LyWvzJSV6mPb8QmiK7mbtu7WcMHwJSjR1PuhFV pOfFZFwu61MiRyJZHc6RWAy8qC3L6iDtBSUlTymtAQ58NM/nxXIDvQjA4mWguj85 SSiB/9Iv6Ow9xaNtSX6IM51PdzHKuFGTzXNF1eh+lbKkUHSGEjaJYtSxmRLNO37D v3wvqJuj9yi7EAsjWYNF49uylDEMqiACVIYl9lrNR4osavHBLmJ9ZneOC9Kw4uwN RYcoRzY4EkOvWiXsMfmQ12aZ+0C950N2MM13hMUcXfYP4GznvbCpsJzMKRlgRxTI 4fAmZsre5EpzLhdw6LlQcPDzT7ny7A086O6dajUZcxbsIxXG294= =kbdA -----END PGP SIGNATURE----- --Apple-Mail=_B4CDA383-4DE6-47F6-A091-B555933267D4-- From nobody Fri Dec 18 12:09:14 2020 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 48E603A08A5 for ; Fri, 18 Dec 2020 12:09:07 -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=[BAYES_40=-0.001, 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 Uqfd87mYDbCD for ; Fri, 18 Dec 2020 12:09:05 -0800 (PST) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 41E223A0880 for ; Fri, 18 Dec 2020 12:09:05 -0800 (PST) Received: by mail-oi1-x22c.google.com with SMTP id q25so4095397oij.10 for ; Fri, 18 Dec 2020 12:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H1bqfma/7wI5DBdevAaBb0H2m/T6/edwn0nCH3a8P7A=; b=lYyNHHnFo62do1ZcQYuFIR8FM7MA5vcHprybGsH9DEPatvQs6/KaeAvhy3UtlEshAT SXwA0vcZel7IRy3tiZsT2Kz+ID1B7Ccv99JGQ4NhxJBEOcQqdFMUj6RvNzLjgVJw/1Bz 1JOyZRdXhnZsPtVuaOwk3almre9a6sK2WYcKVIFPd1oKsDHZ+fabKSnG4RQdLfCUC3Kf F/9fhp5AD9QVuDpRXEV3VZpls0gOtxr382OkYzbDeRblsPsYXeOWXBeb/H1TMSmcC44L Hot6yzMoCBUVNUEOr6ReQyU0Toqy+fH1FVHWpXT8oIK7QzKHBldBZtEzeZA79oBgRA3d Wu6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H1bqfma/7wI5DBdevAaBb0H2m/T6/edwn0nCH3a8P7A=; b=gxe+jBPK1pOn8xWITVxCe7E0IWZxUsdw3Moi4txFU744qSVrzra5RJuNclA91tOXar SQT9nmpXAVOb3jX5Jy5QdrZQ7Gufv/e7OmazP5CFNQF+lXQBDUmpzTwy0DoNjUp515gX otGV6aBRT2/aEFDfZsfiKuo/g+eeEXhKKz/df7PzQ8FgZHQzUo/6xpcYx4fZ829bGwcG VGA7NEMZR8Qpudz3eIxSprOBUk0deKE1Q6O/veht4Qc51xn9ERdvdKhrQR0xQnn7uchi udb6pZtnjREbqpoVWJyCNb7DDMzPeJ0Diz19qzXLLLy3NA0zHXyOmvqb/rFu/Wwp+GQ0 QSng== X-Gm-Message-State: AOAM5302knlAd57yrCWvEvYi0OR0RY2/DH5xj7vsGzy7nenRI7G1Etjh 6mGqUSHsf77bGMiZRuLnYC99C+ireh5Ob4niJpc= X-Google-Smtp-Source: ABdhPJw/148Fee2U33M1wCLsvpiKWajWe+UfshSTHqHqra/NEUTCDbnvNE19wn8JZ2vB4Ypr9rdeTKjF1XRFRzKJKNw= X-Received: by 2002:aca:c7c2:: with SMTP id x185mr3887614oif.143.1608322144350; Fri, 18 Dec 2020 12:09:04 -0800 (PST) MIME-Version: 1.0 References: <20201117184621.11715F40741@rfc-editor.org> <20201206231146.GG64351@kduck.mit.edu> <2b42d1f3-5efa-f247-c5a7-30ccc887433c@strongswan.org> In-Reply-To: <2b42d1f3-5efa-f247-c5a7-30ccc887433c@strongswan.org> From: Jonathan Hammell Date: Fri, 18 Dec 2020 15:08:53 -0500 Message-ID: To: Tobias Brunner Cc: Benjamin Kaduk , rdd@cert.org, simon@josefsson.org, christian.tschudin@unibas.ch, kivinen@iki.fi, ipsec@ietf.org, ynir.ietf@gmail.com Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [IPsec] [Technical Errata Reported] RFC8031 (6339) 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, 18 Dec 2020 20:09:13 -0000 Dear Tobias: > I think it's the other way around. The byte-separated values are all in > little-endian encoding and d_i and d_r are simply given as hex-encoded > numbers (in their natural big-endian encoding as you'd write a decimal > number). So I think the test vectors are correct. I suppose I didn't interpret it that way given the text before d_i and d_r says "encoded in little-endian format" and there is no leading "0x" to indicate an integer versus a string. The test vectors in RFC 7748 are written similarly as a hex string without leading "0x" and must be decoded as strings (with decodeLittleEndian or decodeUCoordinate), rather than being interpreted as an integer. Given the tight relationship with RFC 7748, if RFC 8031 uses the same notation for the d_i and d_r values but must be interpreted differently is grounds for an errata, in my opinion. I suppose that clarification of the text would be acceptable. Best regards, Jonathan From nobody Sat Dec 19 01:17:54 2020 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 519ED3A0FAE; Sat, 19 Dec 2020 01:17:53 -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 SzwdYK9zJM3i; Sat, 19 Dec 2020 01:17:50 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE3C3A0FB0; Sat, 19 Dec 2020 01:17:50 -0800 (PST) Received: from [192.168.2.5] (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 5BCEB6092B; Sat, 19 Dec 2020 09:17:49 +0000 (UTC) From: Christian Hopps Message-Id: <1B7AE37A-1A16-47C5-95A3-FD131A1F0E20@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_97F9B0BA-FC19-48F0-8383-4A607082D918"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 19 Dec 2020 04:17:48 -0500 In-Reply-To: <724B2213-3B5E-4057-8343-4EE039034417@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> <724B2213-3B5E-4057-8343-4EE039034417@strayalpha.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) 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: Sat, 19 Dec 2020 09:17:53 -0000 --Apple-Mail=_97F9B0BA-FC19-48F0-8383-4A607082D918 Content-Type: multipart/alternative; boundary="Apple-Mail=_4A1DECD9-90C3-486F-A008-49C549C6EF5B" --Apple-Mail=_4A1DECD9-90C3-486F-A008-49C549C6EF5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Changes are underway. One comments inline. > On Dec 4, 2020, at 11:42 AM, Joseph Touch = wrote: >=20 > Hi, Christian, [...] >>> There is no clear utility in having the blockoffset point past the = end of the >>> current packet. It serves =E2=80=93 at best =E2=80=93 as only a = partially useful check on the >>> next packet. I.e., if the two blockoffsets disagree, presumably a = packet is >>> lost =E2=80=93 but if they agree, it cannot be concluded that a = packet is not lost. It >>> is sufficient that it points to the end of the tunnel packet. >>=20 >> No harm either though, right? Having implemented this, I can tell you = that it does help detect bugs in ones code while in development. :) >=20 > It=E2=80=99s useful as a check, but it=E2=80=99s important to explain = what the check means. >=20 > There are four cases (BO =3D blockoffsets, seq =3D ESP sequence = number) >=20 > ESP - no gap ESP - gap > --------------------------------------------------------------------- > BO - aligned OK BO-FP-err > BO - misaligned SN-FP-err Typ-err >=20 > Typ-err is the typical error when a packet is lost, because that = should result in both an ESP seqno gap and blockoffset misalignment. >=20 > SN-FP-err is when there=E2=80=99s no ESP seq no gap but the = blockoffsets are misaligned. This should only ever happen if the seqno = rolls around and you missed it, which you should have some other = mechanism to prevent (i.e., drop old packets when they=E2=80=99re half = the sequence space old - which is easy to predict because you know the = tunnel packet generation rate). >=20 > BO-FP-err is when there=E2=80=99s an ESP seq no gap but the = blockoffsets are aligned. This is just a false positive (thus =E2=80=9CFP=E2= =80=9D in my notation). S >=20 > In any of the error cases, you do not reassemble. >=20 > So checking blockoffset alignment only helps you know whether your = sequence number check and timeout discard is working correctly. >=20 > Protocol implementation correctness should be checked by test vectors, = not during normal code operation IMO. At best, it=E2=80=99s unnecessary = complexity. At worst, it gives you a false sense of wanting to = reassemble when you shouldn=E2=80=99t. Conversely, test-vectors are harder to write w/o this and must be = external, whereas this is a simple sanity check that can be added inline = (perhaps conditionally) to code which has been shown to catch bugs. This = will help implementations be more robust. Regarding complexity, having implemented this I can say there really is = no complexity :) You set the block offset to the remaining inner packet = length to be sent (or 0 if no packet fragmentation is in progress). This = value is sitting right there in the code so you can either plug it in or = use some marker value (you suggest the length to the end of the = payload). On receive the code is identical: does it exceed the length of = the payload or not. Thanks, Chris. --Apple-Mail=_4A1DECD9-90C3-486F-A008-49C549C6EF5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Changes are underway. One comments inline.

On Dec 4, 2020, at 11:42 AM, Joseph Touch <touch@strayalpha.com> wrote:

Hi, Christian,

[...]

There = is no clear utility in having the blockoffset point past the end of = the
current packet. It serves =E2=80=93 at best =E2=80=93 = as only a partially useful check on the
next packet. I.e., = if the two blockoffsets disagree, presumably a packet is
lost =E2=80=93 but if they agree, it cannot be concluded that = a packet is not lost. It
is sufficient that it points to = the end of the tunnel packet.

No harm either though, right? = Having implemented this, I can tell you that it does help detect bugs in = ones code while in development. :)

It=E2=80=99s useful as a check, but = it=E2=80=99s important to explain what the check means.

There are four cases (BO = =3D blockoffsets, seq =3D ESP sequence number)

          =                     = ESP - no gap         ESP - gap
---------------------------------------------------------------= ------
BO - aligned         =  OK                   =       BO-FP-err
BO - misaligned =    SN-FP-err             =  Typ-err

Typ-err is the typical error when a packet is lost, because = that should result in both an ESP seqno gap and blockoffset = misalignment.

SN-FP-err is when there=E2=80=99s no ESP seq no gap but the = blockoffsets are misaligned. This should only ever happen if the seqno = rolls around and you missed it, which you should have some other = mechanism to prevent (i.e., drop old packets when they=E2=80=99re half = the sequence space old - which is easy to predict because you know the = tunnel packet generation rate).

BO-FP-err is when there=E2=80=99s an = ESP seq no gap but the blockoffsets are aligned. This is just a false = positive (thus =E2=80=9CFP=E2=80=9D in my notation). S

In any of the error = cases, you do not reassemble.

So checking blockoffset alignment only = helps you know whether your sequence number check and timeout discard is = working correctly.

Protocol implementation correctness should be checked by test = vectors, not during normal code operation IMO. At best, it=E2=80=99s = unnecessary complexity. At worst, it gives you a false sense of wanting = to reassemble when you = shouldn=E2=80=99t.

Conversely, test-vectors are harder to write w/o = this and must be external, whereas this is a simple sanity check that = can be added inline (perhaps conditionally) to code which has been shown = to catch bugs. This will help implementations be more = robust.

Regarding complexity, having = implemented this I can say there really is no complexity :) You set the = block offset to the remaining inner packet length to be sent (or 0 if no = packet fragmentation is in progress). This value is sitting right there = in the code so you can either plug it in or use some marker value (you = suggest the length to the end of the payload). On receive the code is = identical: does it exceed the length of the payload or = not.

Thanks,
Chris.
= --Apple-Mail=_4A1DECD9-90C3-486F-A008-49C549C6EF5B-- --Apple-Mail=_97F9B0BA-FC19-48F0-8383-4A607082D918 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/dxTwACgkQLh2DDte4 MCWljQ/+N336/s7TimCHJ9t+P0MjaDI2bWfBOrb2X/H4irfcc7ne9lilSKB6R1fw wlMjsg4nbv9SzQWLa5eoB6/MjDu3p4sKqAL8TjWIU1ZfnefNHbS9pV3rTItGB8ou QrirpidVJGhxkHqsCr57RqrNaTIDcKLFQmFuh4TRIEE9BxONAp0/buosU558re6A liBL75usMC8GPo1mZQK9bgV1qnxx8kER9NA9y8XLkk/y9oCWcM86XEiI7FNEj1tC BT2wbM6MWjlN9U6Kf/ufAP6hVOaWRRazPvR1CmxQHXPA8CdSC9Hhp+4pF8yZOLlA Gw2z/1CC6nwO9E8dndbTHMUuzVcOiAhIukPfpB1xvbwlX7HcOQEjNCSIhAYjK6io jx/7XpN2Sl6Eu55x6EcsW8uGxBThEsbZRQZlQ5P4t3Q4cwlWCxyuR/igwiFjymAG oHPGgzB0F3XviSrC/1lfvQ5U2ceb6OCBNw8w5cgVgc7pVag8fB5+hpDi/mzaBrA6 FFPYEStTlH5cjGFlDJV5QGiztO5LPMLKxdA5AXoQtFzK3gAGO37rbjuZzptKEAYL gkf9xzsDe3iITlrFNcBT3e32cMhiCfxb0Kx2+/vlPK3AxOYc0OpfnOXSZzG/O1lB 80wlWtwysJHDkSaEKWHG5Lqq+HKMESYZEFYdIYYBaz1Z1re0RQU= =SUfM -----END PGP SIGNATURE----- --Apple-Mail=_97F9B0BA-FC19-48F0-8383-4A607082D918-- From nobody Sat Dec 19 14:17:02 2020 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 E75FB3A0C18; Sat, 19 Dec 2020 14:16:55 -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 CD6t8RGwxm6X; Sat, 19 Dec 2020 14:16:54 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id DF8F63A0C16; Sat, 19 Dec 2020 14:16:53 -0800 (PST) Received: from [192.168.2.5] (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 0E09560424; Sat, 19 Dec 2020 22:16:53 +0000 (UTC) From: Christian Hopps Message-Id: <663120BF-01DA-449A-911D-EBD17EFBE729@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_30D1212C-490F-4158-B18C-6D7A63455849"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 19 Dec 2020 17:16:52 -0500 In-Reply-To: <559B100B-4BC2-4E95-AFF8-95BBAE0BDAC8@chopps.org> Cc: Christian Hopps , ipsec@ietf.org, tsv-art@ietf.org, draft-ietf-ipsecme-iptfs.all@ietf.org To: Joseph Touch References: <160706317241.25013.15326204319913211090@ietfa.amsl.com> <559B100B-4BC2-4E95-AFF8-95BBAE0BDAC8@chopps.org> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [IPsec] 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: Sat, 19 Dec 2020 22:16:56 -0000 --Apple-Mail=_30D1212C-490F-4158-B18C-6D7A63455849 Content-Type: multipart/alternative; boundary="Apple-Mail=_DBD8CAC8-9B15-4C15-8D42-CA37AE0F4A1E" --Apple-Mail=_DBD8CAC8-9B15-4C15-8D42-CA37AE0F4A1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 4, 2020, at 3:14 AM, Christian Hopps 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). "IP-TFS never IP fragments the inner packets and the inner packets will = not affect the fragmentation of the outer encapsulation packets." Do you think I should expand a bit more on that text to anything more = clear? >> 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 = section 5.1.2.1 in = particular). >> 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. >> - Specification of the >> EMTU_R of the tunnel itself, and how that is determined - There is no maximum, all IP packet sizes are supported. :) >> 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. Thanks, Chris. --Apple-Mail=_DBD8CAC8-9B15-4C15-8D42-CA37AE0F4A1E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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).

"IP-TFS never IP fragments the inner packets and the = inner packets will not affect the fragmentation of the = outer encapsulation packets."

Do you think I should expand a bit more on that = text to anything more clear?

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).

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.

- =       Specification of the
EMTU_R of the tunnel itself, and how that is determined = -

There is = no maximum, all IP packet sizes are supported. :)

=       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.

Thanks,
Chris.


= --Apple-Mail=_DBD8CAC8-9B15-4C15-8D42-CA37AE0F4A1E-- --Apple-Mail=_30D1212C-490F-4158-B18C-6D7A63455849 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/ee9QACgkQLh2DDte4 MCXwjg//eli3VaXMcrnZYM1lo1DckCDnjnpfSQsjPPEIEwbec/rYmYRQZraTFfKF cVuHWipeeyZySzLXBtht/wrCve5o1EmGBbQ5jA0Z4QN4Ma976ufmdCf5q+mlFKMD Cx5I/SQKU+jkka6OgM3pAXd7y2ERV4a/gXyP5kTOI2a9s3PbACfmHwjrkvXjTWXC 7zoM/xRxiOe/zu/tj7aW7UrY7hfKTK4FJb6TX5OaOoYo88jfIPCczy6olC1k7x1o BeQjcA7GUOQhINIh3JhHFKNrD940QDLOdR2MeI/0woh8+imP1HLp9stvDWTauGlz 0505xVwrH6tmcyEYXBlpTl8O7XOUjILUqGKld+SPf9U8vGLQYxKtZHpAxtINmue6 a3R9cGSFWbSbZ2ovW+ArmkqW+iLtXwxrl8UGrcGA04c2/bFohtkK+dhgPxqEeSWd 8LIVEnxEWqyJGnX/uDauKuqM0eKfJGPGPKWLWEqdh864JMyXZ/mkrXifaN+1ICWQ ROf5mfknhA+yoItNYR83ZrAYzEQnz0orLPVEfEGm3uBPJP89hsbtqoeaEG9YOkCa NiYl8SKYG7bw06JmJnq0uwDcGjQ/socVnDyvvaedPzxrhP/8Px/uov1WpR/SA3UV GqjlH5EsIzxU+BVRcFwU0mJ4PCPgm+SrLDDnh8uLmCn4Gn4xLdI= =7/OI -----END PGP SIGNATURE----- --Apple-Mail=_30D1212C-490F-4158-B18C-6D7A63455849-- From nobody Sat Dec 19 16:41:51 2020 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 ED5C03A003E; Sat, 19 Dec 2020 16:41:49 -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 sDMDw0z5lIOS; Sat, 19 Dec 2020 16:41:48 -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 DC4053A0039; Sat, 19 Dec 2020 16:41:47 -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=POX1ZH/3JDwayOb9ZmMC68KwnTIRKLlwFyOmS85hQho=; b=VkNfnpULlsJ58IFn8JjVOU/ic 6rh4ky9g+ckdQbJiAWHkNxs+i9EdkRkb4+QH3gvRSne0FLGmrEcfECc1TwhASt8R7cDYC5yic98F1 e12p9hHSM8cXeD9lpoNJRHrMOJbi7YqU8bpSeQOFV4YTLygDwNEDv6ePp0pvePWHUOwuWcyzEVgmC hWtcoHKfqp9fymrBQ3/gTi03tZ6mpOAOR1t930eXHrmNeNgT95K0eCcZ3CcQKO2ITUsjnfVB+3UgW xZnlYqzOeEMm4lZTlpUpSqoh8wkVTX2M8bqo9Cm0Kkz8WbrBE+5A7u3r+/4sDDXaNYXMN6z6+YUQf AMu/e4Vsw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:53136 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 1kqmn8-000kUL-Fs; Sat, 19 Dec 2020 19:41:47 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_420D82D4-04BA-469E-9AAB-076C7A0BC0E5" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: <1B7AE37A-1A16-47C5-95A3-FD131A1F0E20@chopps.org> Date: Sat, 19 Dec 2020 16:41:41 -0800 Cc: ipsec@ietf.org, tsv-art , draft-ietf-ipsecme-iptfs.all@ietf.org Message-Id: References: <160706317241.25013.15326204319913211090@ietfa.amsl.com> <559B100B-4BC2-4E95-AFF8-95BBAE0BDAC8@chopps.org> <724B2213-3B5E-4057-8343-4EE039034417@strayalpha.com> <1B7AE37A-1A16-47C5-95A3-FD131A1F0E20@chopps.org> To: Christian Hopps X-Mailer: Apple Mail (2.3654.20.0.2.21) 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: Sun, 20 Dec 2020 00:41:50 -0000 --Apple-Mail=_420D82D4-04BA-469E-9AAB-076C7A0BC0E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 19, 2020, at 1:17 AM, Christian Hopps = wrote: >=20 > Changes are underway. One comments inline. >=20 >> On Dec 4, 2020, at 11:42 AM, Joseph Touch > wrote: >>=20 >> Hi, Christian, >=20 > [...] >=20 >>>> There is no clear utility in having the blockoffset point past the = end of the >>>> current packet. It serves =E2=80=93 at best =E2=80=93 as only a = partially useful check on the >>>> next packet. I.e., if the two blockoffsets disagree, presumably a = packet is >>>> lost =E2=80=93 but if they agree, it cannot be concluded that a = packet is not lost. It >>>> is sufficient that it points to the end of the tunnel packet. >>>=20 >>> No harm either though, right? Having implemented this, I can tell = you that it does help detect bugs in ones code while in development. :) >>=20 >> It=E2=80=99s useful as a check, but it=E2=80=99s important to explain = what the check means. >>=20 >> There are four cases (BO =3D blockoffsets, seq =3D ESP sequence = number) >>=20 >> ESP - no gap ESP - gap >> --------------------------------------------------------------------- >> BO - aligned OK BO-FP-err >> BO - misaligned SN-FP-err Typ-err >>=20 >> Typ-err is the typical error when a packet is lost, because that = should result in both an ESP seqno gap and blockoffset misalignment. >>=20 >> SN-FP-err is when there=E2=80=99s no ESP seq no gap but the = blockoffsets are misaligned. This should only ever happen if the seqno = rolls around and you missed it, which you should have some other = mechanism to prevent (i.e., drop old packets when they=E2=80=99re half = the sequence space old - which is easy to predict because you know the = tunnel packet generation rate). >>=20 >> BO-FP-err is when there=E2=80=99s an ESP seq no gap but the = blockoffsets are aligned. This is just a false positive (thus =E2=80=9CFP=E2= =80=9D in my notation). S >>=20 >> In any of the error cases, you do not reassemble. >>=20 >> So checking blockoffset alignment only helps you know whether your = sequence number check and timeout discard is working correctly. >>=20 >> Protocol implementation correctness should be checked by test = vectors, not during normal code operation IMO. At best, it=E2=80=99s = unnecessary complexity. At worst, it gives you a false sense of wanting = to reassemble when you shouldn=E2=80=99t. >=20 > Conversely, test-vectors are harder to write w/o this and must be = external, whereas this is a simple sanity check that can be added inline = (perhaps conditionally) to code which has been shown to catch bugs. This = will help implementations be more robust. Test vectors run only during testing. By putting this test in regular = operation, you=E2=80=99re adding overhead to check that the code is = working every time it runs. It=E2=80=99s your call; I was just pointing out that this is very = inefficient. > Regarding complexity, having implemented this I can say there really = is no complexity :) If the LOC > 0, then it=E2=80=99s not =E2=80=9Cno complexity=E2=80=9D. > You set the block offset to the remaining inner packet length to be = sent (or 0 if no packet fragmentation is in progress). This value is = sitting right there in the code so you can either plug it in or use some = marker value (you suggest the length to the end of the payload). On = receive the code is identical: does it exceed the length of the payload = or not. Agreed, it=E2=80=99s simple - but it=E2=80=99s nonzero effort and code. = Again, at run-time. For a check that basically keeps saying the code is = working, rather than checking an actual packet error. Again, recommending inefficient code is up to you. Joe= --Apple-Mail=_420D82D4-04BA-469E-9AAB-076C7A0BC0E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 19, 2020, at 1:17 AM, Christian Hopps <chopps@chopps.org> = wrote:

Changes are underway. = One comments inline.

On Dec = 4, 2020, at 11:42 AM, Joseph Touch <touch@strayalpha.com> wrote:

Hi, Christian,

[...]

There = is no clear utility in having the blockoffset point past the end of = the
current packet. It serves =E2=80=93 at best =E2=80=93 = as only a partially useful check on the
next packet. I.e., = if the two blockoffsets disagree, presumably a packet is
lost =E2=80=93 but if they agree, it cannot be concluded that = a packet is not lost. It
is sufficient that it points to = the end of the tunnel packet.

No harm either though, right? = Having implemented this, I can tell you that it does help detect bugs in = ones code while in development. :)

It=E2=80=99s useful as a check, but = it=E2=80=99s important to explain what the check means.

There are four cases (BO = =3D blockoffsets, seq =3D ESP sequence number)

          =                     = ESP - no gap         ESP - gap
---------------------------------------------------------------= ------
BO - aligned         =  OK                   =       BO-FP-err
BO - misaligned =    SN-FP-err             =  Typ-err

Typ-err is the typical error when a packet is lost, because = that should result in both an ESP seqno gap and blockoffset = misalignment.

SN-FP-err is when there=E2=80=99s no ESP seq no gap but the = blockoffsets are misaligned. This should only ever happen if the seqno = rolls around and you missed it, which you should have some other = mechanism to prevent (i.e., drop old packets when they=E2=80=99re half = the sequence space old - which is easy to predict because you know the = tunnel packet generation rate).

BO-FP-err is when there=E2=80=99s an = ESP seq no gap but the blockoffsets are aligned. This is just a false = positive (thus =E2=80=9CFP=E2=80=9D in my notation). S

In any of the error = cases, you do not reassemble.

So checking blockoffset alignment only = helps you know whether your sequence number check and timeout discard is = working correctly.

Protocol implementation correctness should be checked by test = vectors, not during normal code operation IMO. At best, it=E2=80=99s = unnecessary complexity. At worst, it gives you a false sense of wanting = to reassemble when you = shouldn=E2=80=99t.
Conversely, test-vectors are harder to = write w/o this and must be external, whereas this is a simple sanity = check that can be added inline (perhaps conditionally) to code which has = been shown to catch bugs. This will help implementations be more = robust.

Test vectors run only during testing. By putting = this test in regular operation, you=E2=80=99re adding overhead to check = that the code is working every time it runs.

It=E2=80=99s your call; I was just pointing out = that this is very inefficient.

Regarding complexity, having = implemented this I can say there really is no complexity = :)

If = the LOC > 0, then it=E2=80=99s not =E2=80=9Cno = complexity=E2=80=9D.

You set the block offset to the remaining = inner packet length to be sent (or 0 if no packet fragmentation is in = progress). This value is sitting right there in the code so you can = either plug it in or use some marker value (you suggest the length to = the end of the payload). On receive the code is identical: does it = exceed the length of the payload or = not.

Agreed,= it=E2=80=99s simple - but it=E2=80=99s nonzero effort and code. Again, = at run-time. For a check that basically keeps saying the code is = working, rather than checking an actual packet error.

Again, recommending inefficient code is up to = you.

Joe
= --Apple-Mail=_420D82D4-04BA-469E-9AAB-076C7A0BC0E5-- From nobody Sat Dec 19 16:57:20 2020 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 320653A0121; Sat, 19 Dec 2020 16:57:18 -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 R5whROG1u_xT; Sat, 19 Dec 2020 16:57:15 -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 C00AE3A0115; Sat, 19 Dec 2020 16:57:15 -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=bgalsG2aZQ39bRJwN1UfMUq4If/oRFXImYBRbMOUP/I=; b=QXloN1OSRHfGPlre5Kb3eQgiB w6srm9IA55uOmyZHTv7L+KrJrecuhqQX1qrIWw2mFuVZvWFBYWoWWz5SNy/lbEgzmioepV/fycqAX JqFc44n2+Cy0uqz1THC7Jk/k8H66PZzAMoavz3Et6BC967VE7UZv0+X49nvp1+H9/ZZWqRtej36S9 wwQNeQZWCPrI9pIzNoFDfFY6RBpwwLjaNcULGuXxkO5E+ElQ2Wh+BJSZi051dqxWnkb/ru9zcfo4G s+qHvDPjjNIec1pZI9+GXCbY7gPV7Ctdv2Slswe7vcxANWF4sArK5Wic4Tt63TN+HT16dv/xeuEIw zdgx4PcPw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:53181 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 1kqn26-000yiT-Pl; Sat, 19 Dec 2020 19:57:15 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_AC713009-11FC-4289-9508-C8EE94021A99" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: <663120BF-01DA-449A-911D-EBD17EFBE729@chopps.org> Date: Sat, 19 Dec 2020 16:57:10 -0800 Cc: ipsec@ietf.org, tsv-art@ietf.org, draft-ietf-ipsecme-iptfs.all@ietf.org Message-Id: <6D0D5787-F5F2-421F-89BA-F56647D545BF@strayalpha.com> References: <160706317241.25013.15326204319913211090@ietfa.amsl.com> <559B100B-4BC2-4E95-AFF8-95BBAE0BDAC8@chopps.org> <663120BF-01DA-449A-911D-EBD17EFBE729@chopps.org> To: Christian Hopps X-Mailer: Apple Mail (2.3654.20.0.2.21) 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: Sun, 20 Dec 2020 00:57:18 -0000 --Apple-Mail=_AC713009-11FC-4289-9508-C8EE94021A99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 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). 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.. >=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). It should be noted as how that impacts the methods of this doc. >>> 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. 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 - >=20 > 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). >=20 > 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 --Apple-Mail=_AC713009-11FC-4289-9508-C8EE94021A99 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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=99= re 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

= --Apple-Mail=_AC713009-11FC-4289-9508-C8EE94021A99-- From nobody Sat Dec 19 19:47:56 2020 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 CB8663A097E; Sat, 19 Dec 2020 19:47:54 -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 0iwppsIRLKIg; Sat, 19 Dec 2020 19:47:53 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id E922D3A0978; Sat, 19 Dec 2020 19:47:52 -0800 (PST) Received: from [192.168.2.5] (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 1F0676020D; Sun, 20 Dec 2020 03:47:52 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_3F57C823-97C3-4EC7-B63F-89A425C1EF5F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 19 Dec 2020 22:47:51 -0500 In-Reply-To: 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> <724B2213-3B5E-4057-8343-4EE039034417@strayalpha.com> <1B7AE37A-1A16-47C5-95A3-FD131A1F0E20@chopps.org> X-Mailer: Apple Mail (2.3608.120.23.2.4) 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: Sun, 20 Dec 2020 03:47:55 -0000 --Apple-Mail=_3F57C823-97C3-4EC7-B63F-89A425C1EF5F Content-Type: multipart/alternative; boundary="Apple-Mail=_45005DEE-C8D1-4D04-A5D9-D80307C5DD58" --Apple-Mail=_45005DEE-C8D1-4D04-A5D9-D80307C5DD58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 19, 2020, at 7:41 PM, Joseph Touch = wrote: >=20 >=20 >=20 >> On Dec 19, 2020, at 1:17 AM, Christian Hopps > wrote: >>=20 >> Changes are underway. One comments inline. >>=20 >>> On Dec 4, 2020, at 11:42 AM, Joseph Touch > wrote: >>>=20 >>> Hi, Christian, >>=20 >> [...] >>=20 >>>>> There is no clear utility in having the blockoffset point past the = end of the >>>>> current packet. It serves =E2=80=93 at best =E2=80=93 as only a = partially useful check on the >>>>> next packet. I.e., if the two blockoffsets disagree, presumably a = packet is >>>>> lost =E2=80=93 but if they agree, it cannot be concluded that a = packet is not lost. It >>>>> is sufficient that it points to the end of the tunnel packet. >>>>=20 >>>> No harm either though, right? Having implemented this, I can tell = you that it does help detect bugs in ones code while in development. :) >>>=20 >>> It=E2=80=99s useful as a check, but it=E2=80=99s important to = explain what the check means. >>>=20 >>> There are four cases (BO =3D blockoffsets, seq =3D ESP sequence = number) >>>=20 >>> ESP - no gap ESP - gap >>> = --------------------------------------------------------------------- >>> BO - aligned OK BO-FP-err >>> BO - misaligned SN-FP-err Typ-err >>>=20 >>> Typ-err is the typical error when a packet is lost, because that = should result in both an ESP seqno gap and blockoffset misalignment. >>>=20 >>> SN-FP-err is when there=E2=80=99s no ESP seq no gap but the = blockoffsets are misaligned. This should only ever happen if the seqno = rolls around and you missed it, which you should have some other = mechanism to prevent (i.e., drop old packets when they=E2=80=99re half = the sequence space old - which is easy to predict because you know the = tunnel packet generation rate). >>>=20 >>> BO-FP-err is when there=E2=80=99s an ESP seq no gap but the = blockoffsets are aligned. This is just a false positive (thus =E2=80=9CFP=E2= =80=9D in my notation). S >>>=20 >>> In any of the error cases, you do not reassemble. >>>=20 >>> So checking blockoffset alignment only helps you know whether your = sequence number check and timeout discard is working correctly. >>>=20 >>> Protocol implementation correctness should be checked by test = vectors, not during normal code operation IMO. At best, it=E2=80=99s = unnecessary complexity. At worst, it gives you a false sense of wanting = to reassemble when you shouldn=E2=80=99t. >>=20 >> Conversely, test-vectors are harder to write w/o this and must be = external, whereas this is a simple sanity check that can be added inline = (perhaps conditionally) to code which has been shown to catch bugs. This = will help implementations be more robust. >=20 > Test vectors run only during testing. By putting this test in regular = operation, you=E2=80=99re adding overhead to check that the code is = working every time it runs. The test is already performed to determine if the fragment is complete = or not, regardless of whether you use the real value or some marker = value. > It=E2=80=99s your call; I was just pointing out that this is very = inefficient. >=20 >> Regarding complexity, having implemented this I can say there really = is no complexity :) >=20 > If the LOC > 0, then it=E2=80=99s not =E2=80=9Cno complexity=E2=80=9D. There really is no complexity added. copylen =3D min(inner_remain, outer_remain) ohdr->block_offset =3D inner_remain; /* Only Diff */ memcpy(outer_buf, inner_buf, copylen); if (inner_remain > copylen) more to go... vs. copylen =3D min(inner_remain, outer_remain) ohdr->block_offset =3D copylen; /* Only Diff */ memcpy(outer_buf, inner_buf, copylen); if (inner_remain > copylen) more to go... Except the former allows for creating more robust implementations, and = also differentiates the case where a fragment just fits or not for the = receiver. The latter ends up stripping away useful information. Both = ways point the block offset past the end of payload. I see the loss for = stripping the information here, I don't see the gain. Thanks, Chris. >=20 >> You set the block offset to the remaining inner packet length to be = sent (or 0 if no packet fragmentation is in progress). This value is = sitting right there in the code so you can either plug it in or use some = marker value (you suggest the length to the end of the payload). On = receive the code is identical: does it exceed the length of the payload = or not. >=20 > Agreed, it=E2=80=99s simple - but it=E2=80=99s nonzero effort and = code. Again, at run-time. For a check that basically keeps saying the = code is working, rather than checking an actual packet error. >=20 > Again, recommending inefficient code is up to you. >=20 > Joe --Apple-Mail=_45005DEE-C8D1-4D04-A5D9-D80307C5DD58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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



On Dec 19, 2020, at 1:17 AM, = Christian Hopps <chopps@chopps.org> wrote:

Changes are underway. One comments inline.

On Dec 4, 2020, at 11:42 AM, Joseph Touch = <touch@strayalpha.com> wrote:

Hi, Christian,

[...]

There is no clear utility in having the = blockoffset point past the end of the
current packet. It = serves =E2=80=93 at best =E2=80=93 as only a partially useful check on = the
next packet. I.e., if the two blockoffsets disagree, = presumably a packet is
lost =E2=80=93 but if they agree, = it cannot be concluded that a packet is not lost. It
is = sufficient that it points to the end of the tunnel packet.

No harm = either though, right? Having implemented this, I can tell you that it = does help detect bugs in ones code while in development. :)

It=E2=80=99s useful as a check, but it=E2=80=99s important to = explain what the check means.

There are four cases (BO =3D = blockoffsets, seq =3D ESP sequence number)

          =                     = ESP - no gap         ESP - gap
---------------------------------------------------------------= ------
BO - aligned         =  OK                   =       BO-FP-err
BO - misaligned =    SN-FP-err             =  Typ-err

Typ-err is the typical error when a packet is lost, because = that should result in both an ESP seqno gap and blockoffset = misalignment.

SN-FP-err is when there=E2=80=99s no ESP seq no gap but the = blockoffsets are misaligned. This should only ever happen if the seqno = rolls around and you missed it, which you should have some other = mechanism to prevent (i.e., drop old packets when they=E2=80=99re half = the sequence space old - which is easy to predict because you know the = tunnel packet generation rate).

BO-FP-err is when there=E2=80=99s an = ESP seq no gap but the blockoffsets are aligned. This is just a false = positive (thus =E2=80=9CFP=E2=80=9D in my notation). S

In any of the error = cases, you do not reassemble.

So checking blockoffset alignment only = helps you know whether your sequence number check and timeout discard is = working correctly.

Protocol implementation correctness should be checked by test = vectors, not during normal code operation IMO. At best, it=E2=80=99s = unnecessary complexity. At worst, it gives you a false sense of wanting = to reassemble when you = shouldn=E2=80=99t.
Conversely, test-vectors are harder to = write w/o this and must be external, whereas this is a simple sanity = check that can be added inline (perhaps conditionally) to code which has = been shown to catch bugs. This will help implementations be more = robust.

Test vectors run only during testing. = By putting this test in regular operation, you=E2=80=99re adding = overhead to check that the code is working every time it = runs.

The = test is already performed to determine if the fragment is complete or = not, regardless of whether you use the real value or some marker = value.

It=E2=80=99s your = call; I was just pointing out that this is very inefficient.

Regarding = complexity, having implemented this I can say there really is no = complexity :)

If the LOC > 0, then it=E2=80=99s = not =E2=80=9Cno complexity=E2=80=9D.
There really is no complexity = added.

copylen =3D min(inner_remain, = outer_remain)
ohdr->block_offset =3D = inner_remain; /* Only Diff = */
memcpy(outer_buf, inner_buf, copylen);
if = (inner_remain > copylen) more to go...

vs.

copylen= =3D min(inner_remain, outer_remain)
ohdr->block_offset =3D copylen; /* Only Diff */
memcpy(outer_buf, inner_buf, copylen);
if = (inner_remain > copylen) more to go...

Except the former allows for creating = more robust implementations, and also differentiates the case where a = fragment just fits or not for the receiver. The latter ends up stripping = away useful information. Both ways point the block offset past the end = of payload. I see the loss for stripping the information here, I don't = see the gain.

Thanks,
Chris.


You set = the block offset to the remaining inner packet length to be sent (or 0 = if no packet fragmentation is in progress). This value is sitting right = there in the code so you can either plug it in or use some marker value = (you suggest the length to the end of the payload). On receive the code = is identical: does it exceed the length of the payload or = not.

Agreed,= it=E2=80=99s simple - but it=E2=80=99s nonzero effort and code. Again, = at run-time. For a check that basically keeps saying the code is = working, rather than checking an actual packet error.

Again, recommending inefficient code is up to = you.

Joe

= --Apple-Mail=_45005DEE-C8D1-4D04-A5D9-D80307C5DD58-- --Apple-Mail=_3F57C823-97C3-4EC7-B63F-89A425C1EF5F 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/eyWcACgkQLh2DDte4 MCVOxg/+MwxWuJLmvxGGR3pB0txYXclCtdUT2jwpcBe3H1iPg/OsywU2V8sw1q4F VjB4g2eZ7S09W+xBaL1TaxZc+0VIr/j3tdyz+37s3bXUi0phIZuWaBxC3/8dPiSk 5EGUgrjcO3LDj8pPX/hgLLd/zLeWiMXKGmni2Ri60T0Z7Ctf7HiFhqOU5YHRWT7c B7AO85zL40LCSmpiDjD8utpvYjvUVspsmcK3l7wDlWg3W7i1SsgEhD3stfpsPFo+ cwciQGKp04shjo3GTU/Wa9bDQ5Ho/kgYmx2SE6+x/Rk24oG0LjB+zGq6spZchm6t ywQ75fIq1hvyg8lPWCpcmMKNmz9+BV+9rT9RxFxpuyFy3ImXlF2qXft0LIdkCWR8 NPK7MqKAxqeqaboK9ypq0gGNfP6lSvKIN/wDIo2Ww5izRlwQstNDeq3UWVWjhPy1 u7ZgznAsHhQ9N7S5iJL+5sslou6dwJwF77YZtap5KPsntBCRzVPWIwUqdSIdcJW6 bk4z9kEk5Hf+TQ1a2MkPCKiMs2dUT+7aEJfi5ZL6vnOFwNkIQpPCyfu34E+/14zy sOUmmJtP79F7BqM8A1PlKUJDNJp9pfRfNkF8XRGOJ8tsz1aUIUgeh/EzJ+fL8Yok 5BVhWaMXPMvyvjcI1SFU2O8ER8sr+fQB2+CFgR27I0mRb00Z2yM= =h/hX -----END PGP SIGNATURE----- --Apple-Mail=_3F57C823-97C3-4EC7-B63F-89A425C1EF5F-- From nobody Sat Dec 19 20:39:45 2020 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 9246C3A09C0; Sat, 19 Dec 2020 20:39:40 -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: <160843918055.15323.15880036103690289492@ietfa.amsl.com> Date: Sat, 19 Dec 2020 20:39:40 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-05.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, 20 Dec 2020 04:39:41 -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 Traffic Flow Security Using Aggregation and Fragmentation Author : Christian Hopps Filename : draft-ietf-ipsecme-iptfs-05.txt Pages : 28 Date : 2020-12-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-05 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-05 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 Sat Dec 19 20:44:26 2020 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 DE4DD3A09CD; Sat, 19 Dec 2020 20:44:24 -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 xHJC32-oOnCH; Sat, 19 Dec 2020 20:44:23 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id ABDAF3A09C9; Sat, 19 Dec 2020 20:44:22 -0800 (PST) Received: from [192.168.2.5] (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 DC0E56020D; Sun, 20 Dec 2020 04:44:21 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_736B9820-E371-4238-BD14-A1058B40F6C6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 19 Dec 2020 23:44:20 -0500 In-Reply-To: <6D0D5787-F5F2-421F-89BA-F56647D545BF@strayalpha.com> Cc: Christian Hopps , ipsec@ietf.org, tsv-art@ietf.org, 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> X-Mailer: Apple Mail (2.3608.120.23.2.4) 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: Sun, 20 Dec 2020 04:44:25 -0000 --Apple-Mail=_736B9820-E371-4238-BD14-A1058B40F6C6 Content-Type: multipart/alternative; boundary="Apple-Mail=_38446A74-7053-4DC8-B826-F6B1995054A7" --Apple-Mail=_38446A74-7053-4DC8-B826-F6B1995054A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = 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 = --Apple-Mail=_38446A74-7053-4DC8-B826-F6B1995054A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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
= --Apple-Mail=_38446A74-7053-4DC8-B826-F6B1995054A7-- --Apple-Mail=_736B9820-E371-4238-BD14-A1058B40F6C6 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/e1qQACgkQLh2DDte4 MCUkVA/8DtKiN9MZpHRv6+UrTmSraV9TR69BbiJJRoKLs/cF/cTnuhndNtT5mRT1 ++YoCHi5OhNLmUaTbPrqUrPJcIXYS877ZhAxnBiMadV/R8upH1m9VFVGyGTv7ana w4tRrqwARcqZpaPtOqEKM83isNQp8WChovePbdjLsXep+K0KNksKjITpTxiQUqrQ tkq68/nzSkYN7djr7JODRzqVQ2WK43oJzgyUe4dOzcXxr5DSjgmkwOANPpzLSqvS BmyXU9FZ9xackRe5YpVQxWEsznHoN5s87U+qg92BUPQkUk1mNxoMRnmaEPhn3G+L 4xJz2krFJ7cSlX2KK9Lzz3zwAWViQv4xjgXdjZmrmnqGJggpnWlXEHa875JGWIzz RarQHPEi7Bu+W5kkrqcVUpOotNfYKyITivKkflb/tnmaEKCv/Uf1mjQmjTQfzkTJ 2a252s/1v4D3/vaCc2pszWcieQzokfu67Z0HZZWV4J107eOFEfQiPyfFHxxsrUgE yr5cbTCRqmoUeAhmR+IFk0+7FPHmp7JpMw238pd7SAN5aV3lnySYOUI/X2t6xt4r TZIVVMfJl5Wn6tTqGV7EwN2k8JZoBzUtHX/ijZWyQLw+jin/TCMwiVnRm6DXMkSV Ou+eYJ+SEd5bu8wEXeLonSlspkMB2s0QgtUcALaLJQH2+DKMMPk= =PJMj -----END PGP SIGNATURE----- --Apple-Mail=_736B9820-E371-4238-BD14-A1058B40F6C6-- From nobody Mon Dec 21 09:32:17 2020 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 9D1063A1300; Mon, 21 Dec 2020 09:32:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Cc: David Waltermire , The IESG , Yoav Nir , draft-ietf-ipsecme-ipv6-ipv4-codes@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, kaduk@mit.edu, rfc-editor@rfc-editor.org, ynir.ietf@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160857192762.17962.376311186893449897@ietfa.amsl.com> Date: Mon, 21 Dec 2020 09:32:07 -0800 Archived-At: Subject: [IPsec] Protocol Action: 'IKEv2 Notification Status Types for IPv4/IPv6 Coexistence' to Proposed Standard (draft-ietf-ipsecme-ipv6-ipv4-codes-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: Mon, 21 Dec 2020 17:32:08 -0000 The IESG has approved the following document: - 'IKEv2 Notification Status Types for IPv4/IPv6 Coexistence' (draft-ietf-ipsecme-ipv6-ipv4-codes-06.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ Technical Summary draft-ietf-ipsecme-ipv6-ipv4-codes specifies new IKEv2 notification status types to better manage IPv4 and IPv6 co-existence. The new codes improve upon the generic error code INTERNAL_ADDRESS_FAILURE that is in RFC 7296. This document updates RFC 7296. Working Group Summary The document was reviewed by the usual suspects of the IPsecME working group: Paul Wouters, Valery Smyslov, MCR, Daniel Migault, Tero, and Yoav Nir. The review was thorough and resulted in some changes. but consensus was rough on a few points: * That the new notifications are always sent, regardless of whether the Initiator did or did not request a particular type of address, and regardless of whether the Responder was able to fulfill the request. * It was a little controversial whether this draft ought to update 7296, or whether it is just an extension. Document Quality The reviewers named in the WG summary section are quite experienced and the document quality is believed to be high. No implementations have been indicated yet. Personnel Ben Kaduk is the responsible AD; Yoav Nir is the document shepherd. From nobody Wed Dec 23 14:33:58 2020 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 8A2B33A0EDB; Wed, 23 Dec 2020 14:33:56 -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 0-Hv8UAKYrxu; Wed, 23 Dec 2020 14:33:54 -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 1C8F53A0ECE; Wed, 23 Dec 2020 14:33:53 -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=0UqBqlW5OGCBCSgu2POy+m3yx3J8A55G7iE2IVm6Oyo=; b=OkOkIC40SLzpju6O3L0Zie5YV 0h68L9JkWS+cboHCrDQDNU7K8cn7ZIkRFD5hi72IIPc43jlUxHGmOZgrDSSx4Lm7qZ9zheB+HUK9y xILQykLjD0Kt/MNUm7QYsFBxp9+0osTR559V6jv81Wqjt6bmc1lvCJ+u+SsUqlo7S1L8dPiXTSX7r 535AT4eP3PkFPEWHIEgjlMRCv00VzodLz2X8mcYTYELOFcBDYY+2UfWTyJmPwCqTM2xu461ZJcTbA Ak7mKUtVwTEkErvk/RzUrl7W2rek7F6DfXan8BefTpyTa+B/K3APivrIswUTes5xIsZXiZvKB0HSC vVaneps1Q==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:56735 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 1ksChY-001ude-5J; Wed, 23 Dec 2020 17:33:53 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_EE6D06EE-7877-44AF-9AF0-B951F6BECF55" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Joseph Touch In-Reply-To: Date: Wed, 23 Dec 2020 14:33:47 -0800 Cc: ipsec@ietf.org, tsv-art , draft-ietf-ipsecme-iptfs.all@ietf.org Message-Id: <2574222A-BB85-4F4B-AEC7-7E5BB7FE45CC@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> 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: Wed, 23 Dec 2020 22:33:57 -0000 --Apple-Mail=_EE6D06EE-7877-44AF-9AF0-B951F6BECF55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Looks good - thanks. Joe > 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 --Apple-Mail=_EE6D06EE-7877-44AF-9AF0-B951F6BECF55 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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

= --Apple-Mail=_EE6D06EE-7877-44AF-9AF0-B951F6BECF55--