Hello Yoshi,

Thanks for your reply. Please see my comments inline.

Regards,
Jayshree

> -----Original Message-----
> From: Yoshiyuki Tsuda [mailto:yoshiyuki.tsuda <at> toshiba.co.jp]
> Sent: Saturday, December 28, 2002 5:02 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: mobile-ip <at> sunroof.eng.sun.com; Chowdhury, Kuntal
> [RICH1:2H18:EXCH];
> ytsuda <at> attbi.com
> 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:yoshiyuki.tsuda <at> toshiba.co.jp]
> >> Sent: Saturday, December 21, 2002 4:10 AM
> >> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> >> Cc: ytsuda <at> attbi.com; 'mobile-ip <at> sunroof.eng.sun.com';
> >> 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.

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

> >>  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:yoshiyuki.tsuda <at> toshiba.co.jp]
> >> >Sent: Friday, December 20, 2002 4:17 PM
> >> >To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> >> >Cc: ytsuda <at> attbi.com; 'mobile-ip <at> sunroof.eng.sun.com';
> >> 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:yoshiyuki.tsuda <at> toshiba.co.jp]
> >> >>Sent: Friday, December 20, 2002 4:46 AM
> >> >>To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> >> >>Cc: ytsuda <at> attbi.com; 'mobile-ip <at> sunroof.eng.sun.com'
> >> >>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
>