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

["Kent Leung (kleung)" <kleung at cisco.com>]

Hi Charlie.  Sorry for the delayed response.  I lost track of this issue
when my comment was left in my draft queue.

Anyways, I'm not sure how my quoted comment was interpreted as a "MAY"?
A response from the HA (when it has a FA-HA security association) to the
FA has been userful in deployments.  There isn't likely a DoS from FA.

I think the more relevant issue is with the MN-HA authentication
rejection.  The current text contains:

3.8.2.1:

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

I think this case warrants no response from the HA.  Actually, we should
say that HA MUST NOT send RRP when HA does not have the MN-HA security
association.  Nowadays, the MN-HA SA is coming from the AAA server.
MN-AAA authentication failure or other conditions result in
Access-Reject from the AAA server.  This leaves the HA without the MN-HA
SA and the RRP cannot be protected.  But in general, when an RRQ arrives
at the HA which does not have MN-HA SA for the NAI, the HA MUST NOT send
the RRP, IMHO.

Kent

-----Original Message-----
From: Ahmad Muhanna [mailto:amuhanna at nortel.com] 
Sent: Monday, June 02, 2008 12:59 PM
To: Charles E. Perkins; Mobile IPv4 Mailing List
Cc: George Tsirtsis; Kent Leung (kleung); Acee Lindem
Subject: RE: [Mip4] RFC 3344 - Home Agent Registration Code 132
-foreignagent failed authentication

Hi Charlie,

I am thinking the best option would be keeping the existing text + your
proposed text about denial-of-service. 
But I can live with your proposed option 3 too.

Thanks!

Regards,
Ahmad
 

> -----Original Message-----
> From: mip4-bounces at ietf.org [mailto:mip4-bounces at ietf.org] On Behalf 
> Of Charles E. Perkins
> Sent: Monday, June 02, 2008 1:05 PM
> To: Mobile IPv4 Mailing List
> Cc: George Tsirtsis; Kent Leung (kleung); Acee Lindem
> Subject: Re: [Mip4] RFC 3344 - Home Agent Registration Code
> 132 -foreignagent failed authentication
> 
> 
> Hello folks,
> 
> There is one outstanding issue with rfc3344bis, having to do with Home

> Agent Registration Code 132 (foreign agent failed authentication).
> 
> Discussion from a couple of months ago was inconclusive, but was 
> inserted as Ticket #6 (new defect) [see 
> http://tools.ietf.org/wg/mip4/trac/ticket/6].
> 
> Currently, rfc3344bis recommends that a home agent return code #132 
> when a foreign agent, that has a security association with the home 
> agent, does not supply a valid HA-FA authentication extension.
> 
> Very briefly, the problem is that this could conceivably be exploited 
> for a denial-of-service attack, and it goes against what is commonly 
> done in other protocols.
> 
> Here are some proposals for remedying this problem.
> 
> 1) do nothing
> 
> 2) Change "SHOULD" to "MAY" in:
>        "   ...     the home agent MUST reject the mobile node's
>        registration and SHOULD send a Registration Reply to the mobile
>        node with Code 132."
> 
> 3) Make the change in (2), and add an explanation so that
>    implementors will not send the Registration Reply if there
>    seems to be evidence that a denial-of-service attack is
>    underway.
> 
> I am in favor of (3).  Here is the new text I would propose to add.
>        "           ...     When there are indications that this
>        status report is being solicited as part of a denial-of-service
>        attack, the Registration Reply with Code 132 SHOULD NOT be
>        returned to the foreign agent."
> 
> Here is some more relevant discussion on the matter:
> 
> On Thu, Apr 10, 2008 at 11:32 PM, Kent Leung (kleung) 
> <kleung at cisco.com>
> wrote:
>  >          .....                                           default
>  >  implementation adhering to RFC language in deployment for years 
> and  >  experience has shown usefulness of reply and lack of FA DoS 
> attacks.
> 
> In my understanding, this is exactly the sort of experience that would

> indicate the use of "MAY" for such a feature.
> I hope that responsible vendors would recognize such value in 
> providing the implementation of the MAY, given the warning about DoS, 
> and in so doing best serve the needs of their customers in this 
> matter.
> 
> ===============================================================
> 
> As part of the discussion, another proposal was made to notify the FA 
> when MN-HA authentication fails.
> This makes a lot of sense to me, but it is not closely related to the 
> technical problem under discussion in Ticket #6.  I'm in favor of 
> moving that discussion _out_ of the scope of Ticket #6, so that we can

> more easily focus on the technical resolution of the problem with 
> reporting status #132.  If there is interest in re-opening that 
> discussion, please submit a new ticket with a summary of the proposal 
> (or, ask me to do so).
> 
> I expect that I could write up some text for this new feature sometime

> this week if desired.
> 
> ===============================================================
> 
> One way or the other, I hope we can resolve these relatively minor 
> issues and get rfc3344bis on track for shepherding before the meeting 
> in Dublin.
> 
> 
> Regards,
> Charlie P.
> 
> --
> Mip4 mailing list: Mip4 at ietf.org
>     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/
> 
--
Mip4 mailing list: Mip4 at ietf.org
    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/