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

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: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
Jouni Korhonen
Sent: Monday, April 08, 2013 3:32 PM
To: <radext@ietf.org>
Cc: dhcwg
Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

Seems that I forgot to CC mailing lists.

- Jouni

Begin forwarded message:

From: jouni korhonen <jouni.nospam@gmail.com>

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 <tomasz.mrugalski@gmail.com>

5.4.2013 17.16 "Tomek Mrugalski" <tomasz.mrugalski@gmail.com> kirjoitti:
>
> On 05.04.2013 15:12, Ted Lemon wrote:
> > On Apr 5, 2013, at 8:50 AM, Jouni Korhonen <jouni.nospam@gmail.com>
> > 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
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg