Subject: [abfab] Trying to publish with a VSA

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 12:42:08 -0400

Hi.

We need a couple of RADIUS attributes.  Realistically I don't think we
can get our attributes from the standard IETF namespace: it's basically
running out of attributes.  There's work in radext
(draft-ietf-radext-radius-extensions) to extend the namespace.

we could create a normative dependency on that work.  I have two
concerns:

1) It's moving kind of slowly.

2) It requires significant changes to client and server RADIUS
libraries. For example the libraries I'm familiar with identify
attributes either by a 32-bit identifier (16 bits of vendor and 16-bits
of attribute) or as a vendor plus an attribute. It's not entirely
obvious what interface changes will need to be made to support these new
attributes, but it's quite clear something is required and it's not done
yet.

For those of us implementing today it's be really convenient to use
RADIUS attributes from a VSA space.  Personally I don't see the problem
with this so long as the organization in question is willing to give up
change control of at least those attributes to the IETF.  It's possible
we could get push back from the IESG.

I'd like to ask the WG though about whether we are willing to try and
use VSA space in a standard assuming we can get change control of the
attributes in question.  I think it will significantly help our
time-to-market and will not have any cost other than cleanliness of
standard.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 18 Oct 2011 09:53:51 -0700

Can we setup a vsa allocation tied to an iana registry?

Skickat från min iPad

18 okt 2011 kl. 09:42 skrev Sam Hartman <[email-masked]>:

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 14:04:07 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> Can we setup a vsa allocation tied to an iana registry?
    Leif> Skickat frÃ¥n min iPad

We could.  I don't really see the value in this though given that there
 is not significant value in having future allocations comes from the
 same vendor registry.

we could ask IANA to maintain a convenience registry to indicate all the
standardized GSS-EAP AAA attributes regardless of their origin.

---

From: Leif Johansson <[email-masked]>
Date: Tue, 18 Oct 2011 11:08:19 -0700

The value is that it wouldn't be tied to a company but to the iesg or some such neutral entity.

Skickat från min iPad

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 14:18:09 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> The value is that it wouldn't be tied to a company but to the
    Leif> iesg or some such neutral entity.  Skickat frÃ¥n min
    Leif> iPad

Right. I guess I don't understand what the value of that is. In my mind
numbers are just numbers; the important thing is to agree on one.  I see
there's value in being able to allocate new numbers, in being able to
define the semantics of something, to control future changes to how some
field is used.  I don't see the value in having a particular number
drawn from someone's namespace though.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Oct 2011 21:28:07 +0200

> (draft-ietf-radext-radius-extensions) to extend the namespace.

  That document is in WG last call.  It's waiting for me to update it.
I hope to do that this week.

> 1) It's moving kind of slowly.

  It's done. :)

> attributes, but it's quite clear something is required and it's not done

  There are multiple implementations of the new format.  It requires
minimal changes to existing libraries.  I know, I've done it.

  IIRC, adding support for the new format (int/ipaddr alone) is ~200
lines of code.  If anyone needs help, I'm glad to assist.

> we could get push back from the IESG.

  It's not really any more work to use the new formats.  If people are
going to be hacking RADIUS implementations anyways to add channel
bindings, adding support for the new format is a small effort.

> time-to-market and will not have any cost other than cleanliness of

  I think requiring the new RADIUS format isn't much of a problem.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 15:47:16 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   There are multiple implementations of the new format.  It
    Alan> requires minimal changes to existing libraries.  I know, I've
    Alan> done it.

    Alan>   IIRC, adding support for the new format (int/ipaddr alone)
    Alan> is ~200 lines of code.  If anyone needs help, I'm glad to
    Alan> assist.

So, when asking about implementation issues the IETF has a tradition
(both from advancement and fromIPR licensing) of asking implementors to
go try and something and report back on their experiences.

I've just sent mail to the RADIUS library provider we use asking what
would be involved in terms of time and cost to add support for this
draft.  I'll report back to the WG. I'm obviously not going to quote
cost numbers, although I'll say something like "no big deal," or "many
fine castles and planes."  From my standpoint the time number is the
much bigger concern.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 19 Oct 2011 19:14:13 +0200

> fine castles and planes."  From my standpoint the time number is the

OK so it sounds like we may not have to deal with VSA space.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 19 Oct 2011 19:24:20 +0200

> OK so it sounds like we may not have to deal with VSA space.

  That would be best, if possible.

  Otherwise, if time pressures are tight, using VSA space is well within
the RADIUS tradition.

  Alan DeKok.

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 19 Oct 2011 20:09:39 +0200

>  Otherwise, if time pressures are tight, using VSA space is well within

but having the VSA attributes controlled by the IETF not so much….

---

From: Leif Johansson <[email-masked]>
Date: Thu, 20 Oct 2011 18:18:21 +0200

> but having the VSA attributes controlled by the IETF not so much….

Right. I understood it to be a sneaky thing to do. My vote is to try
to stay with extended space.

	Cheers Leif