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

From: "Jayshree Bharatia" <[email-masked]>
Date: Fri, 3 Jan 2003 11:33:57 -0600

> -----Original Message-----
> From: Yoshiyuki Tsuda [mailto:[email-masked]]
> Sent: Friday, January 03, 2003 6:18 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: [email-masked]; Chowdhury, Kuntal 
> [RICH1:2H18:EXCH];
> [email-masked]
> Subject: Re: [mobile-ip] RFC3012bis-04 Available
> 
> 
> Hi Jayshree,
> 
>  Thank you for your email.  My comments are inlined:
> 
> Thanks.
> -Yoshi
> 
> at Thu, 2 Jan 2003 11:44:21 -0600, Jayshree Bharatia wrote:
> >Hello Yoshi,
> >
> >Thanks for your reply. Please see my comments inline.
> >
> >Regards,
> >Jayshree
> >
> >> -----Original Message-----
> >> From: Yoshiyuki Tsuda [mailto:[email-masked]]
> >> Sent: Saturday, December 28, 2002 5:02 AM
> >> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> >> Cc: [email-masked]; Chowdhury, Kuntal 
> >> [RICH1:2H18:EXCH];
> >> [email-masked]
> >> Subject: Re: [mobile-ip] RFC3012bis-04 Available
> >> 
> >> 
> >> Hi Jayshree,
> >> 
> >>  Sorry for my late reply.  My comments are inlined below.
> >> 
> >> Thanks.
> >> -Yoshi
> >> 
> >> at Mon, 23 Dec 2002 14:28:15 -0600, Jayshree Bharatia wrote:
> >> >Hello Yoshi,
> >> >
> >> >Please see my comments below.
> >> >
> >> >Regards,
> >> >Jayshree
> >> >
> >> >> -----Original Message-----
> >> >> From: Yoshiyuki Tsuda [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.
> >> 
> >>  Oops, in case of BAD_AUTHENTICATION, an FA can overwrite
> >>  the error code in a Registration Reply.  But, generally, 
> >>  if an FA overwrite the error code, an MN will fail in
> >>  authentication calculation of MN-AAA authentication
> >>  extension in a Registration Reply.  So, an FA should NOT
> >>  overwrite the error code as much as it can.  This means
> >>  an AAA is expected to set the error code before the AAA
> >>  calculates the MN-AAA authentication extension in a
> >>  Registration Reply.
> >> 
> >[JB] We are talking about two different protocols, the AAA
> > protocol between the AAA-FA and MIP between FA-MN. Hence,
> > FA needs to have MIP error code corresponding to the error
> > code it receives on the AAA-FA interface. By the way,
> > according to section 6, the Registration Reply to the MN
> > must not include the Mobile-AAA Authentication Extension.
> 
>  Ah, I've found that text in section 6 that the MN-AAA
>  Authentication extension must not be included in the
>  registration reply.
> 
>  If you happen to know the above reason, could you point
>  it to me ?
>  Because at least draft-ietf-mobileip-challenge-09.txt
>  didn't have that text, and from my memory I'd seen the
>  MN-AAA Authentication extension in an RRP from some
>  vendor at the past bakeoff.  I'm now trying to find when
>  and why the above text was added to the RFC3012 through
>  the Mobile IP archive...
> 
[JB] The text on not having MN-AAA auth extension in a Registration Reply
has been there in RFC3012 as well as all the versions of RFC3012bis. 
> 
> >>  In case of BAD_AUTHENTICATION, the MN-AAA authentication
> >>  extension itself has a problem.  So, an MN can use the
> >>  error code without calculating the authentication value...
> >> 
> >> >>  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.
> >> 
> >>  There ia a case where both an MN-AAA authentication
> >>  extension and an Mobile-Foreign authentication extension
> >>  are required.  I will write about it in the reply to your
> >>  next email.
> >> 
> >> >>  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.
> >> 
> >>  ???
> >>  If an R-bit is set in an advertisement from an FA,
> >>  an MN must send a Registration Request via an FA,
> >>  even if the MN is using co-located care-of address.
> >>  In this case, the Mobile-Foreign challenge extension
> >>  is included in a Registration Request.
> >> 
> >> 
> >[JB] As I have indicated earlier, the RFC3012bis allows a foreign
> > agent to use a challenge/response mechanism to authenticate the
> > mobile node. If MN is using co-located care-of address with 'R'
> > bit set, there is no issue in using challenge extension. In this
> > case, since the error-code sent to MN by the FA always falls in
> > range of 64-127, the choice is clear and that is error code 67.
> 
>  I'm happy to know you could agree a co-located Mobile Node
>  is applicable.
> 
I agree for the case where there is a foreign agent involved. Otherwise, in
general, it is not applicable for a co-located Mobile Node.

> >> >>  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]]
> >> >> >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]]
> >> >> >>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
> >> >3012bis-04.txt.
> >> >>>>
> >> >>>>Thanks,
> >> >>>>Jayshree
> >> 
>