IETF Logo Mail Archive

Re: [dhcwg] whether/how to support Confirm with sedhcpv6

"Bernie Volz (volz)" <volz@cisco.com> Tue, 28 March 2017 15:44 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AAB12945C for <dhcwg@ietfa.amsl.com>; Tue, 28 Mar 2017 08:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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
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 c1fk77YP42_r for <dhcwg@ietfa.amsl.com>; Tue, 28 Mar 2017 08:44:37 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25CF5127010 for <dhcwg@ietf.org>; Tue, 28 Mar 2017 08:44:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2986; q=dns/txt; s=iport; t=1490715877; x=1491925477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=V9PC4J2Kbwk5G5ZvS7MoeZMC2eVCvINtA01fFHe7Z4E=; b=KXw1PANu4fKbUwY2BiRZMRvRDIjAeE7kkH5m1e6ydCkv0xb5e3OfZKXP jOwbz+cWk9xnphjdjCX+v0wkt2q3kxkKWfd2hcn9Hyt5K3LvS2o5rN2Vo lF+5+nEhQP9rg9fzv+UCFbvNPrR3YScHdllEFCWu8PVa/VoAEcxmJXc4j w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C0AQDgg9pY/5pdJa1dGQEBAQEBAQEBAQEBBwEBAQEBg1SBbAeDW4oPpx2CDoYiAhqDBz8YAQIBAQEBAQEBayiFFgYjEUUQAgEIDgwCJgICAjAVEAIEAQ0FigesfoImik8BAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQuHSIJqhD4WgwYugjEBBIkjkz0Bkk6RM4FskX0BHziBBFkVUgGERh2BY3WHMAeBKYENAQEB
X-IronPort-AV: E=Sophos;i="5.36,237,1486425600"; d="scan'208";a="7862868"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 15:44:36 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v2SFiax1010367 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2017 15:44:36 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Mar 2017 10:44:35 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Tue, 28 Mar 2017 10:44:35 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Ted Lemon <mellon@fugue.com>, 神明達哉 <jinmei@wide.ad.jp>
CC: "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] whether/how to support Confirm with sedhcpv6
Thread-Index: AQHSpj3Fn2WlavvNXUqtanr4SSkvDaGnMo+VgALI7QCAALvGAP//wWsA
Date: Tue, 28 Mar 2017 15:44:35 +0000
Message-ID: <80C62C74-BB9D-4F43-9C2F-A5EC02A63918@cisco.com>
References: <CAJE_bqetH-MvY1RRGXvyy3t8WDa9AUDcvXM6jW0aGP=uJC60hg@mail.gmail.com> <3566F64B-D709-4DF3-9A5F-7648DA8FC45E@cisco.com> <CAJE_bqf1QijOkv4L=YumwH+gxSh5QRxkukAN-b+cgE7zabTmOA@mail.gmail.com> <4512A1F7-A480-4250-BE57-FCE822EAC890@fugue.com>
In-Reply-To: <4512A1F7-A480-4250-BE57-FCE822EAC890@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.242.245]
Content-Type: text/plain; charset="utf-8"
Content-ID: <03B0E94D60A8384BBA8BF89A6B2B5211@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/cfFF5y5KKuxaqk0Rwkr6uXwMoOA>
Subject: Re: [dhcwg] whether/how to support Confirm with sedhcpv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 15:44:39 -0000

Interesting idea …

But, wouldn’t just sending the initial Information-Request per seDHCPv6 which “solicits” server’s certificates with the Encrypted-Message Option which contained the Confirm (and an Encryption Key Tag Option) be best? Not exactly sure what the reference to “wrap relay messages”.

We might also consider whether this could be useful for the Rebind (prefix delegation version of Confirm).

And, then there’s the question of what the server’s response is … for the server that can decrypt, it would send a Reply for the Confirm(/Rebind) and not answer the Information-Request?

BTW: RFC 7844 (DHCP Anonymity Profiles) section 4.2 says not to send Confirms. Perhaps for seDHCPv6, starting with the seDHCPv6 Information-Request is thus OK and if client determines same server exists (based on certificate) it could then issue Confirm (or just Renew/Rebind). RFC7844 4.2 also suggests that if other information about the link is available (such as SSID), the Confirm might be sent directly.

The main question is how much special mechanism to add? Be nice to not make it too complex.

- Bernie

On 3/28/17, 11:28 AM, "Ted Lemon" <mellon@fugue.com> wrote:

    Probably the most expedient way to handle this would be to create a confirm, sign and encrypt it, and then wrap it the same way we wrap relay messages, including it in an information-request as in the regular IR/Solicit/Confirm process for secure DHCP.
    
    The server on the local wire either supports the wrapping and can decrypt, supports it but cannot decrypt, or doesn't support it and hence ignores it.   This allows the client to send a single packet that will always elicit a response, either an answer to the question asked in the Information request, or else a confirmation that it's okay to continue using the address.
    
    The hard question is, what do you do if you get an answer to the information request, rather than to the Confirm?   But I think that's straightforward: you wait a (short) while to see if you get an answer to the confirm; if you do, you take that; otherwise you take the answer from the Information-Request.

v2.23.0 | Report a Bug | By Email