Subject: Re: Last call on extensions document?

From: Peter Deacon <[email-masked]>
Date: Tue, 2 Aug 2011 14:11:18 -0700 (Pacific Daylight Time)

On Tue, 26 Jul 2011, Alan DeKok wrote:

>  Can we do a last call on the extensions document?  The list has had
> little discussion on it.

>  I think the name will need to change, as RFC 2868 is already RADIUS
> extensions.

Aside from picking up the 64-bit int type my crystal ball is saying there 
will be increasing need for Combo-IP like data type to convey either IPv4 
or IPv6 address information in one attribute.

As IPv6 is deployed following the current scheme of keeping address 
families separated into separate attributes wherever addresses are used 
will become problematic as cases where the address family is not known in 
advance creep up.

Vendors are using it in their VSA spaces so why not just add a few 
paragraphs.  I'll volunteer.  This way future attributes with an IP data 
type have the option if makes sense for them.

Thought about suggesting it in the IPv6 draft but perhaps better for 
everyone to get that one done ASAP.

regards,
Peter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 02 Aug 2011 17:36:58 -0400

Peter Deacon wrote:
> Aside from picking up the 64-bit int type my crystal ball is saying
> there will be increasing need for Combo-IP like data type to convey
> either IPv4 or IPv6 address information in one attribute.

  Oh, that scares me.

> will become problematic as cases where the address family is not known
> in advance creep up.

  My $0.02 is that it would be better to use TLVs.  But I welcome an
inspired discussion on the topic. :)

> type have the option if makes sense for them.

  So far as I know, it's only WiMAX that does this.

> everyone to get that one done ASAP.

  If everyone else here thinks it's a good idea, fine.  But I'm not sure
that's going to happen.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 4 Aug 2011 10:53:24 -0700 (Pacific Daylight Time)

> inspired discussion on the topic. :)

In most cases where an attribute of type IP Address needs to be defined 
there will be a need for an IPv6 analogue of that same attribute.

Some examples:

Naming services
Access control and filtering
Flow export and logging servers
Application proxies (smtp, web content filter..etc)
App specific services

There are implementation costs and operational costs associated with the 
approach of segregating address families.  Costs can be reduced somewhat 
with a ComboIP (Payload Len 4 = IPv4, 16 = IPv6) data type.

Currently:

1. Multiple attributes need to be defined.

2. Operators entering an IP Address into fields need to make sure they 
select the correct attribute based on the address family they are 
targeting.

Operators may enter a hostname and have the system enter the resolved 
address.  In this case the operator may have no knowledge of the address 
family or it may change tomorrow!

The system will need to provide additional intelligence during the name 
lookup process to select the proper attribute based on address family for 
each instance.

We can live without however much like gigawords I believe with the new 
attribute space comes some opportunity to improve the standard framework 
for future attributes.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Thu, 04 Aug 2011 20:52:00 -0400

> there will be a need for an IPv6 analogue of that same attribute.

  OK.

> 1. Multiple attributes need to be defined.

  With 1000+ new attributes and TLVs, I'm not sure this is an issue.

> select the correct attribute based on the address family they are

  That's a UI problem.  The system in which they enter the IP should
know (a) the address family, and (b) the relevant attribute.  There's no
reason to force the admin to make those choices.

> family or it may change tomorrow!

  Which is a disaster for maintainable systems.  Having the RADIUS
response change because of modifications to DNS is terrible.  I strongly
oppose that kind of setup.

> lookup process to select the proper attribute based on address family
> for each instance.

  It can send multiple attributes.  Foo-IPv4, Foo-IPv6, Foo-IPv4, etc.

  Why select?  If the DNS lookup provides 2 IPv4s, and 1 IPv6, why not
send that in RADIUS?

> attribute space comes some opportunity to improve the standard framework

  Of course.

  While adding "combo IP" seems OK for WiMAX, I'm not convinced that the
above use-cases *require* it.  The same result can be achieved with
family-specific attributes.

  Alan DeKok.

---

From: Peter Deacon <[email-masked]>
Date: Thu, 4 Aug 2011 21:45:25 -0700 (Pacific Daylight Time)

>  With 1000+ new attributes and TLVs, I'm not sure this is an issue.

It is unecessary, redundant and wasteful.

> reason to force the admin to make those choices.

Its a problem that does not need to exist.  Regardless of where you punt 
for those attributes taking advantage of combo IP the issue goes away.

> oppose that kind of setup.

Use of naming services to abstract network addresses is universal.  Kind 
of the whole point of using these systems in the first place.

>  Why select?  If the DNS lookup provides 2 IPv4s, and 1 IPv6, why not

Of course you can enumerate the result of name lookups and send multiple 
attributes if there are multiple results.  I never suggested otherwise.

Without combo IP the system needs *extra* intelligence to know the IPv4 
and IPv6 analogue for each attribute.  With combo IP this is unnecessary as 
the same attribute can be used and the system just works.

> family-specific attributes.

64-bit integers are not required to convey 64-bit data types.  There are 
thousands of attributes available.  The same result can be achieved with 
gigawords.

*require* is not the point.  I think this was made pretty clear in the "we 
can live without" language used above.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Fri, 05 Aug 2011 07:47:32 -0400

> of the whole point of using these systems in the first place.

  What I meant was that *unexpected* changes are a problem.  DNS is
nice, and useful for many things.  RADIUS policies are usually
relatively fixed.  Having them depend on DNS means that a non-RADIUS
admin can effectively update the RADIUS policies.

  I've seen this cause problems in practice, which makes me wary of it.

> and IPv6 analogue for each attribute.  With combo IP this is unnecessary
> as the same attribute can be used and the system just works.

  The main way I can see combo IP being useful is if family-specific
attributes were to be deprecated.

  Unless there's a groundswell of support for it on this list, I don't
see combo-IP making it into the document.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Fri, 5 Aug 2011 11:24:46 -0400

I also support the notion of having a "family-specific" attribute set.

My reasons are somewhat different.

In the case of carrying a "pure" IPv6 address and a pure IPv4 address then
the argument for having a single attribute to carry both makes sense.

However, IPv6 addresses have different flavours.  Sometime I want to carry
a "pure" IPv6 address, sometimes I want to convey just the prefix and
sometimes I want to convey the prefix and the interface and thus I need to
include the prefix length in the address.  There are examples of these
encodings already in the IETF.

A family-specific approach is good.  Thus if we want to create such a
beast for IPv6 addresses we should create an attribute that can meet all
the use cases or have an attribute type for each use case.

Avi

---

From: Peter Deacon <[email-masked]>
Date: Fri, 5 Aug 2011 08:51:19 -0700 (Pacific Daylight Time)

>  I've seen this cause problems in practice, which makes me wary of it.

By specifying a name you delegate responsibility for resolution to the 
naming service.  This is always the case no matter where that name is 
stored.

> see combo-IP making it into the document.

This was never my intention.  My intention was a couple of paragraphs to 
explain a new data type attribute designers may want to take advantage of 
for their *future* work while implementing new attributes in the new 
attribute space.

regards,
Peter

---

From: Peter Deacon <[email-masked]>
Date: Fri, 5 Aug 2011 09:20:49 -0700 (Pacific Daylight Time)

> I also support the notion of having a "family-specific" attribute set.

I'm sorry for any confusion.  The intent was never to "take away" any 
options that already exist.  I certainly am not suggesting any current 
attributes be changed in any way.

All I suggested is that a new "data type" be specified allowing single IP 
Addresses to be conveyed in either IPv4 or IPv6 address family.

It would be up to the designer of a new attribute to weigh the pros and 
cons and select the appropriate data type.  This would simply be another 
tool in the extensions toolbox at their disposal.

> the argument for having a single attribute to carry both makes sense.

My recommendation is limited to anything that would currently fit in the 
IPv4 or IPv6 address data types.

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Fri, 05 Aug 2011 17:53:48 -0400

Peter Deacon wrote:
> explain a new data type attribute designers may want to take advantage
> of for their *future* work while implementing new attributes in the new
> attribute space.

  If it's in the doc, people will use it.  We need to agree that it's a
good idea before it's standardized.

  Alan DeKok.