Re: [dhcwg] DHCPv6 RAAN options

Hi Bernie,

> -----Original Message-----
> From: Bernie Volz (volz) [mailto:volz@cisco.com]
> Sent: Friday, August 15, 2014 1:13 PM
> To: Templin, Fred L; Ted Lemon
> Cc: dhcwg@ietf.org; Ralph Droms
> Subject: RE: [dhcwg] DHCPv6 RAAN options
> 
> Fred:
> 
> How about a 3rd option ...
> 
> Perhaps you should look at the Active Leasequery work as that might be a better option for the Relay
> tracking what the server has?
> 
> See http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-active-leasequery.

Thanks - will have a look.

> One issue for RAAN and even Relay gleaming the Reply is that the Reply message might be lost and never
> get to the Relay. The client may not retry (or all Releases suffer from this issue) - it is suggested
> that the client retry, not a requirement.
> 
>    Because Release messages may be lost, the client should retransmit
>    the Release if no Reply is received.  However, there are scenarios
>    where the client may not wish to wait for the normal retransmission
>    timeout before giving up (e.g., on power down).
> 
> (I guess we could argue here that 3315 should say "Because Release or Reply messages may be lost ...".
> Perhaps another 3315bis item if we haven't caught this already? No, at least not as of the bis 02
> document.)

I think the client not retrying the Release is probably something else
to be concerned about, yes.

> On the other hand, I'm also not sure how serious this issue is. The Relay is probably keeping some
> state about what addresses/prefixes are in use by what clients. So, when a Release is received, it can
> at least validate that the client has this lease and remove it. If a rouge client did the Release,
> what happens?

A rogue client is exactly the case of concern. I have a link on which
rogue nodes can easily masquerade and attempt to cancel the leases of
legitimate clients. For that, I am depending on DHCP authentication.
But, if the relay agent can't inspect IAs in the Reply coming back
from the server it has no way of knowing *what* (if anything) has
been released.

> I guess that depends on what the Relay is doing with this information. If the Relay is
> also acting as a router or network traffic cop, such as in DOCSIS CMTS, when a unknown addresses is
> seen, the Relay does a Leasequery to the server to ask it who is using this address. If it gets back
> information, it updates it state tables and all is well. (Note that PD leases can be recovered - as
> the Leasequery will return the PD lease containing the address). The only bad thing when the Relay
> removes the lease early is that if it was injecting the PD into the routing table, that would
> obviously stop and potentially be a problem.

Relay acting as a router, e.g., for PD is the case I am considering.

> Note that Bulk LQ might also be needed by the Relay to recover state if the relay loses stable
> storage? Hence, using Active LQ may not be such a stretch to avoid these security holes.

I'll look at active LQ. Per my earlier messages today, however, I am
also looking at ways I can get relay agents out of the picture and
just have direct client<->server transactions so that we don't have
to go through the gleaning headaches. I will post something on this
soon.

Thanks - Fred
fred.l.templin@boeing.com 

> - Bernie
> 
> -----Original Message-----
> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Templin, Fred L
> Sent: Friday, August 08, 2014 12:48 PM
> To: Ted Lemon
> Cc: dhcwg@ietf.org; Ralph Droms
> Subject: Re: [dhcwg] DHCPv6 RAAN options
> 
> Hi Ted,
> 
> > -----Original Message-----
> > From: Ted Lemon [mailto:ted.lemon@nominum.com]
> > Sent: Friday, August 08, 2014 9:34 AM
> > To: Templin, Fred L
> > Cc: Ralph Droms; dhcwg@ietf.org
> > Subject: Re: [dhcwg] DHCPv6 RAAN options
> >
> > On Aug 8, 2014, at 12:24 PM, Templin, Fred L <Fred.L.Templin@boeing.com> wrote:
> > > It is a link-layer consideration that occurs below the IPv6 layer.
> > > So, yes it is DHCPv6 over a specific link layer.
> >
> > Right, I don't think this makes sense as an Internet standard unless
> > there's some broad applicability, in which case that would have to be documented as a DHCP extension
> first.
> >
> > > If that is still troubling, then please also consider the case of a
> > > link that is physically constrained to have only a single
> > > DHCPv6 relay.
> >
> > A special extension to DHCP just to account for this use case seems like the wrong approach when you
> > consider the general applicability of the DHCP protocol.   ISTM that either solution we've talked
> > about would work for you as a private hack, but the question is which
> > one (if any) makes sense as a standard extension to DHCP.
> 
> Just so we can be clear on the alternatives, the first one we talked about was to ask the server to
> include in its Reply message any IAs that were released as a result of the client's Release message
> and with lifetimes set to 0. The second alternative was to resurrect RAAN options somehow.
> 
> If I am understanding this correctly, then the RAAN option provides a convenient way of relay agent
> gleaning. But, option 1 would still allow for a slightly less convenient means for gleaning.
> 
> Thanks - Fred
> fred.l.templin@boeing.com
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg