Re: [v6ops] [EXTERNAL] Re: Improving ND security

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Mon, 03 August 2020 16:45 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE933A1006; Mon, 3 Aug 2020 09:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 19THZ8gZK1Cu; Mon, 3 Aug 2020 09:45:48 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 608643A0F8C; Mon, 3 Aug 2020 09:45:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 073GjkOQ022524; Mon, 3 Aug 2020 12:45:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1596473146; bh=H75stNS2flEXqH7rCOFpKWnOpGBlTzrEhFGQg3CF+xw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ic+6u17waVXqfwm+t2Extvu3mvMSEFJEyZaXtfcTbLu5fglWC0PX91VNaBvH72mXd B6NTtivVR74o9zdB8tcQdE64Skt3QViw/7P+WszPNbK1wERKVAHw9khcR7GDtBPG4s /KKF+/MvoO0xR1kONwL+cArm9v+nNgrcLyAAaREHjNUIB5dIJisKYMhz1r+ws8jc+L iQiwh76nCTyxCCUztbvoojmJ1johVd/QMlJgdQXt9TozCxhez9+lSLH6f85dnb548t 7zWGreaXivd9/CB0/C1v8pPMZuMGg4HPHNmNUSmUIidZbqkqtunb3++2gsP78xkDuo X0UxYdHZQpnpQ==
Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 073GjZ9I021418 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 3 Aug 2020 12:45:35 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1979.3; Mon, 3 Aug 2020 09:45:33 -0700
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.1979.003; Mon, 3 Aug 2020 09:45:33 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Fernando Gont <fernando@gont.com.ar>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>
CC: v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
Thread-Topic: [v6ops] [EXTERNAL] Re: Improving ND security
Thread-Index: AdZnYGykJNK1kk2zSneWe05yLDtm6gAO/XoAAA6T6+D//9BAgIAAcUNg//yt9vCABzh8AIAAbPyQ
Date: Mon, 3 Aug 2020 16:45:33 +0000
Message-ID: <6b0d6c0a790b46c893b0ff3051599fb4@boeing.com>
References: <d5c245f216c3409f826f8132e532a882@boeing.com> <860E06E2-2650-4AAE-AD33-D4D12B0290DC@fugue.com> <b66ce3d9c75d4a39b5336dcdf9929411@boeing.com> <0DDEBA6C-3933-40FC-BB9C-33FA59DC9D76@cisco.com> <4907a159683346789bef5c495f03f95d@boeing.com> <b5043a5446914cb5b12ed76401359c7e@boeing.com> <3978163f-8815-1bd4-0fda-d84df9cbe684@gont.com.ar>
In-Reply-To: <3978163f-8815-1bd4-0fda-d84df9cbe684@gont.com.ar>
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: 81A8C2ED568CCE03CA0CA5DD9A25E17051BFBA2A11F0B581BF4D5E2F010C61FD2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/tP5MpN4_7ErlSnsiOXfcR3GpnNA>
Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2020 16:45:53 -0000

Hi Fernando,

It has come to my attention that my message response formatting has become
unwieldy, so I am leaving big spaces intentionally so folks can see where my
responses fall - see below:

Fred

> -----Original Message-----
> From: Fernando Gont [mailto:fernando@gont.com.ar]
> Sent: Monday, August 03, 2020 9:06 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>om>; Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: v6ops list <v6ops@ietf.org>rg>; 6man <ipv6@ietf.org>
> Subject: Re: [v6ops] [EXTERNAL] Re: Improving ND security
> 
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.
> On 3/8/20 11:22, Templin (US), Fred L wrote:
> > Here’s another think about SEND. RFC3971 SEND says that it works in
> > conjunction with Cryptographically Generated addresses (CGA) per RFC3972. But, CGAs are
> > cumbersome to work with as the source and destination addresses of IPv6 packets,
> > and SEND hints that it can be used without CGA but does not tell how to do so.
> 
> Of the top of my head, CGAs are a core part of send.





That is fine; we can accommodate CGAs in OMNI, cumbersome as they are.
I have this on my TODO list for after the adoption call.





> > But then, RFC4380 offers a “poor-man’s” alternative to SEND/CGA. It
> > places a message authentication code in the encapsulation headers of IPv6 ND messages so
> > that the messages can pass a rudimentary authentication check.
> 
> You mean the Teredo spec? If so, I don't think it includes any sort of
> poor-man's SEND-CGA.



It provides for message authentication, and it is widely-deployed which suggests
to me that the vendors who support it believe it is secure. So, if it is secure enough
for RFC4380, then shouldn't it also be secure enough for OMNI?
 



> > So someone with
> > security experience please help me out here – is RFC4380 authentication an acceptably
> > secure  replacement for SEND/CGA that might be easier to work with and less
> > cumbersome?
> 
> Nope. Tee point of CGAs is that they allow you to prove address
> ownership. There's nothing in RFC4380 that provides the same or similar
> functionality.




Why do we have to prove address ownership and use a whacky address format like
CGA? There is nothing in the OMNI spec that needs or wants CGAs in any fashion
unless they are absolutely required for security. Isn't it enough to prove message
authentication using the mechanisms of RFC4380 without having to accommodate
the excess baggage of CGAs??




> Thanks,
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@si6networks.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
>