Subject: RE: [Mip4] review: draft-ietf-mip4-faerr-01.txt

From: [email-masked]
Date: Tue, 20 Sep 2005 16:09:16 -0700

Hi Charlie.  Looks good with a few comments below.

1) New text for FA notifying HA after MN section.  Feel free to massage
to your satisfaction.

5. Mobile Node Considerations

   If a mobile node receives a successful Registration Reply (status
   code 0 or 1), with a FA Error extension indicating that the foreign
   agent is not honoring said Registration Reply, the mobile node SHOULD
   then send a deregistration message to the home agent.  In this way,
   the home agent will not maintain a registration status that is
   inconsistent with the status maintained by the foreign agent.

6. Foreign Agent Considerations

   When denying a successful Registration Reply, the Foreign Agent
SHOULD 
   send the a Registration Revocation message [RFC 3543] to the Home
Agent 
   if a mobility security association exists between them.  The benefit
   of this operation is identified in previous section.

2) SHOULD or MAY?  As Gabe mentioned, this act (triggered w/o
authentication)
   can be something we can live with or without.  I'm OK either way.

   If a mobile node receives a successful Registration Reply (status
   code 0 or 1), with a FA Error extension indicating that the foreign
   agent is not honoring said Registration Reply, the mobile node SHOULD
   then send a deregistration message to the home agent.  In this way,
   the home agent will not maintain a registration status that is
   inconsistent with the status maintained by the foreign agent.

3) Since the MN cannot tell which message is real, suggest a little
rewording
   to the following paragraph.

   In many common cases, the mobile node will not have a security
   association with the foreign agent that has sent the extension.
   Thus, the mobile node will be unable to ascertain that the foreign
   agent sending the extended Registration Reply message is the same
   foreign agent that earlier received the associated Registration
   Request from the mobile node.  Because of this, a malicious foreign
   agent could cause a mobile node to operate as if the registration had
   failed, when in fact its home agent and a correctly operating foreign
   agent had both accepted the mobile node's Registration Request.  In
   order to reduce the vulnerability to such maliciously transmitted
   Registration Reply messages with the unauthenticated extension, the
   mobile node MAY delay processing of such Registration Reply messages
   for a short while in order to determine whether another authentic
   Registration Reply might be received from the true foreign agent.

 To give priority of accepted over denied replies, reworded:

   order to reduce the vulnerability to such maliciously transmitted
   Registration Reply messages with the unauthenticated extension, the
   mobile node MAY delay processing of such denied Registration Reply
messages
   for a short while in order to determine whether another successful
   Registration Reply might be received.
 
 Note, that this allows a rogue node to blackhole a MN's session by
sending
 registration reply without FA error ext, when the real FA is denying
the
 registration.  But this is better than rogue node forcing MN to
deregister
 after successful registration.

Kent

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Charles E. Perkins
> Sent: Monday, September 19, 2005 5:48 AM
> To: [email-masked]; Jari Arkko
> Cc: [email-masked]
> Subject: Re: [Mip4] review: draft-ietf-mip4-faerr-01.txt
> 
> 
> Hello folks,
> 
> I made a new document.  It might not be "done" yet until the 
> current issues are agreed to have been resolved, but anyway 
> it's available if you want to have a look, at the following URL:
>     http://people.nokia.net/charliep/txt/mobilefaerr/faerr.txt
> 
> Regards,
> Charlie P.
> 
> 
> 
> --
> Mip4 mailing list: [email-masked]
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
> 

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 21 Sep 2005 14:16:01 +0300

Hello Kent,

I have made the changes as you suggested.  Only one substantial
comment, at the end...

[email-masked] wrote:

>........
O.K.  I added this new section.

>   can be something we can live with or without.  I'm OK either way.
For now, it has been changed to SHOULD.

>   Registration Reply might be received.
O.K.  I made this change.  Unless I missed something, it only consists of
adding the single word.

> after successful registration.
Maybe it's time to resuscitate some ideas from a long time ago.
At one time I had a draft which specified how a home agent could
fashion a key for a MN-FA security association and send it along
with the registration reply.  It's not perfect, but it would prevent
problems like this.  I reckon it would be a pretty good improvement
overall.

Regards,
Charlie P.