Subject: [Mip4] resolution of RADIUS-MIP identifier issues??

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Thu, 12 May 2005 15:40:23 -0500

Sorry for the long delay on this. I looked at all the email and tried to see the convergence.

Most of the cases seem to be straightforward: put NAI in user name and IP address in HoA.

It seems that the main issue is when HoA is available but NAI is not and the AAA infrastructure (mainly NAS) may not trust HoA routability enough to put it in user name when NAI is not there. Avi suggested we come up with some guidance for implementers, I am not quite sure if I came up with anything. Kuntal suggested a DNS lookup. Maybe we can include that in RADIUS routing requirement section, so that we can deal with it when this draft gets to RADEXT.

Anyway, before you fire away at my statements above, please look at the following summary and if you deem it to be adequate. I will make the changes to the draft accordingly and fire away a new version.

Madjid

Attributes we discussed:

MN HoA, MN NAI, HA IP, NAS ID, user name

Not sure why Avi brought up the MN CoA attribute? We did not have that originally?

The home AAA or HA don't know CoA anyway, so not sure what is used for?

CcoA case: there is no FA, HA acts as NAS

a) If both NAI and HoA available for MN (we can assume HA IP is also available in RRQ):

            User name attribute: MN NAI

            MN HoA attribute: MN HoA IP 

            HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA)

            NAS IP attribute: IP address of HA interface towards the AAA server (this should be a routable IP address)

            NAS ID: FQDN for HA, if available

(Issue: RFC 3344 does not assume that both HoA and NAI are available at the same time.

See section 3.6: when NAI is used HoA is set to 0.0.0.0).

b) If only NAI is available and no HoA is present (HA IP may or may not be present).

            User name: MN NAI

            No MN HoA attribute 

            HA IP attribute (if present)

            NAS IP attribute: IP address for HA interface towards the AAA server

            NAS ID: FQDN for HA, if available

c) If only HoA is present (HA IP should be present as well) but no NAI

            AAA-routability for multi-domain roaming is not possible

            User name: MN FQDN if available??/ MN HoA if deemed routable (***)

            MN HoA: MN HoA

            HA IP attribute (from RRQ)

            NAS IP attribute: HA IP address towards the AAA server).

            NAS ID: FQDN for HA, if available

*** Avi suggested to provide guidance for implementers here? What should we recommend?

For FA-Based case:

a) when both MN NAI and MN HoA are available

            User name attribute: MN NAI

            MN HoA attribute: MN HoA IP 

            HA IP attribute: HA IP from RRQ (interface towards the MN, not towards AAA)

            NAS IP attribute: FA IP address towards the AAA server (this should be a routable IP address)

NAS ID: FQDN for FA, if available

b) If only NAI is available and no HoA is present (HA IP may or may not be present).

            User name: MN NAI

            No MN HoA attribute 

            HA IP attribute (if present in RRQ)

            NAS IP attribute: IP address for FA interface towards the AAA server

NAS ID: FQDN for FA, if available

c) If only HoA is present (HA IP should be present as well) but no NAI

            AAA-routability for multi-domain roaming is not possible

            User name: MN FQDN if available??/ MN HoA if deemed routable (***)

            MN HoA: MN HoA

            HA IP attribute (from RRQ)

            NAS IP attribute: FA IP address towards the AAA server).

NAS ID: FQDN for FA, if available

*** Avi suggested to provide guidance for implementers here? What should we recommend?

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 13 May 2005 01:52:59 -0400

Madjid, 

Good sunnary. I am still not clear about the case when the MN sends a RRQ with a non routable HoA but does not include NAI extension. What should be in the username attribute in that case? We can't assume that the MN FQDN can be drived. So, there won't be anything to identify the user. Why can't we assume that the HA rejects such RRQs (poorly formed RRQ)? It does not make sense to go through hoops to accomodate nasty MN implementations, IMHO.

Regarding the need for the inclusion of CoA in the Access-Request, I think it is optional for the FA and the HA to include it, but it is good to have. 

-Kuntal

--------------------------
Sent from my BlackBerry Wireless Handheld

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>; Kent Leung <[email-masked]>; Avi Lior <[email-masked]>; Chowdhury, Kuntal <[email-masked]>
CC: Mobile IPv4 Mailing List <[email-masked]>
Sent: Thu May 12 15:40:23 2005
Subject: resolution of RADIUS-MIP identifier issues??

Madjid

Attributes we discussed:

 

            User name: MN NAI

            No MN HoA attribute 

            MN HoA: MN HoA

 

For FA-Based case:

 

            User name: MN NAI

            No MN HoA attribute 

 

            MN HoA: MN HoA

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Fri, 13 May 2005 01:16:13 -0700

Hi Madjid.  My comment below in "KL>".

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Nakhjiri Madjid-MNAKHJI1
	Sent: Thursday, May 12, 2005 1:40 PM
	To: Nakhjiri Madjid-MNAKHJI1; Kent Leung (kleung); Avi Lior;
'Chowdhury, Kuntal'
	Cc: Mobile IPv4 Mailing List
	Subject: [Mip4] resolution of RADIUS-MIP identifier issues??

	Sorry for the long delay on this. I looked at all the email and
tried to see the convergence.

	Most of the cases seem to be straightforward: put NAI in user
name and IP address in HoA.

	It seems that the main issue is when HoA is available but NAI is
not and the AAA infrastructure (mainly NAS) may not trust HoA
routability enough to put it in user name when NAI is not there. Avi
suggested we come up with some guidance for implementers, I am not quite
sure if I came up with anything. Kuntal suggested a DNS lookup. Maybe we
can include that in RADIUS routing requirement section, so that we can
deal with it when this draft gets to RADEXT.

	Anyway, before you fire away at my statements above, please look
at the following summary and if you deem it to be adequate. I will make
the changes to the draft accordingly and fire away a new version.

	Madjid

	Attributes we discussed:

	Not sure why Avi brought up the MN CoA attribute? We did not
have that originally?

	The home AAA or HA don't know CoA anyway, so not sure what is
used for?

	 

	a) If both NAI and HoA available for MN (we can assume HA IP is
also available in RRQ):

	            HA IP attribute: HA IP from RRQ (interface towards
the MN, not towards AAA)

	            NAS IP attribute: IP address of HA interface towards
the AAA server (this should be a routable IP address)

	(Issue: RFC 3344 does not assume that both HoA and NAI are
available at the same time.

	KL> I think RRQ fields should be mapped directly to RADIUS AVPs.
So NAI -> username

	       and HoA IP -> MN HoA AVP.  Don't set HoA to 0.0.0.0 if
it's not.  This bit of info

	       might be useful for the RADIUS server.

	b) If only NAI is available and no HoA is present (HA IP may or
may not be present).

	            User name: MN NAI

	            No MN HoA attribute 

	            NAS IP attribute: IP address for HA interface
towards the AAA server

	KL> HoA field is always in RRQ, so "no HoA is present" doesn't
make sense to me.  Pls

	       explain?

	c) If only HoA is present (HA IP should be present as well) but
no NAI

	            AAA-routability for multi-domain roaming is not
possible

	            User name: MN FQDN if available??/ MN HoA if deemed
routable (***)

	            MN HoA: MN HoA

	            NAS IP attribute: HA IP address towards the AAA
server).

	*** Avi suggested to provide guidance for implementers here?
What should we recommend?

	KL> The User-Name AVP MUST be in the Access-Request.  The length
of String field must be >= 3.  What happens when there is no DNS entry
for the MN with private HoA IP address?  How is the User-Name AVP
populated?

	For FA-Based case:

	            HA IP attribute: HA IP from RRQ (interface towards
the MN, not towards AAA)

	KL> HA IP address in RRQ may be any interface address on the
router/HA.  This may be a logical interface or happens to be the same
interface towards AAA.  We should not prohibit any interface as stated
in parenthesis.

	            NAS IP attribute: FA IP address towards the AAA
server (this should be a routable IP address)

	KL> For FA case, are we talking about FA-AAA or HA-AAA
interaction?  I think we need to cover both scenarios.  The NAS IP AVP
is set to the HA/FA IP address towards the AAA server.

	b) If only NAI is available and no HoA is present (HA IP may or
may not be present).

	            User name: MN NAI

	            No MN HoA attribute 

	            NAS IP attribute: IP address for FA interface
towards the AAA server

	KL> Same as above, meaning of "no HoA"?

	c) If only HoA is present (HA IP should be present as well) but
no NAI

	            AAA-routability for multi-domain roaming is not
possible

	            User name: MN FQDN if available??/ MN HoA if deemed
routable (***)

	            MN HoA: MN HoA

	            NAS IP attribute: FA IP address towards the AAA
server).

	*** Avi suggested to provide guidance for implementers here?
What should we recommend?

	Kent

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 13 May 2005 09:50:36 -0500

Hi Kent,

See inlines.

Madjid

-----Original Message-----
From: Kent Leung \(kleung\) [mailto:[email-masked]] 
Sent: Friday, May 13, 2005 3:16 AM
To: Nakhjiri Madjid-MNAKHJI1; Avi Lior; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nakhjiri Madjid-MNAKHJI1
Sent: Thursday, May 12, 2005 1:40 PM
To: Nakhjiri Madjid-MNAKHJI1; Kent Leung (kleung); Avi Lior; 'Chowdhury, Kuntal'
Cc: Mobile IPv4 Mailing List
Subject: [Mip4] resolution of RADIUS-MIP identifier issues??

Madjid

Attributes we discussed:

 

KL> I think RRQ fields should be mapped directly to RADIUS AVPs.  So NAI -> username

       and HoA IP -> MN HoA AVP.  Don't set HoA to 0.0.0.0 if it's not.  This bit of info

 Madjid>>Not sure if I said we make HoA to 0.0.0.0 anywhere? I was just quoting the RFC 3344 behavior as a potential issue for this scenario. But that may not be our problem. We are simply providing support for different scenario. 

            User name: MN NAI

            No MN HoA attribute 

KL> HoA field is always in RRQ, so "no HoA is present" doesn't make sense to me.  Pls

       explain?

Madjid>> Ok, I guess what I meant here was the RFC 3344 behavior, when NAI is present, the MN according to 3344 sets the HoA to 0.0.0.0. You are right, we better include HoA as it is in MN HOA always. I guess this simplifies our life, since cases a and b are now one.  

            MN HoA: MN HoA

KL> The User-Name AVP MUST be in the Access-Request.  The length of String field must be >= 3.  What happens when there is no DNS entry for the MN with private HoA IP address?  How is the User-Name AVP populated?

Madjid>> I agree. Two options in this case: 

1) include HoA in User-Name (as I said in my previous email). If HoA is routable fine, if not either HA must fix it, or the AAA server rejects it.

2) Not sure if we can put zeros in User-Name attribute?

For FA-Based case:

KL> HA IP address in RRQ may be any interface address on the router/HA.  This may be a logical interface or happens to be the same interface towards AAA.  We should not prohibit any interface as stated in parenthesis.

Madjid>> Agree, need to clarify the sentence in the write up. How about, the following in the Mobile IP requirements section?

In case the HA is using different interfaces towards the MN and AAA server, care must be taken so that HA IP includes the IP address used in RRQ and NAS IP includes the address used in AAA signaling. 

KL> For FA case, are we talking about FA-AAA or HA-AAA interaction?  I think we need to cover both scenarios.  The NAS IP AVP is set to the HA/FA IP address towards the AAA server.

Madjid>> this part is about FA-AAA.

            User name: MN NAI

            No MN HoA attribute 

            MN HoA: MN HoA

Kent

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 13 May 2005 10:33:49 -0500

Hi Qiang, 

Thanks for the email. We are not limiting the usage of user-name to anything. Our main concern is that User-Name is really something that must be understood by the AAA infrastructure. The point is whether we have to provide a solution for every case here or not. I don't think we should. If AAA server does not recognize the User-Name, it will simply reject the request.

Madjid

-----Original Message-----
From: Qiang Zhang/Aber [mailto:[email-masked]] 
Sent: Friday, May 13, 2005 10:18 AM
To: Nakhjiri Madjid-MNAKHJI1; 'Chowdhury, Kuntal'; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Mip4] RE: resolution of RADIUS-MIP identifier issues??

Hi, Madjid, a couple comments.. thanks

NAT Traversal is a fairly common practice and MN usually doesn't have a
routable HoA.

In addition, I have impression by reading below that User-Name AVP is being
restricted to use HoA or FQDN for MIP, (ignore this if I got it wrong), in
many cases that the user-name should not be limited to HoA or FQDN , for
example, it can be a MSISDN or any sort of identifier that is compliant with
RADIUS user-name AVP.

Qiang

>
> It seems that we have to have the User-name attribute populated before
sending an Access Request on behalf of the MN. Avi seemed to have issues
with putting an non-routable HoA in User-name. The reasoning is
understandable, however, as you said we cannot fix MN implementation
problems here, unless somebody on this list tells me there is a legitimate
reason for the MN using a non-routable HoA (NAT-traversal?).
> I think we should simply not support NAT traversal at this point.
>

> For case C) where no NAI is available, we should accept
> User-Name=HOA
> MN-HoA=HoA
> The HA simply creates the Access Request and sends it to AAA server. I
don't think we can modify the RFC 3344 behavior of HA here. It is not within
our scope. If NAT traversal drafts define a behavior for HA to change the
non-routable HoA to routable one, then the HA may insert the routable
address inside the MN-HoA or something. I don't think we should deal with
that now. We can provide some recommendation. The AAA server examining these
two fields will recognize that MN did not have an NAI and if HoA is
unrecognizable it will reject the request.
>
> If you guys are ok with this, I will add some text in that effect.
>
> Madjid
>  -----
> Original Message-----
> From: Chowdhury, Kuntal [mailto:[email-masked]]
> Sent: Friday, May 13, 2005 12:53 AM
> To: Nakhjiri Madjid-MNAKHJI1; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: resolution of RADIUS-MIP identifier issues??
>
> Madjid,
>
> Good sunnary. I am still not clear about the case when the MN sends a RRQ
with a non routable HoA but does not include NAI extension. What should be
in the username attribute in that case? We can't assume that the MN FQDN can
be drived. So, there won't be anything to identify the user. Why can't we
assume that the HA rejects such RRQs (poorly formed RRQ)? It does not make
sense to go through hoops to accomodate nasty MN implementations, IMHO.
>
> Regarding the need for the inclusion of CoA in the Access-Request, I think
it is optional for the FA and the HA to include it, but it is good to have.
> To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>; Kent Leung
<[email-masked]>; Avi Lior <[email-masked]>; Chowdhury, Kuntal
<[email-masked]>
> It seems that the main issue is when HoA is available but NAI is not and
the AAA infrastructure (mainly NAS) may not trust HoA routability enough to
put it in user name when NAI is not there. Avi suggested we come up with
some guidance for implementers, I am not quite sure if I came up with
anything. Kuntal suggested a DNS lookup. Maybe we can include that in RADIUS
routing requirement section, so that we can deal with it when this draft
gets to RADEXT.
>
>
>
> Anyway, before you fire away at my statements above, please look at the
following summary and if you deem it to be adequate. I will make the changes
to the draft accordingly and fire away a new version.
>             NAS IP attribute: IP address of HA interface towards the AAA

---

From: Avi Lior <[email-masked]>
Date: Fri, 13 May 2005 11:42:53 -0400

We need to clear this up first:
 
2865 Does not mandate the user-name is required in Access-Request.
 
Here are the appropriate snippets.....
 
Section 4.1 Access-Request
..... An Access-Request SHOULD contain a User-Name attribute.
 
Section 5.1 User-Name
 
User-Name
 
   Description
 
      This Attribute indicates the name of the user to be authenticated.
      It MUST be sent in Access-Request packets if available.
 
Here is the entry in the table.
 Request   Accept   Reject   Challenge   #    Attribute
   0-1       0-1      0        0            1   User-Name
 
And here is what 2865 says about routing:
The User-Name
   attribute MAY contain a Network Access Identifier [8] for RADIUS
   Proxy operations.  The choice of which server receives the forwarded
   request SHOULD be based on the authentication "realm". The
   authentication realm MAY be the realm part of a Network Access
   Identifier (a "named realm").  Alternatively, the choice of which
   server receives the forwarded request MAY be based on whatever other
   criteria the forwarding server is configured to use, such as Called-
   Station-Id (a "numbered realm").

So here is the table of attributes.  (This hopefully simplifies the summary)
 
RADIUS     MIP
------------     -----
User-Name <--- MN-NAI-Extension (see note below)
MN_HOA   <--- HOA (if available)
HA_IP       <---- HA_IP (if available)
NAS_IP    <----- as per RADIUS.
NAS_ID    <----- as per RADIUS.
 
The User-Name MUST be populated with the MN-NAI-Extension if avialable.  If
MN-NAI-Extension is not available the User-Name MAY be left blank.  If
routing of the Access-Request is required it may be performed based on
whatever other criteria criteria the forwarding server is configured to use
such as HoA or HA-IP.  If the NAI is not available, the RADIUS client MAY
populate the user name with a value of annonymous@realm
<mailto:annonymous@realm>  where realm is the result of doing a DNS lookup
using HoA or HA-IP.  [NOTE we need to check the NAI bible]

see more inline

-----Original Message-----
From: Kent Leung (kleung) [mailto:[email-masked]] 
Sent: Friday, May 13, 2005 4:16 AM
To: Nakhjiri Madjid-MNAKHJI1; Avi Lior; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nakhjiri Madjid-MNAKHJI1
Sent: Thursday, May 12, 2005 1:40 PM
To: Nakhjiri Madjid-MNAKHJI1; Kent Leung (kleung); Avi Lior; 'Chowdhury,
Kuntal'
Cc: Mobile IPv4 Mailing List
Subject: [Mip4] resolution of RADIUS-MIP identifier issues??

Sorry for the long delay on this. I looked at all the email and tried to see
the convergence.

Most of the cases seem to be straightforward: put NAI in user name and IP
address in HoA.

It seems that the main issue is when HoA is available but NAI is not and the
AAA infrastructure (mainly NAS) may not trust HoA routability enough to put
it in user name when NAI is not there. Avi suggested we come up with some
guidance for implementers, I am not quite sure if I came up with anything.
Kuntal suggested a DNS lookup. Maybe we can include that in RADIUS routing
requirement section, so that we can deal with it when this draft gets to
RADEXT.

Madjid

Attributes we discussed:

Not sure why Avi brought up the MN CoA attribute? We did not have that
originally?

 

a) If both NAI and HoA available for MN (we can assume HA IP is also
available in RRQ):

            HA IP attribute: HA IP from RRQ (interface towards the MN, not
towards AAA)

(Issue: RFC 3344 does not assume that both HoA and NAI are available at the
same time.

KL> I think RRQ fields should be mapped directly to RADIUS AVPs.  So NAI ->
username

       and HoA IP -> MN HoA AVP.  Don't set HoA to 0.0.0.0 if it's not.
This bit of info

 

b) If only NAI is available and no HoA is present (HA IP may or may not be
present).

            User name: MN NAI

            No MN HoA attribute 

            NAS IP attribute: IP address for HA interface towards the AAA
server

KL> HoA field is always in RRQ, so "no HoA is present" doesn't make sense to
me.  Pls

       explain?

            User name: MN FQDN if available??/ MN HoA if deemed routable
(***)

            MN HoA: MN HoA

            NAS ID: FQDN for HA, if available
[Avi] We shouldnt specify what is in NAS ID other then what is already
recommended by RADIUS. You can say it should be the FQDN but you must not
mandate it.  So I belive that standard RADIUS definition is sufficient.

*** Avi suggested to provide guidance for implementers here? What should we
recommend?

KL> The User-Name AVP MUST be in the Access-Request.  The length of String
field must be >= 3.  What happens when there is no DNS entry for the MN with
private HoA IP address?  How is the User-Name AVP populated?
[Avi] No.  That is wrong as shown above. 

For FA-Based case:

            HA IP attribute: HA IP from RRQ (interface towards the MN, not
towards AAA)

KL> HA IP address in RRQ may be any interface address on the router/HA.
This may be a logical interface or happens to be the same interface towards
AAA.  We should not prohibit any interface as stated in parenthesis.

            NAS IP attribute: FA IP address towards the AAA server (this
should be a routable IP address)

KL> For FA case, are we talking about FA-AAA or HA-AAA interaction?  I think
we need to cover both scenarios.  The NAS IP AVP is set to the HA/FA IP
address towards the AAA server.

b) If only NAI is available and no HoA is present (HA IP may or may not be
present).

            User name: MN NAI

            No MN HoA attribute 

            NAS IP attribute: IP address for FA interface towards the AAA
server

            User name: MN FQDN if available??/ MN HoA if deemed routable
(***)

            MN HoA: MN HoA

*** Avi suggested to provide guidance for implementers here? What should we
recommend?

Kent

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 13 May 2005 13:02:58 -0400

Madjid,

Rejecting a poorly formed RRQ is not a protocol violation. If the user uses a private IP address as HoA and does not include NAI extension, it is entirely upto the HA provider's policy to accept or reject the registration request. If the provider's network is setup with non-overlapping private IP addresses and these private addresses can be mapped to unique usernames, then the HA MAY process the request by setting username=HoA. Otherwise, the HA SHOULD reject the request as the user cannot be uniquely identified. I think we need to clarify the HA behavior on this line.

BTW, support of private IP address (private HoA) at the HA does not necessarily mean that the HA has NAT traversal support. HAs are deployed with overlapping private IP address pools for different enterprises. Such traffic are tunneled to/from the enterprise via the HA. The NAT can be somewhere in the enterprise.

-Kuntal

> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> Sent: Friday, May 13, 2005 9:40 AM
> To: Chowdhury, Kuntal; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: resolution of RADIUS-MIP identifier issues??
> 
> 
> Hi Kuntal,
> 
> It seems that we have to have the User-name attribute 
> populated before sending an Access Request on behalf of the 
> MN. Avi seemed to have issues with putting an non-routable 
> HoA in User-name. The reasoning is understandable, however, 
> as you said we cannot fix MN implementation problems here, 
> unless somebody on this list tells me there is a legitimate 
> The HA simply creates the Access Request and sends it to AAA 
> server. I don't think we can modify the RFC 3344 behavior of 
> HA here. It is not within our scope. If NAT traversal drafts 
> define a behavior for HA to change the non-routable HoA to 
> routable one, then the HA may insert the routable address 
> inside the MN-HoA or something. I don't think we should deal 
> with that now. We can provide some recommendation. The AAA 
> server examining these two fields will recognize that MN did 
> not have an NAI and if HoA is unrecognizable it will reject 
> the request.
> 
> Good sunnary. I am still not clear about the case when the MN 
> sends a RRQ with a non routable HoA but does not include NAI 
> extension. What should be in the username attribute in that 
> case? We can't assume that the MN FQDN can be drived. So, 
> there won't be anything to identify the user. Why can't we 
> assume that the HA rejects such RRQs (poorly formed RRQ)? It 
> does not make sense to go through hoops to accomodate nasty 
> MN implementations, IMHO.
> 
> Regarding the need for the inclusion of CoA in the 
> Access-Request, I think it is optional for the FA and the HA 
> to include it, but it is good to have. 
> 
> -Kuntal
> 
> 
> To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>; 
> Kent Leung <[email-masked]>; Avi Lior 
> <[email-masked]>; Chowdhury, Kuntal 
> It seems that the main issue is when HoA is available but NAI 
> is not and the AAA infrastructure (mainly NAS) may not trust 
> HoA routability enough to put it in user name when NAI is not 
> there. Avi suggested we come up with some guidance for 
> implementers, I am not quite sure if I came up with anything. 
> Kuntal suggested a DNS lookup. Maybe we can include that in 
> RADIUS routing requirement section, so that we can deal with 
> it when this draft gets to RADEXT.
> 
>  
> 
> Anyway, before you fire away at my statements above, please 
> look at the following summary and if you deem it to be 
> adequate. I will make the changes to the draft accordingly 
> and fire away a new version.
> 
>  
> 
> Madjid
> 
>  
> 
>  
> 
> Attributes we discussed:
> 
>             NAS IP attribute: IP address of HA interface 
> towards the AAA server (this should be a routable IP address)
>

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Fri, 13 May 2005 13:07:24 -0700

Hi Avi.  Comments below in "KL>".

	From: Avi Lior [mailto:[email-masked]] 
	Sent: Friday, May 13, 2005 8:43 AM
	To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Avi Lior;
Chowdhury, Kuntal
	Cc: Mobile IPv4 Mailing List
	Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

	 
	2865 Does not mandate the user-name is required in
Access-Request.
	 
	KL> I was looking at RFC 2138 (my usual reference :), which is
obsoleted by this RFC.

	 

	Section 5.1 User-Name
	 
	User-Name
	 
	   Description
	 
	      This Attribute indicates the name of the user to be
authenticated.
	      It MUST be sent in Access-Request packets if available.

	KL> OK, User-Name AVP may be not in the messages.

	And here is what 2865 says about routing:
	The User-Name
	   attribute MAY contain a Network Access Identifier [8] for
RADIUS
	   Proxy operations.  The choice of which server receives the
forwarded
	   request SHOULD be based on the authentication "realm". The
	   authentication realm MAY be the realm part of a Network
Access
	   Identifier (a "named realm").  Alternatively, the choice of
which
	   server receives the forwarded request MAY be based on
whatever other
	   criteria the forwarding server is configured to use, such as
Called-
	   Station-Id (a "numbered realm").
	 
	KL> OK
	 
	So here is the table of attributes.  (This hopefully simplifies
the summary)
	 
	RADIUS     MIP
	------------     -----
	 
	The User-Name MUST be populated with the MN-NAI-Extension if
avialable.  If MN-NAI-Extension is not available the User-Name MAY be
left blank. 
	 
	KL> If the MN-NAI-Extension is absent, then the User-Name AVP
MAY be left out of the RADIUS messages, right?  The User-Name string
field has to be >= 3 octets.

	  If routing of the Access-Request is required it may be
performed based on whatever other criteria criteria the forwarding
server is configured to use such as HoA or HA-IP.  If the NAI is not
available, the RADIUS client MAY populate the user name with a value of
annonymous@realm <mailto:annonymous@realm>  where realm is the result of
doing a DNS lookup using HoA or HA-IP.  [NOTE we need to check the NAI
bible]

	see more inline
	 <snip> 
	 
	Kent

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Fri, 13 May 2005 16:41:26 -0500

Ok, this email got blocked because it was too long. So I am sending it again, without all the previous emails...

Madjid

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 
Sent: Friday, May 13, 2005 2:36 PM
To: 'Avi Lior'; 'Kent Leung (kleung)'; Chowdhury, Kuntal; Nakhjiri Madjid-MNAKHJI1
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

Thanks Avi for the clarification and the suggestion. I guess now we are not obligated to add a User-Name if we don't have an NAI.

We also know at this point that every RRQ MUST have an HoA field, it may have been populated by a routable HoA, non-routable HoA or just 0.0.0.0. Regardless of the case, there IS an HoA field and if the NAS creates an Access Request it will include that in the MN HoA attribute. If the HA decides to reject an RRQ, there is nothing we will do here.

Question: Is HA IP address a mandated field in MIP RRQ? What will the MN insert there if it does not know the HA?

Ok, another attempt at the summary:

For CcoA case: 

The HA acts as a NAS. The HA may or may not use two different interfaces towards the MN and AAA server.

If the HA decides to create a RADIUS Access Request, the attributes are populated as following

User-Name: MN-NAI from MN-NAI extension of MIP RRQ

MN-HoA: HoA from MIP RRQ (including cases where HoA=0.0.0.0)

HA IP: HA IP address from MIP RRQ

NAS IP: As instructed per RADIUS for Access Request (maybe different from HA IP)

NAS ID: as instructed per RADIUS

Note that creating a RADIUS Access Request based on a RRQ is within the discretion of HA. If the MIP HA deems the RRQ or its contents (such as the HoA or HA-IP included in the RRQ) or lack thereof (such as NAI) inappropriate for processing, it MAY reject the RRQ without creating a RADIUS Access Request. If HA acting as a RADIUS client decides to create a RADIUS Access Request and the MN-NAI-Extension is not available in the RRQ, the HA can populate the User-Name attribute according the network policies and is outside the scope of this specification. For instance User-Name MAY be left blank or be populated with  <mailto:annonymous@realm> anonymous@realm where realm is the result of doing a DNS lookup using HoA or HA-IP. 

For FA-based CoA, similar to above, except FA acts as a RADIUS client.

---

From: Avi Lior <[email-masked]>
Date: Fri, 13 May 2005 18:03:17 -0400

Kent,
 
The User-Name MUST be populated with the MN-NAI-Extension if avialable.  If
MN-NAI-Extension is not available the User-Name MAY be left blank. 
 
KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left
out of the RADIUS messages, right?  The User-Name string field has to be >=
3 octets.
 
You are correct. YOu cant send a blank.  It must be ommitted.

-----Original Message-----
From: Kent Leung (kleung) [mailto:[email-masked]] 
Sent: Friday, May 13, 2005 4:07 PM
To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

  _____  

To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Avi Lior; Chowdhury,
Kuntal

 
KL> I was looking at RFC 2138 (my usual reference :), which is obsoleted by
this RFC.

 

Section 5.1 User-Name
 
User-Name
 
   Description

 

KL> OK

RADIUS     MIP
------------     -----
 
The User-Name MUST be populated with the MN-NAI-Extension if avialable.  If
MN-NAI-Extension is not available the User-Name MAY be left blank. 
 
KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left
out of the RADIUS messages, right?  The User-Name string field has to be >=
3 octets.

  If routing of the Access-Request is required it may be performed based on
whatever other criteria criteria the forwarding server is configured to use
such as HoA or HA-IP.  If the NAI is not available, the RADIUS client MAY
populate the user name with a value of  <mailto:annonymous@realm>
annonymous@realm where realm is the result of doing a DNS lookup using HoA
or HA-IP.  [NOTE we need to check the NAI bible]

see more inline
 <snip> 
 
Kent

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Mon, 16 May 2005 10:57:51 -0500

I guess I missed the resolution. Do we or do we not send a blank User-Name attribute if NAI is missing?

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Friday, May 13, 2005 5:03 PM
To: 'Kent Leung (kleung)'; Avi Lior; Nakhjiri Madjid-MNAKHJI1; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

Kent,

The User-Name MUST be populated with the MN-NAI-Extension if avialable.  If MN-NAI-Extension is not available the User-Name MAY be left blank. 

KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left out of the RADIUS messages, right?  The User-Name string field has to be >= 3 octets.

-----Original Message-----
From: Kent Leung (kleung) [mailto:[email-masked]] 
Sent: Friday, May 13, 2005 4:07 PM
To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

  _____  

To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Avi Lior; Chowdhury, Kuntal

KL> I was looking at RFC 2138 (my usual reference :), which is obsoleted by this RFC.

 

Section 5.1 User-Name

User-Name

   Description

 

The User-Name

KL> OK

RADIUS     MIP

------------     -----

The User-Name MUST be populated with the MN-NAI-Extension if avialable.  If MN-NAI-Extension is not available the User-Name MAY be left blank. 

KL> If the MN-NAI-Extension is absent, then the User-Name AVP MAY be left out of the RADIUS messages, right?  The User-Name string field has to be >= 3 octets.

  If routing of the Access-Request is required it may be performed based on whatever other criteria criteria the forwarding server is configured to use such as HoA or HA-IP.  If the NAI is not available, the RADIUS client MAY populate the user name with a value of  <mailto:annonymous@realm> annonymous@realm where realm is the result of doing a DNS lookup using HoA or HA-IP.  [NOTE we need to check the NAI bible]

see more inline
 <snip> 

Kent

---

From: Avi Lior <[email-masked]>
Date: Mon, 16 May 2005 14:07:16 -0400

You cant send a blank attribute.  We can force it to nul.  But there is no
point in doing that. 
 
This is the statement that we need to make:
 
MN-NAI-Extension, if available, SHOULD be placed in the User-Name attribute.
 
Reason behind it:
 
1) Why SHOULD. Some application may want to put something else in the
User-Name attribute.  There maybe a better NAI and we dont want them to be
forced to always use MN-NAI-Extenison
 
2) We dont want to say "If NAI is not avialable User-Name SHALL|SHOULD be
ignored" because some deployments may have something else they can put in
that attribute.
 
So in the sprit of just doing mapping, then that is the only requirement
that we should impose.  However, we are still free to make some
recommendations.

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
Sent: Monday, May 16, 2005 11:58 AM
To: 'Avi Lior'; 'Kent Leung (kleung)'; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

I guess I missed the resolution. Do we or do we not send a blank User-Name
attribute if NAI is missing?

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Friday, May 13, 2005 5:03 PM
To: 'Kent Leung (kleung)'; Avi Lior; Nakhjiri Madjid-MNAKHJI1; Chowdhury,
Kuntal

Kent,

-----Original Message-----
From: Kent Leung (kleung) [mailto:[email-masked]] 
Sent: Friday, May 13, 2005 4:07 PM
To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] resolution of RADIUS-MIP identifier issues??

  _____  

 

Section 5.1 User-Name

User-Name

   Description

 

The User-Name

KL> OK

RADIUS     MIP

------------     -----

 

 

see more inline
 <snip> 

Kent