[dhcwg] Minor issue in draft-ietf-dhc-dhcpv6-privacy-02

"Bernie Volz (volz)" <volz@cisco.com> Tue, 12 January 2016 13:15 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20CF1AD1EE; Tue, 12 Jan 2016 05:15:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 mb0K93F1k0EY; Tue, 12 Jan 2016 05:15:23 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF95C1AD1DB; Tue, 12 Jan 2016 05:15:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14779; q=dns/txt; s=iport; t=1452604522; x=1453814122; h=from:to:cc:subject:date:message-id:mime-version; bh=Mg0NhIV0vs14MHq/AOdlXivMLLctWqvFLEJa2lBPTQc=; b=TrvP37cQHKqs02a0Fdgesjpm1HvQTg/yCWrVCOUXbrcGETA9WyN0vg8g 6uFYrX0bNOhXNCEhvzNbMyVbEynImco5FMrG9gy6yeB+ZP8nAlBtCAG3o 60b9p8RerDs6C3ePwZ+7eZ9df3TE+IL5A1zYxT6YdTn/kp16cABuW54mX U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AJAgA7+5RW/5BdJa1UCoJuTFJziFOzJwENgWaGD4EnOBQBAQEBAQEBfwuENwQtTBIBgQAmAQQODYgmv2ABAQEBAQEBAQIBAQEBAQEBAQEakAEShH8Fh2CHE4QdhAMBgQ6MQ48DjlIBIAEBQoIRHIFdhVgkH4EIAQEB
X-IronPort-AV: E=Sophos;i="5.20,557,1444694400"; d="scan'208,217";a="226674285"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2016 13:15:21 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u0CDFLXL010132 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Jan 2016 13:15:21 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 12 Jan 2016 07:15:21 -0600
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.1104.009; Tue, 12 Jan 2016 07:15:20 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "draft-ietf-dhc-dhcpv6-privacy@ietf.org" <draft-ietf-dhc-dhcpv6-privacy@ietf.org>
Thread-Topic: Minor issue in draft-ietf-dhc-dhcpv6-privacy-02
Thread-Index: AdFNOwRKD7rEdtcxTuiAHkRh2E9YBg==
Date: Tue, 12 Jan 2016 13:15:20 +0000
Message-ID: <a68466a6f26945b593756a60ac149c5a@XCH-ALN-003.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.240.42]
Content-Type: multipart/alternative; boundary="_000_a68466a6f26945b593756a60ac149c5aXCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/AYYFE3FMt3WO6mVbcDGJq06AmXg>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: [dhcwg] Minor issue in draft-ietf-dhc-dhcpv6-privacy-02
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Jan 2016 13:15:25 -0000

Hi:

In my review for the shepherd write-up, I noticed the following in 4.1 Temporary addresses:

   However, in section 18.1.3 it explicitly mentions that temporary
   addresses can be renewed.  Client implementations may mistakenly
   renew temporary addresses if they are not careful (i.e., by including
   the IA_TA with the same IAID in Renew or Rebind requests, rather than
   a new IAID - see [RFC3315] Section 22.5), thus forfeiting short

Per RFC 3315 section 22.5:

   An IA_TA option does not include values for T1 and T2.  A client MAY
   request that the lifetimes on temporary addresses be extended by
   including the addresses in a IA_TA option sent in a Renew or Rebind
   message to a server.  For example, a client would request an
   extension on the lifetime of a temporary address to allow an
   application to continue to use an established TCP connection.
...
   A server MUST return the same set of temporary address for the same
   IA_TA (as identified by the IAID) as long as those addresses are
   still valid.  After the lifetimes of the addresses in an IA_TA have
   expired, the IAID may be reused to identify a new IA_TA with new
   temporary addresses.

This text says to EXTEND lifetimes, a client MUST include the addresses (IAADDR options). Just sending an IA_TA itself causes the server to return the existing address(es) if still valid (or new ones if not), but does NOT result in extending the lifetimes. (I agree that this subtle distinction could be lost on many [server] implementations.)

The text in 18.1.3 does indicate that to Renew, one includes the IAADDR option(s). So, it may be that the text in the draft is technically OK.

I think thought that the draft text:

                              Client implementations may mistakenly
   renew temporary addresses if they are not careful (i.e., by including
   the IA_TA with the same IAID in Renew or Rebind requests, rather than
   a new IAID - see [RFC3315] Section 22.5),

Is what is technically wrong as it isn't just including the IA_TA with the same IAID, but also by including the addresses. My suggestion is: Drop "i.e., by including the IA_TA with the same IAID in Renew or Rebind requests, rather than a new IAID -". This way you just refer people to Section 22.5 for how to do this.

Not sure this is worth a respin. It may be better for me to point out this issue and send the document to the AD for now as the AD review may turn up a few other issues? We can respin before sending off to IESG itself?


-          Bernie