Hi all,

I finally found time to come back to this document.
Sorry for the delay.

I like the new applicability statement and other
changes you made in the draft. However, there
are still some issues from my previous review
that were not addressed, including for instance
the normative references, negotiation of how
this mechanism is turned on, and a more detailed
explanation of the security implications of this
mechanism. Details later in this e-mail.

Also, as I went through the draft I wrote some
edits that would satisfy my review and let this
draft move forward. Feel free to use these
as a starting point or make your own edits;
they are provided as suggestions only:

http://www.arkko.com/reviews/mip6/cn-ipsec-03-edits.txt
http://www.arkko.com/reviews/mip6/cn-ipsec-03-edits-from-draft-ietf-mip6-cn-ipsec-03.diff.html

Technical:
>    -  when an alternate care-of address option is present and is not
>       checked using the state cookie mechanism [COOKIE], the alternate
>       care-of address MUST match the source address in the IP header or
>       the home address itself.  Any binding update which does not
>       fulfill this requirement MUST be rejected.
>    -  no care-of address test is required when ingress filtering can
>       reject fake care-of addresses from a rogue mobile node but a
>       correspondent node can use the return routability state cookie
>       procedure to get extra insurance as well as for the support of
>       real alternate care-of addresses.
We already talked about this...

I would suggest deleting the part about the cookie mechanism.
This allows your draft to become an RFC without this IMHO normative
reference. (And if/when you publish another RFC on the cookie
mechanism, its OK for that draft to update this RFC. And I am
willing to AD sponsor documents in this space. But I'd like to
do that on a document-by-document basis, not by approving
one document that points to all the others.)

In any case, my suggested edits contain a new
section about possible enhancements, with pointers
to some ideas. This would be OK.
>    When the home address is bound to a public key, for instance when the
>    home address is a Cryptographically Generated Addresses [RFC3972],
>    the strong authentication MAY be replaced by an address ownership
>    proof as described for instance in [IKECGA].
As above.

>    IPsec is far more secure than the return routability procedure, thus
>    it should be used where it is applicable.  So this document can
>    increase at least the overall security of Mobile IPv6.
This document should specify how IPsec is better or
different, not simply state its better.

My suggested edits have one attempt at such
a description.

Semi-technical:
>  In binding updates the new requirements are:
>    -  the H (home registration) and K (key management mobility
>       capability) bits MUST be cleared.
The former does not appear to be a new requirement. Suggest
deleting the entry, and stating later in the same section
"The use of the K (key management mobility capability)
bit with correspondent nodes is not defined. This bit
is always set to zero."

>    -  as ESP can only protect the payload, an alternate care-of address
>       option MUST be used in conjunction with ESP (cf. [RFC3775] section
>       11.7.1).
This is another requirement that is not new. Delete the
item.
>    -  "long" lifetime compatible with the IPsec policy (i.e., by default
>       up to the IPsec security association lifetime) MAY be granted.
Perhaps you should classify this as something else
than a new requirement, e.g., place it after the list
and formulate as:

"Note that a relatively "long" lifetime compatible with the IPsec policy
(i.e., by default up to the IPsec security association lifetime) MAY
be granted."
>    -  in order to avoid granting any extra privilege by a side effect of
>       using IPsec, the peers (i.e., the mobile and correspondent nodes)
>       may restrict the traffic selectors to the protection of mobility
>       signaling only.  This should be applied to any dubious cases,
>       including by default when security administration is known to be
>       too light.
I still do not understand this. Furthermore, it seems to
argue against the situation that you assumed in the
applicability statement. That is, you use this method
when you would be using IPsec anyway for some other
reason.

> When a packet carrying a home address option is protected by a
> >    suitable IPsec security association, the home address option SHOULD
> >    be considered valid.
>  
>
> I think there should be a discussion somewhere (perhaps Section 2)
> about the type of SA creation procedure and trust that is required
> to make the above decision. See RFC 4449 Section 2 first two bullet
> items for an example, and consider saying something about whether
> this mechanism is applicable with BTNS or opportunistic IPsec.
>
> The implications may also be different for triangular routing
> and route optimization. It seems that all we need for triangular
> routing is that the original address (the one that you send
> traffic back to) was used in the IKE exchange. That is, a dynamic
> SA is needed, but it can be of any type. For route optimization,
> we'd like to know and trust the entity at the other end.
>  
This comment from my previous review has not
been addressed.

> In binding updates the new requirements are:
>  
>
> I would like to understand what happens when the peers use RFC 3775
> while at the same time for other reasons use IPsec between themselves,
> and ONE (not both) support the mechanism specified here. How do they
> know what they should do? Is there a missing negotiation step somewhere?
>  
As above.

> If you cut away the state cookie reference (as suggested earlier),
> I would suggest that you include a statement similar to RFC 4449
> about the trust needed to take care-of addresses without verifying
> them.
As above.


Editorial:

> But any stronger mechanism (i.e., more secure than the
> return routability procedure) may be used, including of course IPsec
> (cf. [RFC3775] Appendix 3 "New Authorization Methods").
For readability, you should rewrite this as "This document
defines an alternative mechanism based on strong authentication
and IPsec."
>    The purpose of this document is not to replace the [RFC3775] return
>    routability procedure by the use of IPsec/IKE which has some
>    authentication requirements which make its universal deployment more
>    than unrealistic.
Again for readability, change to

   The purpose of this document is not to replace the [RFC3775] return
   routability procedure by the use of IPsec/IKE. It is unrealistic to
   expect credentials to be available for strong authentication between
   any pair of communication hosts.

Finally, the document should be checked for correct
capitalization of terms (such as message names) from
RFC 3775.

Jari


_______________________________________________
Mip6 mailing list
Mip6 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mip6