RE: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Mon, 30 November 2020 21:53 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942263A11D4 for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 13:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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.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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 yr6wb_jeHji3 for <ipv6@ietfa.amsl.com>; Mon, 30 Nov 2020 13:53:02 -0800 (PST)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 B0C583A0ED9 for <ipv6@ietf.org>; Mon, 30 Nov 2020 13:53:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 0AULqwMR022416; Mon, 30 Nov 2020 16:53:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1606773180; bh=QxiNnBwA+4hyrdmT5j24nfgfvn+vfy5KcslV38qZ4xE=; h=From:To:Subject:Date:References:In-Reply-To:From; b=lDRAYXa5ugO2R/jGrVZWF6n912mDNVvFVJExOH/SMnMtC6sTwK+2FD8KMH9rHi1jj iNJb14la9RMYvL+OhqeStvDEhE0AM1eKiXQQAa4F7AV/4KNNboJpQKl4AzmszzNq/w 9KA3DkvG4Hckr6WIcUA/kknHlFYLhVX1z89fDvJuDrl+f2eVyXkZmJGdSqFpkLyBxc qyLuFP8+aMkQcOwWwzMuCKsvZJP3lJuozsMbM8i+C4zGYMmXsIl1ziGk6xQoBSogge tBohqDwlATDe65zuWCgNKEihYUX2QWuBeFNiso/PgB3AVcGQKaW9qGWOIbohGntLHd dRWOPNySjp9Gg==
Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 0AULqmX6022211 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 30 Nov 2020 16:52:49 -0500
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 30 Nov 2020 13:52:47 -0800
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Mon, 30 Nov 2020 13:52:47 -0800
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Thread-Topic: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Thread-Index: AdbHPO7yBmucpkuCTXSTQb2WL3XhTgAF1NBAAANemBA=
Date: Mon, 30 Nov 2020 21:52:47 +0000
Message-ID: <f787f23d0f0d4a5a814603a9cc634bc5@boeing.com>
References: <c65ee3e9ad9847aaaafaf8dea5a689f9@boeing.com> <f1574938ecbb4f5993ed17ef2e4cf49b@boeing.com>
In-Reply-To: <f1574938ecbb4f5993ed17ef2e4cf49b@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 5CA15B76D4D3D2D8389743CD3184FEE880D8DE42F75DC2AFE900B73E5E79029A2000:8
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/G-8_ESG7YdwWKW0puFfZp7l-xD8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Nov 2020 21:53:05 -0000

Anyone who would miss having SEND/CGA on OMNI interfaces needs to speak up
now; else, they will be gone from the next draft version and OMNI will perform
IPv6 ND message authentication over Internet links the same as for Teredo.

Fred

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin (US), Fred L
> Sent: Monday, November 30, 2020 12:25 PM
> To: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>om>; ipv6@ietf.org
> Subject: RE: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> 
> Philip,
> 
> For my OMNI case, I have convinced myself that I could drop this line of investigation
> (i.e., and refrain from coding bits 10-63 of the LLA) iff I could be convinced that OMNI
> interfaces will never need to use CGAs. I have considered both approaches in terms
> of securing IPv6 ND messages on OMNI interfaces, namely SEND/CGA vs. HMAC.
> 
> RFC4380 uses HMAC for its IPv6 ND message authentication, i.e., and does not use
> SEND/CGA. And, OMNI use cases for securing IPv6 ND messages are the same as
> for RFC4380. So, is that good enough for OMNI IPv6 ND messages also? Will anyone
> miss CGAs if they are not supported on OMNI interfaces?
> 
> Fred
> 
> > -----Original Message-----
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin (US), Fred L
> > Sent: Monday, November 30, 2020 9:39 AM
> > To: Philip Homburg <pch-ipv6-ietf-7@u-1.phicoh.com>om>; ipv6@ietf.org
> > Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> >
> > Philip - see below:
> >
> > > -----Original Message-----
> > > From: pch-b9D3CB0F5@u-1.phicoh.com [mailto:pch-b9D3CB0F5@u-1.phicoh.com] On Behalf Of Philip Homburg
> > > Sent: Monday, November 30, 2020 9:09 AM
> > > To: ipv6@ietf.org
> > > Cc: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > > Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
> > >
> > > > your statements
> > > > don't match with the reality of Duplicate Address Detection.  DAD
> > > > is required if there is not going to be any differentiation between
> > > > LLA generation mechanisms.
> > >
> > > DAD is required, but DAD cannot detect things that aren't there.
> >
> > DAD is a "cry in the wilderness" to see if anyone with a duplicate address
> > is out there. The vast majority of times there will be no answer, but many
> > LLA specs still say that the cry must be made. If I have an LLA type for which
> > DAD is not required, and I apply it to an interface that may be exposed to
> > other LLA types, I do not want the non-DAD LLA type to incur the burden
> > of making the cry.
> >
> > > If two hosts have different MAC addresses then their EUI-64 IIDs cannot collide.
> >
> > Yet, for RFC4291-based LLAs the specs say that DAD is required.
> >
> > > By and large the implementation of the pseudo random IIDs generators is good
> > > enough the collision don't occur.
> >
> > Yet the specs say DAD is required, unless Optimistic DAD is invoked.
> >
> > > Of course, there are plenty of lines that end up in loopback. But in that case
> > > your flags scheme would not help either.
> >
> > I don't understand the loopback comment.
> >
> > > > I want to be able to avoid DAD whenever
> > > > possible - certainly in the aviation domain this is very important.
> > > > And, having the LLA Type field would aid in capitalizing on cases
> > > > when DAD can be avoided.
> > >
> > > You are trying to burden every IPv6 system with the specific needs you have
> > > for aviation. That is a bad trade off.
> >
> > No, there is no burden implied for existing deployments. Existing interfaces
> > will see a "Type" value of 0 (i.e., unspecified) and will continue to operate
> > as they always have.
> >
> > > Other link types still have to do DAD, so adding those flags doesn't help at all.
> > >
> > > If you know that OMNI IIDs are unique, then just specify that on OMNI links only
> > > OMNI IIDs are used and disable DAD.
> >
> > OMNI IIDs are unique because the IPv6 Prefix Delegations they are derived
> > from are unique. But, if a node has not been assigned an OMNI IID in advance
> > it will have to request one using a temporary IID such as from RFC4941(bis).
> > And, it is this temporary IID that needs to be de-conflicted from OMNI IIDs.
> >
> > Fred
> >
> > > I think 6lo does something similar for EUI-64.
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------