Subject: [MEXT] Potential new issues for rfc3775bis

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 04 Mar 2009 15:38:27 -0800

Hello folks,

During and after the last IETF meeting, there were several more
topics raised as potential issues to be addressed during the
refinement of rfc3775bis.  Here are the ones I have identified
from looking through the mail archives:

1. BU de-registration race condition, depending on exactly
    when the security information for the mobile node is discarded.

2. Malicious Router Advertisement can cause mobile node
    deregistration on foreign network

3. Additional specification about saving source address of
    packets containing the Alt-CoA option.

4. Relaxing the mandate on the use of IPsec (given RFC 4285)

On these, I think the following is reasonable:

1. Accept.
2. Accept.
3. Accept or deny, but indicate that no work is needed in rfc3775bis
    to solve the problem
4. Deny, since it is more work than was chartered for rfc3775bis.

I expect to bring these topics into discussion soon, during the
next IETF meeting in San Francisco

Comments are welcome, and I will use them as part of my
presentation on these potential issues.

Regards,
Charlie P.

---

From: [email-masked] (Arnaud Ebalard)
Date: Thu, 26 Mar 2009 10:48:54 +0100

Hi,

>    deregistration on foreign network

I was not in SF but expected this issue (2.) to raise some concerns and
discussions. I was told it was finally dropped at the end of the session
with the argument that it is considered a NDP issue. Don't hesitate to
correct me if that summary is incorrect.

AFAICT, NDP was known as an insecure mechanism (just like ARP is) when
RFC 3775 was written. The Home Link Detection mechanism specified in
section 11.5.4 of RFC 3775 is based on that insecure information.

Basically, when there is no protection (authentication, encryption) of
the data exchanged between the HA and the MN (via IPsec tunnel),
emission of RA with Home Prefix on a foreign network by an attacker
leads to a common DoS and the *already expected* ability for an
attacker to access traffic i.e. this not an additional issue.

But when data path is protected using IPsec in tunnel mode, using that
unprotected stimulus as a trigger to drop this IPsec protection may lead
to security issues. One may argue that:

- protection of data path using IPsec is not mandatory in 3775 in all
  cases (well, "If multicast group membership control protocols or
  stateful address autoconfiguration protocols are supported, payload
  data protection MUST be supported", and for HoTI "Such tunneling
  SHOULD employ IPsec ESP in tunnel mode between the home agent and the
  mobile node", ...)  
- dropping IPsec protection when back home is not specified in 3775 but
  was in section 4.2 of 3776:  "When the mobile node returns home and
  de-registers with the Home Agent, the tunnel between the home agent
  and the mobile node's care-of address is torn down." and is in section
  4.2 of RFC 4877: "The security policy entries, which were used for
  protecting tunneled traffic between the mobile node and the home
  agent, SHOULD be made inactive".

The conclusion could be that this is not a 3775 problem, but a 3776/4877
one. Anyway, I think it is a MIPv6 security issue which should be
considered, clarified and solved in the context of the WG. 

Marcelo and Julien, can you provide your chairs' thoughts on previous
paragraph?

Cheers,

a+