Subject: [dhcwg] DHCPv6 RAAN options

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Aug 2014 20:41:09 +0000

Hi, back long ago there was a draft titled: "DHCPv6 Relay Agent Assignment
Notification (RAAN) Option":

http://www.ietf.org/archive/id/draft-ietf-dhc-dhcpv6-agentopt-delegate-04.txt

This document has been dormant for 5yrs, but it looks like it was
already nearly ready for publication at the time. IMHO, the mechanism
it specifies would be useful for real-world networking problems that
cannot be satisfied through other approaches such as simple relay
"gleaning" of IAs during DHCPv6 client/server exchanges. I am wondering
if this document could be revived and brought back into the working
group at this time?

Thanks - Fred
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Aug 2014 17:06:52 -0400

On Aug 7, 2014, at 4:41 PM, Templin, Fred L <[email-masked]> wrote:
> I am wondering

It died for a reason.   Do you have a use case for it?

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Aug 2014 21:22:04 +0000

Hi Ted,

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Thursday, August 07, 2014 2:07 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [dhcwg] DHCPv6 RAAN options
> 

Yes, I think so. When a DHCPv6 client sends a Solicit, Request,
Renew, Rebind, etc. via a DHCPv6 relay, the relay does not know
yet whether the DHCPv6 server will honor the request. For example,
authentication might fail and the DHCPv6 server will ignore the
client's request.

So, the relay should only glean IA_NA and IA_PD information on
the reverse path from the server via the relay and to the client.
However, the server's reply message might not contain enough
information for the relay to do the gleaning (e.g., release of
IA_NA/IA_PDs). So, a RAAN option would provide the correct
information sharing between server and relay.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Aug 2014 17:30:59 -0400

> information sharing between server and relay.

The authentication+release case is certainly an interesting one that I hadn't considered before, and I don't think the working group has either.  RAAN may be a heavyweight solution, though.   So rather than simply reviving the RAAN option and adapting it to this purpose, it might be worth doing a little more analysis first.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Aug 2014 21:47:46 +0000

Hi Ted,

> Sent: Thursday, August 07, 2014 2:31 PM
> To: Templin, Fred L
> Cc: [email-masked]
> The authentication+release case is certainly an interesting one that I hadn't considered before, and I
> don't think the working group has either.

Yes, I think that is the case that most strongly calls for something
more than is in the base spec. But, I think other cases that call for
authentication would also benefit - perhaps to a lesser degree.

> RAAN may be a heavyweight solution, though.

I am quite sure you understand the server->relay engine a lot better
than I do. But, could it be turned on based on a server configuration
option rather than having it as the default behavior? 

> So rather
> than simply reviving the RAAN option and adapting it to this purpose, it might be worth doing a little
> more analysis first.

I have been looking at this for the past couple of days, and I don't
see any ways for the relay agent to securely conclude that the client's
IAs have been released without receiving downstream information from
the server. The relay agent could cache the client's Release request,
but then if the client is a rogue the relay could be exposed to a
buffer exhaustion DoS attack.

Now that I think of it, though, one possibility is to use the
RFC3315(bis) effort to change the behavior of the server's Reply
to a Release message so that the server lists the IAs that were
released and with lifetimes set to 0. But, I'm not sure that the
schedule for publishing RFC3315(bis) would be within the
timeframe I am hoping for.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Aug 2014 17:52:26 -0400

On Aug 7, 2014, at 5:47 PM, Templin, Fred L <[email-masked]> wrote:
> released and with lifetimes set to 0.

Yeah, that was the other alternative that sprung readily to mind when I thought about the problem.

> But, I'm not sure that the

Trying to get work through the WG on a time schedule is always a challenge.   But I think the point is that you should raise the issue with the working group, not presupposing a particular solution, and see what happens.   Which I think effectively we have done now by having this conversation.  :)

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Aug 2014 22:00:06 +0000

Hi Ted,

> Sent: Thursday, August 07, 2014 2:52 PM
> To: Templin, Fred L
> Cc: [email-masked]

Agreed.
 
> Trying to get work through the WG on a time schedule is always a challenge.   But I think the point is
> that you should raise the issue with the working group, not presupposing a particular solution, and
> see what happens. Which I think effectively we have done now by having this conversation.  :)

Also understood. At the moment, having the relay securely conclude
that a client's IAs have been released is the only use case that
I can see that doesn't seem to be satisfied by the base specs. I
would be happy to hear differently, however, and will keep my eyes
open for other use cases that may need attention.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Aug 2014 22:23:26 +0000

Hi Ted,

> > Yeah, that was the other alternative that sprung readily to mind when I thought about the problem.

what about an errata to RFC3315?

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Aug 2014 18:55:50 -0400

> what about an errata to RFC3315?

It's not an error, so no, I would have to reject that.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Aug 2014 14:44:40 +0000

> It's not an error, so no, I would have to reject that.

Write a little draft that (if approved) updates RFC3315?

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Aug 2014 10:53:43 -0400

> Write a little draft that (if approved) updates RFC3315?

That's the right process, if you can't get this into the 3315bis effort.   But it would have to go through the working group.   I seem to be talking a lot on this topic, but I'm only one working group participant, and not an active participant in the 3315bis effort.   Have any of the 3315bis people been following this discussion?   Do you have thoughts on the matter?

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Aug 2014 11:57:15 -0400

> That's the right process, if you can't get this into the 3315bis effort.   But it would have to go through the working group.   I seem to be talking a lot on this topic, but I'm only one working gr…

If I recall correctly, draft-ietf-dhc-dhcpv6-agentopt-delegate-04 was not published by the working group because of message transport and ordering concerns: no guarantees that...

...messages containing RAAN options will be delivered in order so that the relay agent takes actions in the correct order
...transactions containing RAAN options will be forwarded through the correct relay agent; e.g., the transaction delegating prefix P to device D might be forwarded through relay agent R1, causing R1 to take action based on that delegation, while the subsequent transaction releasing P might be forwarded through relay agent R2, which has no knowledge of the original delegation

- Ralph

PS I'm working from memory w/o bothering to research the mailing list...
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Aug 2014 16:06:51 +0000

Hi Ralph,

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Friday, August 08, 2014 8:57 AM
> To: Ted Lemon
> Cc: Templin, Fred L; [email-masked]
> > That's the right process, if you can't get this into the 3315bis effort.   But it would have to go
> through the working group.   I seem to be talking a lot on this topic, but I'm only one working group
> participant, and not an active participant in the 3315bis effort.   Have any of the 3315bis people
> been following this discussion?   Do you have thoughts on the matter?
> 
> If I recall correctly, draft-ietf-dhc-dhcpv6-agentopt-delegate-04 was not published by the working
> group because of message transport and ordering concerns: no guarantees that...
> 
> ...transactions containing RAAN options will be forwarded through the correct relay agent; e.g., the
> transaction delegating prefix P to device D might be forwarded through relay agent R1, causing R1 to
> take action based on that delegation, while the subsequent transaction releasing P might be forwarded
> through relay agent R2, which has no knowledge of the original delegation

I have a case where the Client can steer its DHCPv6 messaging through a
specific relay agent or agents by mapping All_DHCP_Relay_Agents_and_Servers
to a unicast L2 address. I think there would probably also be real-world
use cases where there is only one relay agent on the link - otherwise, I
think PD might have problems in some environments. But, perhaps others
would know better.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Aug 2014 12:16:08 -0400

On Aug 8, 2014, at 12:06 PM, Templin, Fred L <[email-masked]> wrote:
> to a unicast L2 address.

That's not DHCP, so it's out of scope for the WG.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Aug 2014 16:24:54 +0000

Hi Ted,

> Sent: Friday, August 08, 2014 9:16 AM
> To: Templin, Fred L
> Cc: Ralph Droms; [email-masked]

It is a link-layer consideration that occurs below the IPv6 layer.
So, yes it is DHCPv6 over a specific link layer.

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.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Aug 2014 12:33:36 -0400

> 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.

> of a link that is physically constrained to have only a single

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.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Aug 2014 16:48:12 +0000

Hi Ted,

> Sent: Friday, August 08, 2014 9:34 AM
> To: Templin, Fred L
> 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.
> 
> 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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Aug 2014 13:17:34 -0400

> allow for a slightly less convenient means for gleaning.

Convenient for the relay agent, modulo path asymmetries.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Aug 2014 13:29:26 -0400

> think PD might have problems in some environments. But, perhaps others

After a short conversation at lunch on this topic, I also recall (and others with better memory should certainly correct me) that the WG eventually came to the conclusion that piggybacking information for the relay agent on client-server transactions is not a good design.  A protocol transaction (DHCP or something else) explicitly between the relay agent and some control function (perhaps in the DHCP server, perhaps elsewhere) would be a more robust design.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Aug 2014 17:40:44 +0000

Hi Ted,

> Sent: Friday, August 08, 2014 10:18 AM
> To: Templin, Fred L
> Cc: [email-masked]; Ralph Droms

Right. I think I also see from the recharter announcement that the
second alternative would probably be met with less resistance in
the working group.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Aug 2014 18:33:23 +0000

Hello,

In Section 18.2.6 of 'draft-dhcwg-dhc-rfc3315bis-02.txt' the next to
last paragraph of the section currently states:

   "After all the addresses have been processed, the server generates a
   Reply message and includes a Status Code option with value Success, a
   Server Identifier option with the server's DUID, and a Client
   Identifier option with the client's DUID.  For each IA in the Release
   message for which the server has no binding information, the server
   adds an IA option using the IAID from the Release message, and
   includes a Status Code option with the value NoBinding in the IA
   option.  No other options are included in the IA option."

According to this specification, the server does not include any
information about IAs that were successfully released in the
transaction. Therefore, relays that need to "glean" client-server
transactions will have no way of knowing that the Release was
successfully executed by the server.

A proposed resolution is to add an additional specification to this
paragraph as follows:

   "After all the addresses have been processed, the server generates a
   Reply message and includes a Status Code option with value Success, a
   Server Identifier option with the server's DUID, and a Client
   Identifier option with the client's DUID.  For each IA in the Release
   message for which the server has released binding information, the
   server adds an IA option using the IAID from the Release message with
   both preferred-lifetime and valid-lifetime set to 0 in the IA
   Address/Prefix option, and includes a Status Code option with the
   value Success in the IA option. For each IA in the Release message for
   which the server has no binding information, the server adds an IA
   option using the IAID from the Release message, and includes a Status
   Code option with the value NoBinding in the IA option.  No other
   options are included in the IA option."

Comments? Questions?

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Aug 2014 15:32:45 -0400

> Comments? Questions?

WFM, although that's a pretty long paragraph.   I think this solves a real problem and is worth doing.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 8 Aug 2014 15:38:45 -0400

On Aug 8, 2014, at 3:32 PM, Ted Lemon <[email-masked]> wrote:
> I think this solves a real problem and is worth doing.

(and, rather importantly, I think it's unlikely to break anything.)

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Aug 2014 15:52:35 -0400

I think the text needs a full disclosure warning to the effect that there is no guarantee that the Release-Reply transaction will traverse the same relay agent as other transactions.

- Ralph

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Aug 2014 22:39:24 +0000

Hi Ralph,

> From: dhcwg [mailto:[email-masked]] On Behalf Of Ralph Droms
> Sent: Friday, August 08, 2014 12:53 PM
> To: [email-masked]
> Subject: Re: [dhcwg] RFC3315(bis) comment
> 
> I think the text needs a full disclosure warning to the effect that there is no guarantee that the
> Release-Reply transaction will traverse the same relay agent as other transactions.

I think I understand the point, but this would not harm any relays that
were not on the original {Solicit/Request}-Reply path; they would simply
see that the client's IAs have been released regardless of which relay
they were initially established through. I think the more dangerous case
is for relays that would glean information from the initial
{Solicit/Request}-reply path; unless the relay has some way of knowing
that any subsequent Release would come through itself and not through a
different relay it cannot safely do the gleaning. But, there is no
warning label in the spec about that.

The information I am suggesting in my proposed text would also provide
potentially useful information to the client in the form of a positive
confirmation of the release of individual IAs independent of what any
relays might do. So, other documents that suggest relay gleaning would
be the place to explain the circumstances under which gleaning can be
applied.

All of that said, do we really want to fully examine relay gleaning
in both the forward and reverse paths in the RFC3315(bis) base spec?
I hope not, but maybe that is what you were thinking?

Thanks - Fred

---

From: Ralph Droms <[email-masked]>
Date: Sat, 9 Aug 2014 08:13:07 -0400

> On Aug 8, 2014, at 6:39 PM, "Templin, Fred L" <[email-masked]> wrote:
> 
> Hi Ralph,
> 
> different relay it cannot safely do the gleaning.

More generally, the technique of transporting the RAAN option or extending the Reply message to enable gleaning - in my opinion, the two are equivalent for managing state in relay agents - was considered to be the wrong architecture for managing state in relay agents.  As you point out, there is no guarantee that subsequent transactions will be forwarded by the relevant relay agent.  The messages may not be delivered in the correct order.  Finally, there may not be a client-server transaction available when the relay agent state needs to be updated.

> But, there is no

My suggestion is to add such a warning label to this option, if it is intended to enable gleaning/snooping.

> be the place to explain the circumstances under which gleaning can be

Do you have an explicit use case for informing the client of the success of the release?

> I hope not, but maybe that is what you were thinking?

Relay gleaning is, to my mind, sort of a bad idea but it seems to be popular and the solution of choice in certain situations.  Note that I am speaking strictly from an architecture point of view; those operating DHCP services may have a different opinion.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Aug 2014 15:45:53 +0000

Hi Ralph,

OK, if I understand you correctly then maybe what would work would
be 1-2 paragraphs added to RFC3315(bis) to discuss the practice of
relay agent gleaning. So, maybe add a new Section 20.1.4 something
to the effect of:

  "20.1.4 Relay Agent Gleaning

      In operational practice, relay agents are often configured to
      examine address and prefix information contained in client-server
      transactions, e.g., for the purpose of injecting and withdrawing
      information in the routing system. This practice (sometimes known
      as "gleaning") has known operational limitations.

      In particular, relay agents SHOULD NOT perform gleaning unless there
      is operational assurance that the path from the client to server will
      will always travel through the same agent, and that no transaction
      reordering will occur. Furthermore, relay agents SHOULD NOT perform
      gleaning based solely on the client's requests to the server since
      the messages may be rejected, e.g., due to authentication failure.
      If any gleaning is to be done, it should therefore be based on the
      server's replies to the client."

You also asked about a use case for informing the client of the success
of the release. My AERO proposal is one such use case, but certainly
not the only one. In general, in any environment in which a client's
request to the server is subject to authentication, the relay agent
should only perform gleaning on the server's reply to the client.

Thanks - Fred

> Sent: Saturday, August 09, 2014 5:13 AM
> To: Templin, Fred L
> Cc: [email-masked]
> More generally, the technique of transporting the RAAN option or extending the Reply message to enable
> gleaning - in my opinion, the two are equivalent for managing state in relay agents - was considered
> to be the wrong architecture for managing state in relay agents.  As you point out, there is no
> guarantee that subsequent transactions will be forwarded by the relevant relay agent.  The messages
> may not be delivered in the correct order.  Finally, there may not be a client-server transaction
> available when the relay agent state needs to be updated.
> 
> > But, there is no
> Relay gleaning is, to my mind, sort of a bad idea but it seems to be popular and the solution of
> choice in certain situations.  Note that I am speaking strictly from an architecture point of view;
> those operating DHCP services may have a different opinion.
> 
> >
> > Thanks - Fred

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 15 Aug 2014 20:13:27 +0000

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.

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.)

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? 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.

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.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Friday, August 08, 2014 12:48 PM
To: Ted Lemon
Cc: [email-masked]; Ralph Droms
Subject: Re: [dhcwg] DHCPv6 RAAN options

Hi Ted,

> 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.
> 
> 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Aug 2014 20:45:47 +0000

Hi Bernie,

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Friday, August 15, 2014 1:13 PM
> To: Templin, Fred L; Ted Lemon
> Subject: RE: [dhcwg] DHCPv6 RAAN options
> 
> Fred:
> 

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.
> 
> (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

> 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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 21 Aug 2014 18:18:08 +0000

Of course, there could also be some communication between relays in a multiple relay situation where gleaning was being used and in that case this restriction would not apply. 

But perhaps best we ignore that. And, there's interesting issues about timing in some cases with that kind of design. I think we worked on addressing some of the timing issues in RAAN by including a sequence number scheme for server generated messages so relays could tell the order.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Monday, August 11, 2014 11:46 AM
To: Ralph Droms
Cc: [email-masked]
Subject: Re: [dhcwg] RFC3315(bis) comment

Hi Ralph,

OK, if I understand you correctly then maybe what would work would be 1-2 paragraphs added to RFC3315(bis) to discuss the practice of relay agent gleaning. So, maybe add a new Section 20.1.4 something to the effect of:

You also asked about a use case for informing the client of the success of the release. My AERO proposal is one such use case, but certainly not the only one. In general, in any environment in which a client's request to the server is subject to authentication, the relay agent should only perform gleaning on the server's reply to the client.

Thanks - Fred

> >> I think the text needs a full disclosure warning to the effect that 
> >> there is no guarantee that the Release-Reply transaction will traverse the same relay agent as other transactions.
> >
> > I think I understand the point, but this would not harm any relays 
> > that were not on the original {Solicit/Request}-Reply path; they 
> > would simply see that the client's IAs have been released regardless 
> > of which relay they were initially established through. I think the 
> > more dangerous case is for relays that would glean information from 
> > the initial {Solicit/Request}-reply path; unless the relay has some 
> > way of knowing that any subsequent Release would come through itself 
> > and not through a different relay it cannot safely do the gleaning.
> 
> More generally, the technique of transporting the RAAN option or 
> extending the Reply message to enable gleaning - in my opinion, the 
> two are equivalent for managing state in relay agents - was considered 
> to be the wrong architecture for managing state in relay agents.  As 
> you point out, there is no guarantee that subsequent transactions will 
> be forwarded by the relevant relay agent.  The messages may not be delivered in the correct order.  Finally, there may not be a client-server transaction available when the relay agent state needs to be updated.
> 
> > But, there is no
> > The information I am suggesting in my proposed text would also 
> > provide potentially useful information to the client in the form of 
> > a positive confirmation of the release of individual IAs independent 
> > of what any relays might do. So, other documents that suggest relay 
> > gleaning would be the place to explain the circumstances under which 
> > gleaning can be applied.
> 
> Relay gleaning is, to my mind, sort of a bad idea but it seems to be 
> popular and the solution of choice in certain situations.  Note that I 
> am speaking strictly from an architecture point of view; those operating DHCP services may have a different opinion.
> 
> >
> > Thanks - Fred
> >>> In Section 18.2.6 of 'draft-dhcwg-dhc-rfc3315bis-02.txt' the next 
> >>> to last paragraph of the section currently states:
> >>>
> >>>  "After all the addresses have been processed, the server 
> >>> generates a  Reply message and includes a Status Code option with 
> >>> value Success, a  Server Identifier option with the server's DUID, 
> >>> and a Client  Identifier option with the client's DUID.  For each 
> >>> IA in the Release  message for which the server has no binding 
> >>> information, the server  adds an IA option using the IAID from the 
> >>> Release message, and  includes a Status Code option with the value 
> >>> NoBinding in the IA  option.  No other options are included in the IA option."
> >>>
> >>> A proposed resolution is to add an additional specification to 
> >>> this paragraph as follows:
> >>>
> >>>  "After all the addresses have been processed, the server 
> >>> generates a  Reply message and includes a Status Code option with 
> >>> value Success, a  Server Identifier option with the server's DUID, 
> >>> and a Client  Identifier option with the client's DUID.  For each 
> >>> IA in the Release  message for which the server has released 
> >>> binding information, the  server adds an IA option using the IAID 
> >>> from the Release message with  both preferred-lifetime and 
> >>> valid-lifetime set to 0 in the IA  Address/Prefix option, and 
> >>> includes a Status Code option with the  value Success in the IA 
> >>> option. For each IA in the Release message for  which the server 
> >>> has no binding information, the server adds an IA  option using 
> >>> the IAID from the Release message, and includes a Status  Code 
> >>> option with the value NoBinding in the IA option.  No other  options are included in the IA option."
> >>>
> >>> Comments? Questions?
> >>>
> >>> Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Aug 2014 19:52:20 +0000

Thanks Bernie,

The multiple relay situation certainly opens a new can of worms.
That said, I don't know that I have much further to offer regarding
RAAN options since it is beginning to look like my needs can be met
without using relay agents at all.

Thanks - Fred

> Sent: Thursday, August 21, 2014 11:18 AM
> To: Templin, Fred L; Ralph Droms
> Cc: [email-masked]
> Subject: RE: [dhcwg] RFC3315(bis) comment
> 
> Of course, there could also be some communication between relays in a multiple relay situation where
> gleaning was being used and in that case this restriction would not apply.
> 
> But perhaps best we ignore that. And, there's interesting issues about timing in some cases with that
> kind of design. I think we worked on addressing some of the timing issues in RAAN by including a
> sequence number scheme for server generated messages so relays could tell the order.
> 
> - Bernie
> 
> OK, if I understand you correctly then maybe what would work would be 1-2 paragraphs added to
> RFC3315(bis) to discuss the practice of relay agent gleaning. So, maybe add a new Section 20.1.4
> something to the effect of:
> 
> You also asked about a use case for informing the client of the success of the release. My AERO
> proposal is one such use case, but certainly not the only one. In general, in any environment in which
> a client's request to the server is subject to authentication, the relay agent should only perform
> gleaning on the server's reply to the client.
> 
> Thanks - Fred
> > be forwarded by the relevant relay agent.  The messages may not be delivered in the correct order.
> Finally, there may not be a client-server transaction available when the relay agent state needs to be
> updated.
> >
> > > But, there is no