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

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

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 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. 

-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??

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: "Qiang Zhang/Aber" <[email-masked]>
Date: Fri, 13 May 2005 11:17:30 -0400

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?).

> 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.
> 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
server (this should be a routable IP address)