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

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

In view Kuntal's email we need to capture the following:

If a NAS does not have enough information to route the packet it shall
reject.  If a RADIUS forwarding server does not have enough information to
route the packet it shall respond with an Access-Reject.

If a RADIUS Server, does not have enugh information to identifiy the user
for authentication purposes, the RADIUS server MUST respond with an
access-reject packet.

> -----Original Message-----
> From: Chowdhury, Kuntal [mailto:[email-masked]] 
> Sent: Friday, May 13, 2005 5:43 PM
> To: Kent Leung (kleung)
> Cc: Nakhjiri Madjid-MNAKHJI1; Avi Lior
> Subject: RE: OFFLIST resolution of RADIUS-MIP identifier issues??
> 
> 
> Routing the AAA message is one thing, but actually able to 
> authenticate the user is another thing. You cannot 
> authenticate the user if the RRQ does not contain ANY 
> information that can be used to identify the user and the 
> HoA=private IP and the network supports overlapping private address.
> 
> I had a discussion with Avi, BTW. We agreed that in such 
> situation the NAS would still send Access-Request with HoA, 
> HA address etc. and the RADIUS server was free to send 
> Access-Reject since there would be NOTHING in the 
> Access-Request that could be used to identify and 
> authenticate the user.
> 
> -Kuntal
> 
> > -----Original Message-----
> > From: Kent Leung (kleung) [mailto:[email-masked]]
> > Sent: Friday, May 13, 2005 3:12 PM
> > To: Chowdhury, Kuntal; Nakhjiri Madjid-MNAKHJI1; Avi Lior
> > Subject: RE: OFFLIST resolution of RADIUS-MIP identifier issues??
> > 
> > 
> > I think this case is up to implementation.  There are other ways to 
> > route the message w/o username AVP.  This is a generic RADIUS issue 
> > which don't need to be solved in this draft, IMHO.  Just 
> map and stop 
> > at that...
> > 
> > Kent
> > 
> > > -----Original Message-----
> > > From: Chowdhury, Kuntal [mailto:[email-masked]]
> > > Sent: Friday, May 13, 2005 11:23 AM
> > > To: Nakhjiri Madjid-MNAKHJI1; Kent Leung (kleung); Avi Lior
> > > Subject: RE: OFFLIST resolution of RADIUS-MIP identifier issues??
> > > 
> > > What exactly you mean by mapping? What you plan to do when MN
> > > uses a private HoA and does not include it's NAI?
> > > 
> > > -Kuntal
> > > 
> > > > -----Original Message-----
> > > > From: Nakhjiri Madjid-MNAKHJI1
> > [mailto:[email-masked]]
> > > > Sent: Friday, May 13, 2005 1:19 PM
> > > > To: 'Kent Leung \(kleung\)'; Avi Lior; Chowdhury, Kuntal
> > > > Subject: RE: OFFLIST resolution of RADIUS-MIP 
> identifier issues??
> > > > 
> > > > 
> > > > I think I stated this as well. Anyway, I agree.
> > > > I like Avi's suggestion. I will get back to you with 
> > > another summary
> > > > to clean everything up. Unfortunately I am in the middle of
> > > something
> > > > right now.
> > > > 
> > > > Madjid
> > > > 
> > > > -----Original Message-----
> > > > From: Kent Leung \(kleung\) [mailto:[email-masked]]
> > > > Sent: Friday, May 13, 2005 1:09 PM
> > > > To: Avi Lior; Chowdhury, Kuntal; Nakhjiri Madjid-MNAKHJI1
> > > > Subject: RE: OFFLIST resolution of RADIUS-MIP 
> identifier issues??
> > > > 
> > > > I'm in agreement.  We should only do mapping...
> > > > 
> > > > Kent
> > > > 
> > > > > -----Original Message-----
> > > > > From: Avi Lior [mailto:[email-masked]]
> > > > > Sent: Friday, May 13, 2005 10:25 AM
> > > > > To: 'Chowdhury, Kuntal'; Nakhjiri Madjid-MNAKHJI1; Kent Leung
> > > > > (kleung); Avi Lior
> > > > > Subject: RE:OFFLIST resolution of RADIUS-MIP 
> identifier issues??
> > > > > 
> > > > >  "OFFLIST"
> > > > > 
> > > > > It seems to me that we are trying to enhance or tighten
> > MIP with
> > > > > this document.
> > > > > 
> > > > > IMO In doing this work we should as much possible avoid
> > > introducing
> > > > > any new rules or tightening the MIP scope.  We should
> > just figure
> > > > > out how to do the mapping and keep it as simple as possible.
> > > > > 
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Chowdhury, Kuntal
> > [mailto:[email-masked]]
> > > > > > Sent: Friday, May 13, 2005 1:03 PM
> > > > > > To: Nakhjiri Madjid-MNAKHJI1; [email-masked];
> > > > > > [email-masked]
> > > > > > Cc: [email-masked]
> > > > > > Subject: RE: resolution of RADIUS-MIP identifier issues??
> > > > > > 
> > > > > > 
> > > > > > 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
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > 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 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: "Kent Leung \(kleung\)" <[email-masked]>
Date: Fri, 13 May 2005 15:10:36 -0700

Getting close ...

> Sent: Friday, May 13, 2005 2:59 PM
> To: 'Chowdhury, Kuntal'; Kent Leung (kleung)
> Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]'
> If a NAS does not have enough information to route the packet 
> it shall reject.  If a RADIUS forwarding server does not have 
> enough information to route the packet it shall respond with 
> an Access-Reject.
> 

Isn't this just normal RADIUS operation for the NAS and RADIUS
forwarding server?  I don't have a problem with explicit language in the
text.  But this seems common sense though.

> If a RADIUS Server, does not have enugh information to 
> identifiy the user for authentication purposes, the RADIUS 
> server MUST respond with an access-reject packet.
> 

I would expect this to be in the normal operation of RADIUS server.

Shouldn't all this be defined in the RFC 2865?  If so, reference that.
If not, agree that such clarification should be in the draft.

Kent

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 13 May 2005 18:43:03 -0400

How does a NAS create an Access-Request based on information in MIPv4 RRQ and what is the authentication style (note that auth style at the FA is FAC as defined in RFC 3012, but at the HA is not defined for RADIUS) is being defined in this ID. So, to answer your question, NO, such behavior is not necessarily defined and universally understood.

I did a quick glance through RFC 2865, I could not find the RADIUS Server behavior w.r.t. the case we are talking about.

-Kuntal

> Sent: Friday, May 13, 2005 5:11 PM
> To: Avi Lior; Chowdhury, Kuntal
> Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]

---

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

> Sent: Friday, May 13, 2005 3:43 PM
> To: Kent Leung (kleung)
> Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]; Avi Lior
> How does a NAS create an Access-Request based on information 
> in MIPv4 RRQ and what is the authentication style (note that 
> auth style at the FA is FAC as defined in RFC 3012, but at 
> the HA is not defined for RADIUS) 

3012bis defines HA case since CCoA is a supported scenario.

> is being defined in this 
> ID. So, to answer your question, NO, such behavior is not 
> necessarily defined and universally understood.
> 
> I did a quick glance through RFC 2865, I could not find the 
> RADIUS Server behavior w.r.t. the case we are talking about.
> 

I'm not trying to give you a hard time. :) I just expected the generic
RADIUS issues to be covered already.  If not, there's no harm to add
that in the Mobile IP based draft.  As I had say,
"If not, agree that such clarification should be in the draft."

Avi, why didn't they cover these common issues in RADIUS draft?

Kent