A few comments about some of the citations being proposed:
On 10/9/09 4:14 PM, "Charles Perkins" <charles.perkins at earthlink.net> wrote:
Considering the mechanism is implemented and such an interface needed to
support that, 3775bis could at least point MIGRATE doc given below as an
informational reference document. This clarifies the need and gives a
possible solution.
http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00
So that I can finish revising rfc3775bis before having to stop and read
that draft,
can you provide some suggested text for the proposed citation? I'll try
to read the
draft in the next few days understand your citation and text.
This reference does not add any value to 3775bis. It is more relevant in the
context of 3776 or 4877. Adding this reference even in the Informative
section is not required.
It should be stated here or in the "Security Considerations" section
that this procedure is insecure and may have security impact, as we rely
on basic ND and undergo associated threats. This is documented:
http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00
How about:
o Given the availability of the home prefix, the MN checks whether
or not the home prefix matches one of the prefixes received in the
RA. If it does, the MN concludes that it is connected to the home
link. Please see Section 15.10 for information regarding the
security vulnerability associated with this determination.
and,
15.10. Vulnerabilities from Neighbor Discovery
The ``Home Link Detection'' mechanism (Section 11.5.2) allows the MN
to detect when it is at home. When a MN detects it is at home, it is
expected to deregister, and also (if in use) to stop IPsec protection
for data traffic exchanged over the tunnel to its Home Agent.
Unfortunately, Neighbor Discovery is not a secure protocol. It is
possible that some networks may harbor malicious routing agents that
might advertise false information which would lead a mobile node to
erroneously determine that it had returned to its home network.
A draft [40] has been written that discusses the possible threats
and security impacts associated with the use of this insecure NDP-
based mechanism as a trigger to drop IPsec protection of data traffic
for the MN. It also provides some results on the implementation of
the attacks against an existing MIPv6 module. Possible solutions are
suggested.
This is a much larger change to 3775bis. I-D:
draft-ebalard-mext-hld-security-00 has not really been discussed in the MEXT
WG AFAICT and hence making this change based on this reference is not what I
believe is in the scope of the current revision of 3775bis.
If an when the MEXT WG agrees that the threats identified in the referenced
I-D are accepted, it is okay to make these changes.
-Basavaraj