IETF Logo Mail Archive

Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

"Bernie Volz (volz)" <volz@cisco.com> Mon, 12 September 2016 13:41 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 6B6A012B2A5 for <dhcwg@ietfa.amsl.com>; Mon, 12 Sep 2016 06:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.029
X-Spam-Level:
X-Spam-Status: No, score=-16.029 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 4k-0zoNSdyE9 for <dhcwg@ietfa.amsl.com>; Mon, 12 Sep 2016 06:41:12 -0700 (PDT)
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 689AD12B01B for <dhcwg@ietf.org>; Mon, 12 Sep 2016 06:41:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27105; q=dns/txt; s=iport; t=1473687672; x=1474897272; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b05e0T8uKYV7ZXuCEtQk3P/SbZf6MCI5SLcxbjM9lJ4=; b=doV6h68lhyVsG0LQLswV+xPybaRBrOSSzw4R+Z420gWXPS35AuYeLg8q L+KcchPtd2mHbleGsQH6DDtwd+l8HqSHeYAOgF4xjV9p3ihYaIIeyWYSI CQWX94B5Uk6z7kHvErPpEnMK2gcxHkoz5ZuMt9CSZuZodWlx+1HSK1uz/ s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CMAQBWr9ZX/4MNJK1dGQEBAQEBAQEBAQEBBwEBAQEBgwYzAQEBAQEeV3wHjSyrGoIDJIV5AoE3OBQBAgEBAQEBAQFeJ4RhAQEBBCcGTBACAQgRBAEBIQcHMhQJCAIEDgUIF4grDsAoAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWLAIQrTIUmBZN+FYVQAYYkiSCBdYgWfoRghE6IB4N6AR42hFtwAYV0fwEBAQ
X-IronPort-AV: E=Sophos;i="5.30,322,1470700800"; d="scan'208,217";a="322594722"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Sep 2016 13:41:10 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u8CDfAMT012122 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Sep 2016 13:41:10 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.1210.3; Mon, 12 Sep 2016 08:41:10 -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; Mon, 12 Sep 2016 08:41:10 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Thread-Topic: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)
Thread-Index: AdHz4kyO7hzDfzYnSfqWBjHhBsGHFqBGDGeAgAA+lwCAAAn1AIAEKdgAgAH3pgCAAcHfgIABdYgAgAADMICAAPbYAIAGuH0AgAAcCACAAGAdAIAAvucAgAAFvoCAABCsgIAAAW4AgAANBwCgRB0kAL94U6OAgAB0uWD//7EwAIABOJWAgABgDKD//7oDgIAAY22g//+5O4AADpoWMAAOP66AAChHgJAATbctAACDhXWA//F01XD/3sVhYA==
Date: Mon, 12 Sep 2016 13:41:10 +0000
Message-ID: <06156b7382fa424fa69967d734cb7590@XCH-ALN-003.cisco.com>
References: <92dcf2e0cf08452caa5861f7258ea6c5@XCH15-05-05.nw.nos.boeing.com> <201608121919.u7CJJqcS056876@givry.fdupont.fr> <c5303eef3c124228825f32a40f229107@XCH-ALN-003.cisco.com> <ccaff4d4cb5c4eefb05eee0660c2611c@XCH15-05-05.nw.nos.boeing.com> <f46aa91e4cfb41b29dd2d8186f5959f8@XCH-ALN-003.cisco.com> <ba1c8ff573d7466b8c437373e05f1023@XCH15-05-05.nw.nos.boeing.com> <b65e1dd66b634240b3ca164b2c04c20a@XCH15-05-05.nw.nos.boeing.com> <CAJE_bqfb5sxOpkTEXkwZXckKBWof7U1-W6EFzCHk7ijnMjpMMA@mail.gmail.com> <5ec83aaf4e76497aa4b4d465483bdcf5@XCH15-05-05.nw.nos.boeing.com> <CAJE_bqeKqEgLVC2ZZyUCjsrPP5_suRJ8en2NC+g13Q5PyQL1iw@mail.gmail.com> <30c9413c4662476096ef087ac88f6314@XCH-ALN-003.cisco.com> <dc9d2c300d574732a12f7f366f6223c0@XCH15-05-11.nw.nos.boeing.com> <3A5F0B79-8C76-4E82-97E9-FA63657DE6C3@cisco.com> <CAJ3w4NdjgVxvnvuaWjGM=qtOe0qUq4N96fVXsbNrf=YkhiABbQ@mail.gmail.com> <2f45b99b50f84b1280e92ad824e39e26@XCH15-05-05.nw.nos.boeing.com> <9E9A9543-ECB0-4D99-A00F-1AAD813B6522@fugue.com> <091180442e44490ba451874d1543f814@XCH15-05-05.nw.nos.boeing.com> <CAPt1N1=pD7TBrU_NnuyGz61+CiUVp0JiyLLfMUKTz_dgnO59QQ@mail.gmail.com> <AF387F3E-1B64-4E5D-BAF7-EB5BF3ED1EB4@cisco.com> <55dcbc0cd1484fffa264b18b2fc3322c@XCH15-05-05.nw.nos.boeing.com> <122453F6-3987-46D4-89EB-84AF99402BC3@cisco.com> <dd827ec92b874ad8a188b17f44392c54@XCH15-05-05.nw.nos.boeing.com> <438d610f19da4f7aa39fb70a7dc11513@XCH15-05-05.nw.nos.boeing.com> <2279C5E3-0D51-4631-AFC9-DAF05339D21D@cisco.com> <d6f8ed9bdfc8461aa463e6542269ccda@XCH15-05-05.nw.nos.boeing.com> <CAPt1N1nTHJm44KR1SBg=ohj8HfKO+yLna+b+95FPocTjcuuwbQ@mail.gmail.com> <f3f1af6232194fb88703237bc55d8be3@XCH15-05-05.nw.nos.boeing.com> <9EE72F8D-6735-41BC-9F8F-579CA6537397@fugue.com> <4e4a009f8b6c42a9b359b6d704e12100@XCH15-05-05.nw.nos.boeing.com> <17CB2C4C-807A-419C-98DB-333F95C2AFAD@fugue.com> ,<b2a8c8bbbfea4d3b91cbaa7592a8ca5c@XCH15-05-05.nw.nos.boeing.com> <09CF4B5B-F59C-4FAF-8217-CC96CCBEED6B@cisco.com> <47063c06167b4d2194286326c1cb8d8e@XCH15-05-05.nw.nos.boeing.com>
In-Reply-To: <47063c06167b4d2194286326c1cb8d8e@XCH15-05-05.nw.nos.boeing.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.98.1.195]
Content-Type: multipart/alternative; boundary="_000_06156b7382fa424fa69967d734cb7590XCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/a7OhBFkSxh2TaFU0VvCLVlBTtUI>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, Ted Lemon <mellon@fugue.com>, Ralph Droms <rdroms.ietf@gmail.com>
Subject: Re: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 12 Sep 2016 13:41:16 -0000

Adding Ralph as he might remember some more of the details. And, adding DHCWG as perhaps there is someone with better memory (or historical search capabilities) than me, and others may have an opinion on the https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-agentopt-delegate-04 work.

This is perhaps something to add to the Seoul agenda for discussion and finding volunteers to work on this?

I hadn't done it, but recovering the issue(s) that caused the earlier work to be abandoned might be a good first step? I think Thomas Narten raised some issues that might have derailed it, but perhaps it was someone / something else. I recall the potential timing issue was supposed to be addressed by making use of "DHCPv6 Server Reply Sequence Number Option", draft-ietf-dhc-dhcpv6-srsn-option-02, and that got added in the -01 but for some reason was dropped in the -04. Sadly all the 04 change log says is "Changes in rev -04: all references to the "Server Reply Sequence Number" option were removed from the draft." - not why it was removed. But perhaps this is the "complicated protocol was suggested..." from IETF-75 minutes:

https://www.ietf.org/proceedings/75/minutes/dhc.txt contains:

DHCPv6 Relay Agent Assignment Notification Option
                                           Chairs                10 minutes
        <draft-ietf-dhc-dhcpv6-agentopt-delegate-04>

Ted Lemon: The draft tries to solve the way to setup the routing
    information in dhcp replay agents.  Currently it is done by snooping
    on the relay agent traffic. This option should enable to dhcp
    system to send the information for routing information to eliminate
    the guesswork. Allows the relay agent to add a route in its routing
    table based on DHCP information.  A potential timing problem could
    affect customer routing. Complicated protocol was suggested to
    prevent this failure mode, this protocol was not received well,
    decision to go forward with the original proposal and document the
    potential failure mode which would be an operational problem. The
    option is solving the original requirement and needs to advance
    soon.

WG Chairs encourage people to read the draft and supply feedback.

Mark Andrews volunteered to review and to provide feedback.

Ralph Droms will refresh/resubmit the draft.

The draft was never refreshed or resubmitted by Ralph. While I only looked at the next 3 meeting minutes, I didn't find any reference to this document/work in those later minutes.

I think perhaps:

1.       The timing window for CableLabs and DOCSIS 3.0 for IPv6 support ran out and CableLabs was going to use snooping on the CMTS and therefore a major motivation for this draft was removed.

2.       The potential failure mode is no different from what exists today with snooping. As it doesn't appear to have caused any operational issues, perhaps we can argue that while it is a potential issue it would be rare and infrequent and alternatives (i.e., snooping) also suffer from this issue.

3.       While an alternative might be to use Active Leasequery by a relay to monitor a server's activity, that has latency and additional overhead issues that snooping or RAAN would eliminate (as the information is piggybacked with the actual client message).

Ralph: If you have the XML version of this draft source, it might be useful to provide it so that if it is resurrected, we don't have to start over (I suspect though it would require some tweaking to bring it up to current XML2RFC version).

I have no issues with discussing as to whether to dust off this work and try again. Whether we do this now or wait a bit longer to see how the sedhcpv6 work shakes out (it seems to have lost a lot of momentum lately) is always open to debate and may depend more on what issues the RAAN work needs to resolve (if any) - hence making sure we understand all of the key issues is important. I suspect though that until sedhcpv6 is actually being implemented, many relay agents (CMTS, ...) won't bother to be updated to make use of RAAN since the snooping alternative is already implemented and has been working (and they can block the encrypted-messages to prevent its use until the relays and servers are ready to support sedhcpv6).


-          Bernie

From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
Sent: Friday, September 09, 2016 6:01 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: Ted Lemon <mellon@fugue.com>
Subject: RE: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

Hi Bernie and Ted,

I think I have a way forward for AERO that would avoid needing to fight the Secure
DHCPv6 working group consensus, but it depends on the ability to resurrect RAAN.
And, I would not need to add anything new to  RAAN - just use it as it appears in
'draft-ietf-dhc-dhcpv6-agentopt-delegate-04'.

Given that Secure DHCPv6 will make DHCPv6 client<->server messages exchanges
opaque to relays, there would seem to be a requirement for RAAN in general even
not considering AERO. What would we need to do to bring RAAN back?

Thanks - Fred

v2.23.0 | Report a Bug | By Email