Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10

From: Jouni Korhonen <[email-masked]>
Date: Mon, 8 Apr 2013 10:31:49 +0300

Seems that I forgot to CC mailing lists.

- Jouni

Begin forwarded message:

> From: jouni korhonen <[email-masked]>
> Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10
> Date: April 5, 2013 7:37:47 PM GMT+03:00
> To: Tomek Mrugalski <[email-masked]>
> 
> 
> 5.4.2013 17.16 "Tomek Mrugalski" <[email-masked]> kirjoitti:
> >
> > On 05.04.2013 15:12, Ted Lemon wrote:
> > > On Apr 5, 2013, at 8:50 AM, Jouni Korhonen <[email-masked]>
> > > wrote:
> > >> Blindly dropping an attribute might not work in all cases. For
> > >> example, in some cases the server might not then be able to provide
> > >> all information the relay needs..
> > >
> > > Well, I did say "silently ignored," not "dropped," but yeah.   If the
> > > server doesn't support that attribute, it's not going to have any
> > > effect anyway.   It seems like silently ignoring it is better than
> > > dropping the whole message, although I suppose you could argue the
> > > opposite, since a misconfiguration of this sort is probably something
> > > the administrator wants to fix immediately, not discover by accident
> > > years later.
> > Anyway, dropping the whole message is definitely too radical here. We
> 
> I was not suggesting dropping the message. I said "blindly dropping an attribute".. which is somewhat different. I am fine with a) but my point was that it is possible in future when new attributes get added to registry server silently discarding attributes may lead to a situation where the server fails to provide enough information back to relay. This needs to be taken into account when defining DHCP extensions relying on this I-D and the established registry.
> 
> Jouni
> 
> > have 3 options when server receives an unknown attribute:
> > a) ignore just the unknown attribute
> > b) ignore the whole radius option
> > c) ignore the whole message
> >
> > I think we have an agreement that a) is the way to go. At least that's
> > what I strongly recommend.
> >
> > Also, depending on server implementation, it is quite likely that the
> > server will parse unknown attributes and handle them in some generic
> > way, e.g. hex string. This is what some implementations do with unknown
> > DHCPv6 options and I imagine similar approach can be taken with RADIUS
> > attributes. Of course, such a behaviour is strictly implementation
> > specific, so there's no need to put anything about it in the spec.
> > So whether the attribute is "unknown" or not may be a bit blurry
> > definition sometimes.
> >
> > "Server MAY ignore received RADIUS attributes that it does not support."
> > seems like a reasonable text here. Some implementors will ignore unknown
> > attribute, some may produce a warning and some my try to handle it in a
> > generic way.
> >
> > Tomek
> > _______________________________________________
> > dhcwg mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 8 Apr 2013 22:34:33 +0800

Jouni - it is possible in future when new attributes get added to registry
server silently discarding attributes may lead to a situation where the
server fails to provide enough information back to relay. 

Does that sounds a question for the newly introduced attribute? 

Anyway, the server is supposed to know the meaning of the attributes from
the relay before its response; if not, the server will silently ignore it.
Right?

Best Regards,

Leaf

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jouni Korhonen
Sent: Monday, April 08, 2013 3:32 PM
To: <[email-masked]>
Cc: dhcwg
Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

- Jouni

Begin forwarded message:

> Anyway, dropping the whole message is definitely too radical here. We

I was not suggesting dropping the message. I said "blindly dropping an
attribute".. which is somewhat different. I am fine with a) but my point was
that it is possible in future when new attributes get added to registry
server silently discarding attributes may lead to a situation where the
server fails to provide enough information back to relay. This needs to be
taken into account when defining DHCP extensions relying on this I-D and the
established registry. 

Jouni

---

From: Ted Lemon <[email-masked]>
Date: Mon, 8 Apr 2013 15:41:59 +0000

On Apr 8, 2013, at 10:34 AM, Leaf Yeh <[email-masked]<mailto:[email-masked]>> wrote:
Jouni - it is possible in future when new attributes get added to registry server silently discarding attributes may lead to a situation where the server fails to provide enough information back to relay.

Also, having the server reflect the option back is easy; having it make changes to the option is actually a protocol update, and probably not a good idea.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 8 Apr 2013 16:25:04 +0000

(This is with chair hat off! I have to remember to indicate that.)

> having the server reflect the option back is easy

The ERO option can be specified to cause the server to send back the option to the relay. I don't think we want to server to "change" the data in the option.

I wonder whether Jouni's concern is that the server may not send the client the correct response? But in that case you need to assure your server is updated accordingly (to use the new Radius attribute) and I don't see that this is really a concern for this document?

We can't assume servers would know how to do something for something that is not yet defined. The "old" server ignoring the attribute in the option is the correct action until it is updated.

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Monday, April 08, 2013 11:42 AM
To: Leaf Yeh
Cc: <[email-masked]>; dhcwg
Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 9 Apr 2013 12:59:46 +0300

On Apr 8, 2013, at 7:25 PM, Bernie Volz (volz) <[email-masked]> wrote:

> The ERO option can be specified to cause the server to send back the option to the relay. I don’t think we want to server to “change” the data in the option.
>  
> I wonder whether Jouni’s concern is that the server may not send the client the correct response? But in that case

This is my concern and yes, it is not a concern of this document but the future documents using the OPTION_RADIUS.

> you need to assure your server is updated accordingly (to use the new Radius attribute) and I don’t see that this is really a concern for this document?
> 
> We can’t assume servers would know how to do something for something that is not yet defined. The “old” server ignoring the attribute in the option is the correct action until it is updated.

Sure.

What I am after is a note stating that a _client_ must be prepared for a reply from a server that does not provide adequate response/information for all the RADIUS attributes the client included in the request. This is solely meant for the future specifications using the OPTION_RADIUS.

- JOuni

> On Apr 8, 2013, at 10:34 AM, Leaf Yeh <[email-masked]> wrote:

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Apr 2013 13:53:04 +0000

> What I am after is a note stating that a _client_ must be prepared for a reply from a server that does not provide adequate response/information for all the RADIUS attributes the client included in…

Yes, I think this would improve the document.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Apr 2013 14:35:45 +0000

On Apr 9, 2013, at 10:31 AM, Tomek Mrugalski <[email-masked]>
 wrote:
> On 09.04.2013 11:59, Jouni Korhonen wrote:
>> What I am after is a note stating that a _client_ must be prepared
>> for a reply from a server that does not provide adequate
>> response/information for all the RADIUS attributes the client
>> included in the request. This is solely meant for the future
>> specifications using the OPTION_RADIUS.
> When clarifying that, we must remember to be explicit about which client
> or server (radius or dhcpv6) we are talking about here.
> 
> Here's DHCPv6 point of view: This DHCPv6 option will never reach DHCPv6
> client. DHCPv6 client will never send it either. DHCPv6 Server will
> never send this option back, just receive it from the DHCPv6 relay.

Oops, right.   So it's the relay that may need to deal with an inappropriate response from the DHCP server?

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 09 Apr 2013 16:31:26 +0200

---

From: "Leaf Yeh" <[email-masked]>
Date: Tue, 9 Apr 2013 23:09:47 +0800

Jouni - ...for all the RADIUS attributes the client included in the request.

The DHCPv6 client never include the RADIUS attribute in this draft, the
DHCPv6 relay include the RADIUS attribute from the RADIUS client.

Ted - So it's the relay that may need to deal with an inappropriate response
from the DHCP server?
Tomek - DHCPv6 Server will never send this option back,...

Tomek's words sounds right in most cases, including those cases described in
Fig.1 & 2 of the draft.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ted Lemon
Sent: Tuesday, April 09, 2013 10:36 PM
To: Tomek Mrugalski
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10

On Apr 9, 2013, at 10:31 AM, Tomek Mrugalski <[email-masked]>
 wrote:
> When clarifying that, we must remember to be explicit about which 
> client or server (radius or dhcpv6) we are talking about here.
> 
> Here's DHCPv6 point of view: This DHCPv6 option will never reach 
> DHCPv6 client. DHCPv6 client will never send it either. DHCPv6 Server 
> will never send this option back, just receive it from the DHCPv6 relay.

Oops, right.   So it's the relay that may need to deal with an inappropriate
response from the DHCP server?

_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 9 Apr 2013 18:26:01 +0300

> or server (radius or dhcpv6) we are talking about here.

Ops. Good catch. Meant actually relay, not client, but wrote something else :-) 

> never send this option back, just receive it from the DHCPv6 relay.

I never said server sending the OPTION_RADIUS back. Still confirming what I
meant & asked to be clarified for future use of OPTION_RADIUS (and whether
my concern is valid to begin with):

0) Magic happens..
1) DHCP Relay sends a relay-forward to DHCP Server with OPTION_RADIUS
   including attributes X,Y,Z.
2) DHCP Server does not understand Z and thus responses to the Relay
   with DHCP options/values based on X & Y only.
3) DHCP Relay receives the response but for it to send a meaningful
   reply to DHCP Client it would need some DHCP option/value in
   the reply that reflects the content of the RADIUS attribute Z
   (that was included into the request sent to Server).
4) what does DHCP Relay do now?

- Jouni

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 09 Apr 2013 17:07:51 +0200

> Oops, right.   So it's the relay that may need to deal with an inappropriate response from the DHCP server?
No. Is is the DHCP server. Relay/radius client get some attributes from
radius server and then sends it along with the relayed message to the
DHCP server. The DHCP server will use that information to select
configuration parameters for the dhcp client. If the relay includes some
Radius attributes the DHCP server does not recognize, the DHCP server
should ignore that particular RADIUS attribute and use those it
understands. Server will send response back to the DHCP client via DHCP
relay, but that response will not include any RADIUS attributes.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Apr 2013 16:24:49 +0000

>   with DHCP options/values based on X & Y only.

This is an administrative error.

>   (that was included into the request sent to Server).

The relay agent _never_ makes any decisions about what to send the client: that decision is made on the server.   Relay agent options can affect how the relay gets the response to the client, but do not affect the content of the response.

As a practical matter, it seems unlikely that a future RADIUS option would affect _how_ the relay agent gets the response back to the client.   So I think this particular scenario is not a problem.

Going back to the administrative error, it's an error because the administration has configured the RADIUS server and relay to support something but neglected to update the DHCP server to support it.   I think this failure mode is worth documenting, but ultimately it's not something that can be addressed in the spec other than as advice to administrators to make sure their DHCP server supports the added functionality they are hoping to get out of RADIUS.

Sorry for my earlier slightly off-base remarks—I have quite a few plates spinning at the moment.

---

From: Tomek Mrugalski <[email-masked]>
Date: Tue, 09 Apr 2013 18:38:27 +0200

On 09.04.2013 17:26, Jouni Korhonen wrote:
> I never said server sending the OPTION_RADIUS back.
You didn't, but someone in this thread mentioned something about sending
the option back to the client.

> Still confirming what I
Send the response back to the client, as usual. This is defined in
RFC3315, section 20.2, which is a very simple section. Here's the
relevant part:

   The relay agent extracts the message from the Relay Message option
   and relays it to the address contained in the peer-address field of
   the Relay-reply message.

As simple as that: decapsulate and send to the client.

Relay is not supposed to inspect the responses coming back from the
server or act as judge of any sort (that response is good and the other
is bad, because some DHCP option related to RADIUS attribute is not
there). Some relays do deep packet inspection for various reasons
(snooping addresses or prefixes for example), but that's an additional
thing that do not affect the basic operation - send the response towards
the client (or next relay closer to the client if there are more
relays). Relays may produce warnings or send some alerts if certain
option is missing, but they need to send the resonse back to the client
anyway. Otherwise they violate RFC3315 and are not really DHCPv6 relays,
but something that acts similar to DHCPv6 relay.

Tomek

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 10 Apr 2013 09:47:31 +0300

> As simple as that: decapsulate and send to the client.

Ok. So this clears my concerns. Thanks for the patience convincing me ;-)

- Jouni