Subject: RE: [mobile-ip] RFC3012bis-04 Available

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 2 Jan 2003 13:08:15 -0600

Hello Yoshi,

Please see my response inline. 

Regards,
Jayshree

> -----Original Message-----
> From: Yoshiyuki Tsuda [mailto:[email-masked]]
> Sent: Saturday, December 28, 2002 5:03 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]'; [email-masked]';
> [email-masked]
> Subject: Re: [mobile-ip] RFC3012bis-04 Available
> 
> 
> Jayshee,
> 
>  Unfortunately, the proposed text will cause a problem.
>  There is the following case where both MN-AAA authentication
>  extension and a Mobile-Foreign authentication extension are
>  required:
> 
>  If an MN has a configured home address, but the MN doesn't
>  have a configured HA, and the MN wants to be authorized by
>  an AAA, and there is an SA between the MN and an FA, both
>  an MN-AAA authentication extension and a Mobile-Foreign
>  authentication are required, you know, where,
>  - the MN-AAA authentication extension is used to verify the
>    MN and assign an HA,

[JB] The intent of RFC3012bis is to use MN-AAA Authentication 
extension when there is no security association between the MN 
and the FA. If you already have a security association between
MN and the FA, what type of verification the MN is trying to
do with the AAA? 

>  - the Mobile-Foreign authentication extension is used to
>    verify the MN by a visited network.
> 
>  And, I believe a protocol should define mechanisms, not
>  policies;  your proposed texts smells the policy to prohibit
>  the above customer's requests.
> 
[JB] Unfortunately, we have to deal with the optionality and hence 
need this type of policy so that customer's requirements are clarified.

> Thanks.
> -Yoshi
> 
> at Mon, 23 Dec 2002 15:32:30 -0600, Jayshree Bharatia wrote:
> >Hello all,
> > 
> >Currently we have the following paragraph in section 6 
> >"If the mobile node does not include a Mobile-Foreign 
> Authentication [7]
> >extension, then it MUST include the Mobile-AAA 
> Authentication extension
> >whenever the Challenge extension is present." 
> > 
> >As Mark pointed out, there is nothing in this draft to 
> prevent having both
> >MN-AAA and MN-FA authentication extensions in the 
> Registration Request.
> >Since we are interested in either MN-AAA authentication or MN-FA
> >authentication, I like to propose the following text for section 6.
> > 
> >"If the mobile node does not include a Mobile-Foreign 
> Authentication [7]
> >extension, then it MUST include the Mobile-AAA 
> Authentication extension
> >whenever the Challenge extension is present. But the same 
> Registration
> >Request MUST not include both Mobile-Foreign Authentication 
> extension and
> >Mobile-AAA Authentication extension."
> > 
> >Any comments?
> > 
> >Regards,
> >Jayshree
> >
> >-----Original Message-----
> >From: Robert J Marks [mailto:[email-masked]]
> >Sent: Monday, December 23, 2002 2:58 PM
> >To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> >Subject: RE: [mobile-ip] RFC3012bis-04 Available
> >
> >
> >Hi Jayshree,
> > 
> >The draft does not appear to prohibit both the MN-FA and 
> MN-AAA extensions
> >from being present in the same request. I do not believe you 
> can assume that
> >if one is present, the other will not be. Perhaps if the 
> intent is to allow
> >one or the other, the draft could be more specific.
> > 
> >Bob
> >
> >-----Original Message-----
> >From: [email-masked]
> >[mailto:[email-masked]] On Behalf Of 
> Jayshree Bharatia
> >Sent: Monday, December 23, 2002 2:30 PM
> >To: [email-masked]' 
> <mailto:[email-masked]'>
> >
> >Subject: FW: [mobile-ip] RFC3012bis-04 Available
> >
> >
> >
> >
> >
> >-----Original Message----- 
> >From: Bharatia, Jayshree [RICH1:2H13:EXCH] 
> >Sent: Monday, December 23, 2002 2:28 PM 
> >To: 'Yoshiyuki Tsuda'; [email-masked]' 
> >Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH] 
> >Subject: RE: [mobile-ip] RFC3012bis-04 Available 
> >
> >
> >Hello Yoshi, 
> >
> >Please see my comments below. 
> >
> >Regards, 
> >Jayshree 
> >
> >> -----Original Message----- 
> >> From: Yoshiyuki Tsuda [ mailto:[email-masked]
> ><mailto:[email-masked]> ] 
> >> Sent: Saturday, December 21, 2002 4:10 AM 
> >> To: Bharatia, Jayshree [RICH1:2H13:EXCH] 
> >> Cc: [email-masked]; [email-masked]'; 
> >> Chowdhury, Kuntal 
> >> [RICH1:2H18:EXCH] 
> >> Subject: Re: [mobile-ip] RFC3012bis-04 Available 
> >> 
> >> 
> >> Hi Jayshree, 
> >> 
> >>  Thank you for your pointer.  I've found it in Appendix B. 
> >>  OK, AAA is expected to set BAD_AUTHENTICATION(67).  Then, 
> >
> >[JB] Not sure why you have mentioned that AAA is expected to set
> >BAD_AUTHENTICATION (67). The draft RFC3012bis expects the 
> foreign agent to
> >send BAD_AUTHENTICATION error code in a Registration Reply if the
> >verification at AAA fails. Please note that interactions 
> between the AAA and
> >Foreign Agent are not part of RFC3012bis.
> >
> >>  there is a small issue; if an MN receives the error code 
> >>  of BAD_AUTHENTICATION(67), and if there are Mobile-Foreign 
> >>  authentication extension and MN-AAA authentication 
> >>  extension in a registration request or a registration reply, 
> >>  the MN cannot distinguish which extension has the error... 
> >> 
> >
> >[JB] As per the current description in RFC3012bis draft, if 
> the Mobile Node
> >does not have a security association with the Foreign Agent, 
> the Mobile Node
> >must include the Mobile-AAA Authentication extension.  If security
> >association exists between the MN and the FA, the MN-FA 
> authentication
> >extension is included and there won't be MN-AAA 
> authentication extension in
> >the Registration Request message. Hence there is no issue.
> >
> >>  Also, in case of a co-located Mobile Node, which error code 
> >>  does the MN expect to receive, 67 or 131 ? 
> >> 
> >
> >[JB] RFC3012bis allows a foreign agent to use a 
> challenge/response mechanism
> >to authenticate the mobile node. For co-located Mobile Node, 
> this mechanism
> >is not applicable.
> >
> >>  Although the above issues might be so small, it would have 
> >>  be much clearer to assign a new error code to the verification 
> >>  error of MN-AAA authentication extension, I'd like to think. 
> >>  Have great holidays! 
> >> 
> >> Thanks. 
> >> -Yoshi 
> >> 
> >> at Fri, 20 Dec 2002 16:25:45 -0600, Jayshree Bharatia wrote: 
> >> >Hello Yoshi, 
> >> > 
> >> >For a verification error, the AAA has to set the error code. 
> >> This is what 
> >> >currently is not in the scope of RFC3012bis. But once this 
> >> verification 
> >> >failure is notified to the FA, the error code 
> >> BAD_AUTHENTICATION is sent to 
> >> >the mobile node in the Registration Reply. This is discussed 
> >> in section 3.2 
> >> >of RFC3012bis draft. 
> >> > 
> >> >Regards, 
> >> >Jayshree 
> >> > 
> >> >-----Original Message----- 
> >> >From: Yoshiyuki Tsuda [ mailto:[email-masked]
> ><mailto:[email-masked]> ] 
> >> >Sent: Friday, December 20, 2002 4:17 PM 
> >> >To: Bharatia, Jayshree [RICH1:2H13:EXCH] 
> >> >Cc: [email-masked]; [email-masked]'; 
> >> Chowdhury, Kuntal 
> >> >[RICH1:2H18:EXCH] 
> >> >Subject: Re: [mobile-ip] RFC3012bis-04 Available 
> >> > 
> >> > 
> >> >Hi Jayshree and all, 
> >> > 
> >> > Thank you for your qualification. 
> >> > Ah, it's outside the scope of rfs3012bis ?!!! 
> >> > I understand authentication issues by AAA should be treated 
> >> > by AAA(diameter).  But, personally I'd thought rfc3012 was 
> >> > the best place to define error codes related to MN-AAA 
> >> > authentication extension, because MN's developers won't 
> >> > read Diameter's I-Ds without a pointer, and because right 
> >> > now such an error code is missing in Diameter's I-Ds, I'm 
> >> > afraid. 
> >> > Have great holidays! 
> >> > 
> >> >Thanks. 
> >> >-Yoshi 
> >> > 
> >> > 
> >> >at Fri, 20 Dec 2002 11:44:12 -0600, Jayshree Bharatia wrote: 
> >> >>Hello Yoshi, 
> >> >> 
> >> >>The verification and related processing at AAA is outside 
> >> the scope of 
> >> >>RFC3012bis. The current version of RFC3012bis (04) has a 
> >> description in 
> >> >>section 3.2 regarding how verification errors received from 
> >> the AAA are 
> >> >>treated at the foreign agent. 
> >> >> 
> >> >>Regards, 
> >> >>Jayshree 
> >> >> 
> >> >> 
> >> >>-----Original Message----- 
> >> >>From: Yoshiyuki Tsuda [ mailto:[email-masked]
> ><mailto:[email-masked]> ] 
> >> >>Sent: Friday, December 20, 2002 4:46 AM 
> >> >>To: Bharatia, Jayshree [RICH1:2H13:EXCH] 
> >> >>Cc: [email-masked]; [email-masked]' 
> >> >>Subject: Re: [mobile-ip] RFC3012bis-04 Available 
> >> >> 
> >> >> 
> >> >>Hi Jayshree, 
> >> >> 
> >> >> Just one question: 
> >> >> If an AAA find an authentication error in MN-AAA 
> >> >> authentication extension, what error code will the AAA 
> >> >> return to an MN ? 
> >> >> 
> >> >> I've just found the above error code is missing; a 
> >> >> guideline to allocate error codes from the AAA seems to 
> >> >> be missing, I'm afraid.  Or, am I missing any other RFCs ? 
> >> >> 
> >> >> Someone suggested me to use 131 (mobile node failed 
> >> >> authentication).  I think it's a good idea to use it 
> >> >> instead now... 
> >> >> 
> >> >>Thanks in advance. 
> >> >>-Yoshi 
> >> >> 
> >> >> 
> >> >>at Tue, 17 Dec 2002 13:09:32 -0600, Jayshree Bharatia wrote: 
> >> >>>Hello all, 
> >> >>> 
> >> >>>New version of RFC3012bis (version 04) is now available at 
> >> >>> http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc
> ><http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc>  
> >3012bis-04.txt. 
> >>>> 
> >>>>Thanks, 
> >>>>Jayshree 
>

---

From: Yoshiyuki Tsuda <[email-masked]>
Date: Fri, 03 Jan 2003 21:21:28 +0900

Hi Jayshree,

 My comments are embeded in the following...

Thanks.
-Yoshi

>MN and the FA, what type of verification the MN is trying to

 As I wrote in the above, the AAA(H) is expected to
 authenticate the MN and assign an HA to the MN.
 In this case, you know, there isn't a Mobile-Home
 Authentication extension, but an MN-AAA Authentication
 extension at the beginning in order to authenticate
 the MN.

>need this type of policy so that customer's requirements are clarified.

 Then, I'd like to ask you WHY you proposed that the
 Request must not include both Mobile-Foreign
 Authentication extension and Mobile-AAA Authentication
 extension.

 Are there any serious problems ?