Subject: RE: (radius) IPv6

From: "Darran Potter" <[email-masked]>
Date: Thu, 1 Jun 2000 15:01:39 +0100

I also think a new IPADDR_6 type would at least allow older stuff
to carry on working.. sending > 32 bits in IPADDR would be painful.

The transition from ye-olde-plain-text tunnel password to tagged+encrypted
has caused some problems for older hw/sw. But thats nothing to what messing
with IPADDR could cause.

Darran

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of David Mitton
Sent: 31 May 2000 23:44
To: Carl Rigney; [email-masked]; [email-masked]; David Mitton;
[email-masked]
Subject: RE: (radius) IPv6

At 11:06 AM 5/30/00 -0700, Carl Rigney wrote:
>I'd rather add attributes with a new type, since there are only a handful
of
>those, than break all existing RADIUS servers by adding the concept of
length
>sensitive processing.
>--
>Carl Rigney

While I think that's a fair enough decision....

... I'm concerned about the concept of non-six byte ipaddr attributes
"breaking" existing servers.

While they may not understand the value, I would hope that;

a) they would check the length and realize the attribute value received is
not-as-expected for the data type (by their implementation timeframe)

b) ignore the attribute value

c) perhaps flag or log the problem

d) not reject the whole message (though they might per earlier
interpretations of the RADIUS message processing rules)

None of these consequences would be really unusual, as operationally  the
client and server must converge on a mutually understood set of attributes
anyways.

Going a step further, I think primarily NAS-IP-Address would be client
generated. (and Framed-IP-Address if the address was user or NAS
chosen)  Most other ipaddr values would be in a server return profile to
start with.

Older servers would not be able to encode these values, and therefore would
not interoperate with a hypothetical IPv6 RADIUS-speaking NAS.

So I guess that's sort of a rationale for new attributes.  However if they
are anything other than ASCII\\\\\ UTF-8 strings there is something new
here to be implemented anyways.

Dave.

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Carrier Packet Solutions, IP Mobility         978-288-???? FAX
Billerica, MA 01821                    [email-masked]

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 01 Jun 2000 10:43:46 -0400

> "breaking" existing servers.

  Over-loading functionality onto something never designed to have
that functionality often breaks it.  This shouldn't be a surprise.
 
> not-as-expected for the data type (by their implementation timeframe)

  And for the RADIUS server which do NOT check the length, what do
they do?  Often, they'll just use the first 4 octets of the IPv6
address as the IPv4 address.

> b) ignore the attribute value

  Or happily core dump.
 
> c) perhaps flag or log the problem

  Or ignore the problem silently, if they don't core dump.

> client and server must converge on a mutually understood set of attributes 

  (laughs hysterically)

  I guess you have more faith than I do in the various RADIUS
implementations.  Many of the ones I've seen work fine.  However,
there are a large number which are abysmal, and the people using them
cannot, or will not upgrade, or else they simply don't understand that
there is a problem.

  Given the worst scenario (the status quo), I don't think my
descriptions of events are unreasonable.

> not interoperate with a hypothetical IPv6 RADIUS-speaking NAS.

  I'm pessimistic.  I've seen enough RADIUS interoperability problems
to be wary of changes which can cause even more problems.  New
attributes for IPv6 would be the path to the highest level of
interoperation.
 
  Alan DeKok.
-

---

From: "David Mitton" <[email-masked]>
Date: Thu, 01 Jun 2000 14:53:50 -0400

>address as the IPv4 address.

I would argue that implementation is already broken.  And this just serves 
as an illustration and impetus to change.

> > b) ignore the attribute value

That gets people's attention quickly.

>   Or ignore the problem silently, if they don't core dump.

Except that the users' don't get the address they wanted or need.

>cannot, or will not upgrade, or else they simply don't understand that

But the fact of the matter is that the RADIUS client and server MUST 
exchange what's needed or the ISP cannot provide the service.

Actually, I'm just grabbing the opportunity to play advocate for more 
robust software.  If I just get one more person to write more defensive 
protocol code, the network becomes a safer place.

>attributes for IPv6 would be the path to the highest level of

Don't try to out-pessim me...;^)

If you always believe the current stuff won't work if extended, how will 
you ever build new stuff??  Eventually you have to go there.

Given the speed of NAS IPv6 implementations I've witnessed, maybe they 
won't have to implement RADIUS by the time they are ready.

         sigh... Dave.

-

---

From: Alan DeKok <[email-masked]>
Date: Thu, 01 Jun 2000 15:29:45 -0400

"David Mitton" <[email-masked]> wrote:
    [re:  ipv6 address in RADIUS pseudo-IPv4 attributes ]

> Except that the users' don't get the address they wanted or need.

  And they call YOUR tech support, and waste YOUR time, because the
software does weird things.

  I don't know about you, but I hate anwering questions.  If the
protocol can be designed to be robust and well-behaved under
implementation and administrator abuse, that's a damn good thing.

> exchange what's needed or the ISP cannot provide the service.

  What about:

     NAS -> ipv6 aware proxy -> non-ipv6 aware server

  With IPv6 addresses in old IPv4 RADIUS attributes, the end server
dumps core, or returns garbage, and the CORRECTLY WRITTEN proxy server
cannot properly handle the request.

  Your servers are no better than the weakest link in the
authorization/authentication chain.

  If the end server sees the IPv6 attributes as NEW attributes, it
just logs & ignores them.  Everything should still mostly work the same.

> protocol code, the network becomes a safer place.

  That's why my opinion is that new IPv6 specific RADIUS attributes
are the preferred approach.

> you ever build new stuff??  Eventually you have to go there.

  You don't change the foundation under the house if you don't have
to.  The RADIUS foundation is shaky, but it's mostly stable.  I'd
rather see an IPv6 addition in RADIUS, than knocking a whole in an
already shaky foundation, and patching it with duct tape.

  Alan DeKok.
-

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 28 Jun 2000 16:17:11 -0700 (PDT)

All,

Is there ANY vendors out there that currently have defined a vendor specific
attribute of 256? What I mean by this would be the standards VSA (26), with
the "Vendor type" field below set to 256:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           | Vendor type   | Vendor length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Of course, I understand that if one was to follow this structure, one could
NEVER use 256, but there are some vendors out there that do not follow this
suggested VSA structure (and those are the one to whom I am asking this
question).

Thanks,

PatC

-