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

From: "Kent Leung (kleung)" <[email-masked]>
Date: Fri, 22 Aug 2008 07:45:44 -0700

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:[email-masked]] 
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: [email-masked] [mailto:[email-masked]] 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) 
> <[email-masked]>
> 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: [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/
> 
--
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: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 22 Aug 2008 12:12:50 -0500

Hi Kent,

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

[Ahmad]
Sure, any behaving node will not cause a DoS attack. The problem is from
an attacker claiming that it is an honest FA. I am not trying to open
this topic for discussion again, but I am strictly commenting on your
above statement.

Cheers!
Ahmad

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

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 25 Aug 2008 12:23:50 -0700

Hi Ahmad.  Yes, a similar remark was made in this thread already.
Anyways, just wanted to point out this issue is more applicable to MHAE.

Kent 

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Friday, August 22, 2008 10:13 AM
To: Kent Leung (kleung); Charles E. Perkins; Mobile IPv4 Mailing List
Cc: George Tsirtsis; Acee Lindem
Subject: RE: [Mip4] RFC 3344 - Home Agent Registration Code 132

Hi Kent,

[Ahmad]

Cheers!
Ahmad

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 25 Aug 2008 13:32:10 -0700

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.

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 25 Aug 2008 15:15:44 -0700

Hi Charlie.  Thx for factoring in the existence of SA in handling the
cases.  I think the actions for the the cases below are reasonable.
Just one tweak though.  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'm ok with MUST if other folks feel strongly using this language vs.
SHOULD for the reasons above.

Kent 

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

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.