Subject: Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt

From: Yingchun Xu <[email-masked]>
Date: Fri, 2 Jun 2000 13:31:25 -0500

Mandating the behaviour of not removing MN-AAA AE is necessary for FA.
Otherwise, it will create an interoperability issue.
if one FA removes it and another don't and the MN and HA wants to use MN-AAA AE
for mobile node authentication, it will work on one visited network and break on
another.
On the other hand, if FA s keeps MN-AAA AE in RRQ, it's upto HA to decide
whether to use it or not.

---Yingchun.

Rajesh Bhalla <[email-masked]> on 06/02/2000 12:53:56 PM

Please respond to Rajesh Bhalla <[email-masked]>

Sent by:  Rajesh Bhalla <[email-masked]>

To:   [email-masked]
cc:    (Yingchun Xu/MW/US/3Com)
Subject:  Re: [MOBILE-IP] I-D ACTION:draft-ietf-mobileip-challenge-10.txt

Pat,

  Thanks for clarifications on the use of MN-AAA AE  in
  section 6 of the updated draft.

  However I have concern about another change in section 3.2
  (Foreign Agent Processing for Registration Requests). Para 6
  of the updated version states: "the foreign agent MUST NOT
  remove the MN-AAA AE from the RRQ".  I do not think that
  we want to mandate such behaviour at the FA. In fact, the text
  in following paras 7 and 9 ( section 3.2) describs the actions
  at the FA,  if it were to remove the MN-AAA AE.

  Could you please help clarify.

Thanks
Rajesh Bhalla

At 06:42 AM 6/2/00 -0400, [email-masked] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working
Group of the IETF.
>
>        Title           : Mobile IP Challenge/Response Extensions
>        Author(s)       : C. Perkins, P. Calhoun
>        Filename        : draft-ietf-mobileip-challenge-10.txt
>        Pages           : 16
>        Date            : 01-Jun-00
>
>Mobile IP, as originally specified, defines an authentication
>extension (the Mobile-Foreign Authentication extension) by
>which a mobile node can authenticate itself to a foreign agent.
>Unfortunately, this extension does not provide ironclad replay
>protection for the foreign agent, and does not allow for the use
>of existing techniques (such as CHAP) for authenticating portable
>computer devices.  In this specification, we define extensions for
>the Mobile IP Agent Advertisements and the Registration Request
>that allow a foreign agent to use a challenge/response mechanism to
>authenticate the mobile node.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-10.txt
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>        "get draft-ietf-mobileip-challenge-10.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>        [email-masked].
>In the body type:
>        "FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>        MIME-encoded form by using the "mpack" utility.  To use this
>        feature, insert the command "ENCODING mime" before the "FILE"
>        command.  To decode the response(s), you will need "munpack" or
>        a MIME-compliant mail reader.  Different MIME-compliant mail readers
>        exhibit different behavior, especially when dealing with
>        "multipart" MIME messages (i.e. documents which have been split
>        up into multiple messages), so check your local documentation on
>        how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-mobileip-challenge-10.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-mobileip-challenge-10.txt>
>

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 2 Jun 2000 11:35:44 -0700

Precisely. It comes down to a policy decision on the Home Agent on whether or
not the MN-AAA needs to be authenticated. Ensuring that the FA never strips
the extension allows the HA to make such a decision.

PatC
----
> if one FA removes it and another don't and the MN and HA wants to use MN-AAA
> AE for mobile node authentication, it will work on one visited network and
> break on another.
> >This draft is a work item of the IP Routing for Wireless/Mobile Hosts
> Working Group of the IETF.
> >
> >"anonymous" and a password of your e-mail address. After logging in, >type
> "cd internet-drafts" and then >        "get
> draft-ietf-mobileip-challenge-10.txt". >

---

From: Rajesh Bhalla <[email-masked]>
Date: Fri, 2 Jun 2000 13:36:16 -0700

Pat,

  Alright. Do you then plan to update the draft to remove ambiguity
  at other places [paras 7 and 9 (section 3.2)]. There the draft
  talks about the possibility of FA removing MN-AAA AE.

--- Rajesh

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 2 Jun 2000 14:59:58 -0700

>   talks about the possibility of FA removing MN-AAA AE.

Paragraph 7 discusses the removal of the MN-AAA extension, while Paragraph 9
discusses the removal of the Challenge extension. There is no inconsistency,
as far as I can tell.

PatC
> >Precisely. It comes down to a policy decision on the Home Agent on whether
> or >not the MN-AAA needs to be authenticated. Ensuring that the FA never
> strips >the extension allows the HA to make such a decision.
> >
> >PatC
> >----
> >>
> >>
> >> if one FA removes it and another don't and the MN and HA wants to use
> MN-AAA >> AE for mobile node authentication, it will work on one visited
> network and >> break on another.
> >> >Internet-Drafts are also available by anonymous FTP. Login with the
> username >> >"anonymous" and a password of your e-mail address. After
> logging in, >type >> "cd internet-drafts" and then >        "get
> >> >        a MIME-compliant mail reader.  Different MIME-compliant mail
> readers >> >        exhibit different behavior, especially when dealing with