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

["Templin, Fred L" <[e-mail]>]

Thanks Bernie. AFAICT, anyone who favors mandatory encryption for Secure
DHCPv6 must by definition also support RAAN (i.e., the draft Bernie cited).
Without RAAN, Secure DHCPv6 would be unusable for DHCPv6 PD.

Thanks - Fred

From: Bernie Volz (volz) [mailto:[e-mail]]
Sent: Monday, September 12, 2016 6:41 AM
To: Templin, Fred L <[e-mail]>
Cc: Ted Lemon <[e-mail]>; Ralph Droms <[e-mail]>; [e-mail]
Subject: RE: [dhcwg] Citing 'draft-ietf-dhc-secdhcpv6' (rfc3315bis)

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:[e-mail]]
Sent: Friday, September 09, 2016 6:01 PM
To: Bernie Volz (volz) <[e-mail]<mailto:[e-mail]>>
Cc: Ted Lemon <[e-mail]<mailto:[e-mail]>>
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