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

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 2 Jan 2003 11:44:21 -0600

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.

>  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:[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
>

---

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

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:
>[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] 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.

 I'm happy to know you could agree a co-located Mobile Node
 is applicable.