Subject: Re: [Mip4] RFC 3344 - Home Agent Registration Code 132 -foreignagent failed authentication

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 02 Sep 2008 12:48:58 -0700

Hello Kent,

Regarding the case:

- MN-HA authentication fails, FA-HA authentication:
    -- MN-HA SA exists ==>  MUST send #131
    -- no MN-HA SA  ==>  MUST silently drop

you wrote:
Kent Leung (kleung) wrote:
> ....       In the last case, it's better that HA SHOULD
> send #131 when MN-HA authentication failed (SA exists) because of the
> following reasons:
> 	- Pending registration entries can be limited so resource
> consumption is not an issue
> 	- Badly behaving MNs that sends unauthenticated RRQs can be
> controlled by the above function in addition to L2 association checks
> 	- Allow flexibility for HA to not respond to RRQ which failed
> MN-HA authentication
>
>   

I think the case is stronger for MUST, though.  No pending registration
record is required for the rejection, and rate limiting can help to take 
care
of misbehaving MNs (... or, did I miss your point here?).  Whether or not
the HAs should have the flexibility is the issue.  Here, it seems to me that
the HA should help "known" MNs to distinguish between simple network
outage/unavailability versus inoperative security.

I hope we can hear from other WG members and get this issue
finally nailed down.

Regards,
Charlie P.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Charles E. Perkins
> Sent: Monday, August 25, 2008 1:32 PM
> To: Kent Leung (kleung)
> Cc: Mobile IPv4 Mailing List; Ahmad Muhanna
> Subject: Re: [Mip4] RFC 3344 - Home Agent Registration Code 132
> -foreignagent failed authentication
>
>
> Hello Kent,
>
> I think there are several cases, and that each case could likely have
> different answers.  The original issue was about the FA-HA
> authentication, but I agree with you that the case of the MN-HA
> authentication is important.
>
> I think these are the relevant cases, with some suggested actions for
> each case.
> - FA-HA authentication fails:
>     -- FA-HA SA exists ==>  MAY send #132
>     -- no FA-HA SA  ==>  MUST silently drop
>
> - MN-HA authentication fails, no FA-HA SA:
>     -- MN-HA SA exists ==>  MAY send #131
>     -- no MN-HA SA  ==>  MUST silently drop
>
> - MN-HA authentication fails, FA-HA authentication:
>     -- MN-HA SA exists ==>  MUST send #131
>     -- no MN-HA SA  ==>  MUST silently drop
>
> Here, in the last case when there is no SA with the mobile node, the
> foreign agent can soon clean up its pending registration list.  Since
> the FA has proved its identity to the HA, it could eventually infer by
> the lack of RREQs from the HA, even after retries by the MN, that the MN
> was not known to the home agent.
>
> Another possibility would be to assign a new error code for a RREQ that
> was purely for the purpose of notifying the FA that the mobile node was
> unknown.
> Then the FA would not forward this RREQ to the MN, but just expunge its
> pending registration entry.
>
> What do you think?
>
> Regards,
> Charlie P.
>
>
>
>   

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www.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: Tue, 30 Sep 2008 09:41:41 -0700

Hello folks,

There has been some intermittent discussion about how to
handle Code 132 in  a way that is both properly informative
and yet not so likely to reward behavior of malicious nodes
pestering the home agent.

I have prepared a new revision of rfc3344bis with the
following changes, reflecting the suggestions made on this
list during the last couple of months.

============================================

In section 3.7.2.2,

change:
  o  It MUST append the Foreign-Home Authentication Extension, if the
     foreign agent shares a mobility security association with the home
     agent.

to:
  o  If the foreign agent shares a mobility security association with
     the home agent, and the Request has lifetime != 0, then it MUST
     append the Foreign-Home Authentication Extension,

=============================================

In section 3.8.2.

change:
                                                                        
Otherwise
  (the home agent denies the Request), it SHOULD send a Registration
  Reply with an appropriate Code specifying the reason the Request was
  denied.

to:
                                                                        
Otherwise
  (the home agent has denied the Request), it SHOULD in most cases send
  a Registration Reply with an appropriate Code specifying the reason
  the Request was denied.

=============================================

In section 3.8.3,

change:
                                                 Otherwise (the home agent
  has denied the Request), it SHOULD send a Registration Reply with an
  appropriate Code specifying the reason the Request was denied.

to:
                                                  Otherwise (the home agent
  has denied the Request), it it SHOULD in most cases send a
  Registration Reply with an appropriate Code specifying the reason the
  Request was denied.

=============================================

In section 3.8.2.1.  Validity Checks

change:
                          If no authorization-enabling extension is 
found, or
      if the Authenticator is invalid, the home agent MUST reject the
      mobile node's registration and SHOULD send a Registration Reply
      to the mobile node with Code 131.  The home agent MUST then
      discard the Request and SHOULD log the error as a security
      exception.  If the home agent receives a Registration Request
      without a Mobile-Home Authentication extension from a Mobile Node
      that has a security association with this home agent, the home
      agent MUST discard the Mobile Node's Registration Request.

to:
                        If the home agent receives a Registration Request
      without a Mobile-Home Authentication extension from a Mobile Node
      that has a security association with this home agent, or if no
      authorization-enabling extension is found, the home agent MUST
      silently discard the Mobile Node's Registration Request.
      Otherwise, if the Authenticator is invalid, the home agent MUST
      reject the mobile node's registration; further action to be taken
      in this case depends upon whether the Request has a valid
      Foreign-Home authentication extension (see below).  If there is a
      valid Foreign-Home authentication extension, the home agent MUST
      send a Registration Reply with Code 131.  Otherwise, if there is
      no Foreign-Home security association, the home agent MAY send a
      Registration Reply to the mobile node with Code 131.  The home
      agent MUST then discard the Request and SHOULD log the error as a
      security exception.

Also, add new list item:
  d.  If the home agent and the foreign agent do not share a mobility
      security association, and the Registration contains a Foreign-
      Home Authentication Extension, the home agent MUST discard the
      Request and SHOULD log the error as a security exception.

=============================================

If there aren't any objections to this, I'll send it out a revised version
oif rfc3344bis soon.

Regards,
Charlie P.

PS. In my earlier email from August, I made a major typo.
     At the end of my message, I typed "RREQ" a couple of
     times when I meant "RREP".  Sorry 'bout that!