Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)

From: "Mark Jones" <[email-masked]>
Date: Wed, 10 Jan 2001 16:40:48 -0500

In DIAMETER, the IPv4 and IPv6 addresses are collapsed into the single
Address datatype where the actual IP version is determined from the length.
The RADIUS and IPv6 draft (draft-aboba-radius-ipv6-04.txt) appears to take a
different approach by using separate AVPs for IPv4 and IPv6 addresses, e.g.
Login-IP-Host and Login-IPv6-Host.

I was considering whether the DIAMETER approach could also applied in
RADIUSv6 since a common approach would simplify the RADIUS-DIAMETER gateway
implementation.

The RADIUSv6 draft does state that IPv4 and IPv6 attributes MAY be included
in the same RADIUS message and the NAS will decide which attributes to use.
However, I see no reason why a DIAMETER or RADIUS packet could not contain
two instances of the same address AVP: one IPv4 and one IPv6 address. The
NAS could still use the same logic to decide which attributes to use for the
session.

Are there any other issues that would prevent a common approach?

Regards,
       Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Pat Calhoun
> Sent: January 10, 2001 9:44 AM
> To: [email-masked]
> Subject: [diameter] data type modifications to DIAMETER (Fwd)
>
>
> FYI
> >----------------Begin Forwarded Message----------------<
>
> Date: Wed, 10 Jan 2001 15:18:52 +0100
> From: "Erik Guttman" <[email-masked]>
> Subject: data type modifications to DIAMETER
> To: [email-masked], [email-masked]
>
>
> As proposed in draft-ietf-aaa-issues-04.txt and
> draft-ietf-aaa-solutions-01.txt section 9.2, I am
> revising the basic data types in DIAMETER.
>
> I do not list all the changes in this document -
> but the implications are the following.
>
>  1. Data type changes:
>
>     Old type        New type
>     ------------    -------------
>     Address         Address
>     Data            OctetString
>     String          OctetString
>     Time            Unsigned32
>     Integer32       Integer32
>     Integer64       Integer64
>     Complex         Grouped
>                     Unsigned32
>                     Unsigned64
>                     Float32
>                     Float64
>                     Float128
>
>  2. Scalar quantities (Ids and so on from AVPs) had Integer32 type.
>     Now they have Unsigned32 type.
>
>  3. String is now one interpretation of an OctetString.
>
>  4. Time is now one interpretation of an Unsigned32 value.
>
>  5. The biggest change is the elimination of the 'Complex' data
>     type.  Now all AVPs have an 'atomic' data type except for
>     Grouped.  Grouped takes as its value a list of AVPs which
>     have to be included (AVP header and all) in exactly the
>     sequence specified.
>
> Implications for DIAMETER implementations:
>
>   The only real change is that Complex data types have been
>   restructured.  Code handling AVPs which were previously of
>   type Complex will have to change.
>
>   Code which handled the previous types will be easily mapped
>   into the new data types (Integer32 -> Unsigned32, Time ->
>   Unsigned32, String -> OctetString)  There are some subtle
>   range checking changes to be made (maybe) since scalars are now
>   Unsigned32 where before they were Integer32.
>
> Rationale:
>
>   See draft-ietf-aaa-issues-04.txt.  In short, there were several
>   problems with the basic types used by DIAMETER.  (1) Some were
>   interpretations (String and Time) not basic scalars.  (2) Some
>   were ambiguous (Integer32 used as an unsigned scalar).  (3) Not
>   including basic types (floats, mostly) makes future expansion
>   hard.  (4) The types specified were incompatible with SMI and
>   SPPI data types. (5) The complex data type made it hard to
>   create a general data model, easily automated parsers and
>   general 'sniffers.'  All AVPs should either have atomic values
>   or a list of AVPs as their values.  (6) The Grouped-AVP was
>   unnecessarily complex. (7) Complex data types required a 'hack'
>   for fixing the length of certain data fields (such as using 16
>   bytes for addresses where they could be 4 bytes long).  This is
>   no longer necessary.
>
> Erik
>
>
>
> >----------------End Forwarded Message----------------<
>
>

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 10 Jan 2001 13:35:19 -0800 (PST)

I think that the orignal intent of having a dual purpose AVP was to reduce the
number of AVPs that would have to be defined. Furthermore, the Implementation
Guidelines, which describes the protocol gateway stuff, would have to include
text that describes what to do if an IPv4 was found, as opposed to an IPv6
address.

Are there any others that have any concerns with the dual purpose AVP approach?
 PatC

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 10 Jan 2001 17:01:24 -0500

Pat,

I understand the rationale of the dual purpose AVP and have no concerns
about its use in DIAMETER. I was just suggesting that we consider using the
same approach in RADIUSv6 to simplify the gateway implementation.

Regards,
       Mark

> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Pat Calhoun
> Sent: January 10, 2001 4:35 PM
> To: Mark Jones
> Cc: [email-masked]; [email-masked]
> Subject: RE: [diameter] data type modifications to DIAMETER (Fwd)
>
>

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 10 Jan 2001 13:53:08 -0800 (PST)

Oh, I see. You were questioning whether RADIUSv6 should change. That may be
harder to do, unless these new attributes have a new type, perhaps
Dual-Address, instead of Address.

PatC

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 10 Jan 2001 18:23:12 -0500

Pat,

> Oh, I see. You were questioning whether RADIUSv6 should change.
> That may be harder to do, unless these new attributes have a new type,
> perhaps Dual-Address, instead of Address.
>

Would new RADIUS attributes for IPv6 addresses still be required if RADIUSv6
were to adopt the dual purpose AVP approach? If, as suggested by the
RADIUSv6 spec, the RADIUS packet contained both IPv4 and IPv6 AVPs, the NAS
can still distinguish the IPv4/IPv6 addresses by their length and so can
choose the appropriate instance of the address AVP depending on whether its
client is IPv4 or IPv6.

If there is not a common approach to IPv4/IPv6 address encoding, the
DIAMETER-RADIUS gateway must translate, for example, a DIAMETER
Login-IP-Host AVP to a RADIUS Login-IP-Host or Login-IPv6-Host AVP depending
on its length. Not complex. Just tedious.

Regards,
       Mark

---

From: Pat Calhoun <[email-masked]>
Date: Wed, 10 Jan 2001 16:06:47 -0800 (PST)

> on its length. Not complex. Just tedious.

But how would you deal with backward compatibility? This seems especially
important given that in a roaming network, you never know whether the home, or
the NAS, support v6.

PatC

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 11 Jan 2001 13:11:30 -0500

Pat,

> important given that in a roaming network, you never know whether
> the home, or the NAS, support v6.
>

Wouldn't all the RADIUS/DIAMETER servers in the proxy chain will know
whether the NAS itself is IPv6 or IPv4 by virtue of (1) in DIAMETER, the
length of the NAS-IP-Address AVP, or (2) in RADIUS, presence of the
NAS-IP-Address vs NAS-IPv6-Address AVP?

It seem unlikely to me that a RADIUS request received from an IPv6 NAS by a
dual-stack (v4/v6) RADIUS server would then be proxied unmodified to a
legacy IPv4 RADIUS server. Similarly, a RADIUS response received from an
IPv6 RADIUS server would not be returned unmodified to a legacy IPv4 NAS. Do
you think the dual purpose AVP approach would significantly increase the
complexity of the translation being done by a dual-stack RADIUS server?

Whether the host requesting service from the NAS actually supports IPv6 is
another issue since as the RADIUSv6 draft points out:

"Note that a NAS sending a RADIUS Access-Request may not know a-priori
whether the host will be using IPv4, IPv6, or both. For example, within
PPP, NCP occurs after LCP, so that address assignment will not occur
until after RADIUS authentication and authorization has completed.
Therefore it is presumed that the IPv6 attributes described in this
document MAY be sent along with IPv4-related attributes within the same
RADIUS message and that the NAS will decide which attributes to use."

Regards,
       Mark

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 11 Jan 2001 10:08:22 -0800 (PST)

> RADIUS message and that the NAS will decide which attributes to use."

Right, but chances of getting *something* back from the home server are quite
high if two attributes are added, one for each address family, as opposed to
inserting an IPv6 in an attribute that the home server expected to be only
32bit in length. Chances it would drop the request in this case, hence
increasing the difficulty in troubleshooting.

PatC

---

From: "Jari Arkko" <[email-masked]>
Date: Thu, 11 Jan 2001 20:32:20 +0200

> increasing the difficulty in troubleshooting.

Thinking about the major places (e.g. 3g) where DIAMETER could be
deployed in the future, I think it would be even reasonable to *require* IPv6 attribute
support from all DIAMETER nodes. Which would be rather trivial and
different from than supporting IPv6 itself on DIAMETER or the functions
of the NAS.

Jari

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 11 Jan 2001 14:40:52 -0500

Pat,

[[email-masked] removed from CC list. Thread concerns RADIUSv6.]

> increasing the difficulty in troubleshooting.

Yes, I understand the potential problem if a packet containing an IPv6
address AVP arrives at an IPv4 RADIUS server:

1) Using two different AVPs, one for each address family

An IPv6 NAS sends an Access-Request containing Foo-IP-Address AVP and
Foo-IPv6-Address AVP to the first hop dual-stack RADIUS server. This RADIUS
server proxies the request unmodified onto an IPv4 RADIUS server. The IPv4
RADIUS server ignores Foo-IPv6-Address since it has an unknown Type but
otherwise processes the request normally.

2) Using two instances of the same AVP, one for each address family

An IPv6 NAS sends an Access-Request containing a 4-byte (IPv4)
Foo-IP-Address AVP and an 8-byte (IPv6) Foo-IP-Address AVP to the first hop
dual-stack RADIUS server. This RADIUS server proxies the request unmodified
onto an IPv4 RADIUS server. The IPv4 RADIUS server drops the request on
encountering an 8-byte Foo-IP-Address since it expected a 4-byte IPv4
address.

Is this the problem you are refering to?

Alternatively, the dual-stack RADIUS server filters out the IPv6 AVPs before
sending on the request to the IPv4 RADIUS server. In my example (2) above,
the dual-stack RADIUS server removes the 8-byte Foo-IP-Address AVP before
forwarding the request. The IPv4 RADIUS server just sees the 4-byte (IPv4)
Foo-IP-Address AVP and processes the request normally.

Regards,
       Mark

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 11 Jan 2001 12:13:03 -0800

Pat Calhoun [mailto:[email-masked]] writes:

> > were to adopt the dual purpose AVP approach?

Wouldn't this scheme require changes to RADIUS data types?  That can't be
done...

> > If, as suggested by the

Such is the life of a gateway :-)

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 11 Jan 2001 12:41:18 -0800 (PST)

> Wouldn't this scheme require changes to RADIUS data types?  That can't be

That's my point, but Mark is envisioning an environment where proxies strip
out AVPs based on the next hop's capabilities (see previous e-mail). Of
course, this doesn't help too much in environments where a v6 nas talks to a
v4/v6 proxy, to a v4 proxy then to a v4/v6 home server.

PatC

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 11 Jan 2001 14:28:06 -0800

Mark Jones [mailto:[email-masked]] writes:

> Foo-IPv6-Address AVP to the first hop dual-stack RADIUS server.

Why does the RADIUS server need to be dual-stack?  We're talking attributes
here...

> This RADIUS
> dual-stack RADIUS server.

If the 'Foo'=='NAS' in this case, it is prohibited by RFC 2865.

> This RADIUS server proxies the request
> unmodified

I don't think that it matters what version of IP the RADIUS server is
running, just what Attributes it supports.  The reason why new Attributes
were defined is that the kind ofthing you are describing is illegal in
RADIUS.

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 11 Jan 2001 18:19:58 -0500

Pat,

> Of course, this doesn't help too much in environments where a v6 nas
> talks to a v4/v6 proxy, to a v4 proxy then to a v4/v6 home server.
>

Yes, you're right. The IPv6 AVP filtering definitely fails in this scenario.
I've learned my lesson: Don't try to ease the migration by trying to mess
with the legacy protocol.

Regards,
       Mark

---

From: "Mark Jones" <[email-masked]>
Date: Thu, 11 Jan 2001 18:22:42 -0500

Glen,

> Why does the RADIUS server need to be dual-stack?  We're talking

I meant that the host on which the RADIUS server was running has both IPv4
and IPv6 connections. This is obviously only relevant if the RADIUS server
is manipulating attributes depending on whether the destination is a v4 or
v6 host. I now understand where this approach fails in a proxy chain
scenario (see my reply to Pat).

Regards,
       Mark

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 11 Jan 2001 15:19:30 -0800 (PST)

> scenario (see my reply to Pat).
Glen's question was more to the fact that a RADIUS server doesn't have to be
dual stack (or support both IP protocols in the kernel). It merely has to be
able to support both address families in the server (app layer)
implementation. So your use of dual-stack was a little misleading.

PatC