[Mip6] Re: AD review of draft-ietf-mip6-cn-ipsec

[Francis Dupont <[e-mail]>]

Some short answers inline:

   In general, the document is in reasonable shape for something
   to be published as Experimental (my current assumption),

=> I completely disagree about the experimental. BTW I can't understand
why your arguments don't apply to RFC 4449 which is standard track.

   >    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

=> by "suitable" I mean an IPsec SA which provides the right thing,
for instance full origin authentication. The way it is established
and can be trusted is more an IKE issue, i.e., if you can establish
untrustable SAs you are in trouble with and without MIPv6.

   to make the above decision. See RFC 4449 Section 2 first two bullet
   items for an example,

=> these points are supposed to be already handled by IPsec.

   and consider saying something about whether
   this mechanism is applicable with BTNS or opportunistic IPsec.
   
=> opportunistic IPsec is supposed to be safe, BTNS is a problem
(this is why many people raise a concern about possible confusion
between BTNS and 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.

=> no, IKE uses strong mutual authentication and has nothing to do
with the return routability madness.

   That is, a dynamic SA is needed, but it can be of any type.

=> type? I can't see your idea.

   For route optimization,
   we'd like to know and trust the entity at the other end.
   
=> in general in IPsec, we'd like to know and trust the entity at
the other end...

   >    -  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.
   
   This makes [cookie] a normative reference in my opinion. Is that
   being published?

=> [cookie] is a good candidate for an experimental document. I am afraid
I am a bit late to refresh it but it will be possible next week...

   If not, I would suggest deleting the part about it.
   
=> I already moved many things from IPsec-CN to [cookie], I can finish
this (:-)...

   > In special circumstances where the home
   >    address can be unusable, IKE MUST be run over a care-of address but
   >    this has many known drawbacks:
   >    -  a care-of address can not be used for authentication nor
   >       authorization.
   >    -  security associations do not survive handoffs.
   >    -  the establishment of transport mode IPsec security association
   >       using the home address as the mobile node traffic selector raises
   >       a policy / authorization issue.
   
   I agree with the above, but I worry what this implies. Can you document
   what the special circumstances are?

=> when the home address is not routable (i.e., the home address is not
a real address).

   How is the policy / authorization issue resolved?

=> this policy / authorization issue is from RFC 2409:


   The identities of the SAs negotiated in Quick Mode are implicitly
   assumed to be the IP addresses of the ISAKMP peers, without any
   implied constraints on the protocol or port numbers allowed, unless
   client identifiers are specified in Quick Mode.  If ISAKMP is acting
   as a client negotiator on behalf of another party, the identities of
   the parties MUST be passed as IDci and then IDcr.  Local policy will
   dictate whether the proposals are acceptable for the identities
   specified.

So the solution is an explicit setup to get at least ownership of
the home address. Of course the usual way, put it in a SubjectAltName
of the MN certificate, is only half of the solution because one could
like to check if the address is the one IKE runs over, and it is not
the case... My intention here is to raise the point but to given
the burden to solve it to the special circumstances mechanisms.
   
   > 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?

=> if the MN doesn't support it, it'll just loose a faster and stronger
way to do RO. If the CN doesn't support it, it'll reject the BU. There
is no ambiguous error case. BTW I am afraid there can be a bidding down
attack...

   Is there a missing negotiation step somewhere?
   
=> There is no standardized way to manage IPsec polices and what one
can do with IPsec SAs is IMHO exactly in the scope of IPsec policies.

   >    Note that
   >    some operators can not propose Mobile IPv6 based services knowing
   >    that the Mobile IPv6 security is based on assumptions.
   
=> I leave this to my co-author who is an employee of an operator
which has this position.
   
   >    -  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 the support of real
   >       alternate care-of addresses.
   
   Ingress filtering helps only when it is deployed. But you already knew
   that we have agreed to disagree on that point.
   
=> it seems you are trying to read between the lines.

   If you cut away the state cookie reference (as suggested earlier),

=> IMHO it (the state cookie stuff) is an useful mechanism when
there is no care-of address test and someone wants a return routability
check. So I prefer to find a way to keep it.

   >    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.  In this case the public key MAY be transported by IKE from
   >    the mobile node to the correspondent node, for instance in a
   >    Certificate payload of type 11 ([IKEv2] section 3.6).  Auxiliary
   >    parameters MAY be transported in an Identification payload of type
   >    ID_KEY_ID...
   
   This would work, but I worry about the lack of details here. How would
   the peers know they are using RFC 3972 to authenticate in IKE?

=> because it is in the PAD (RFC 4301 section 4.4.3).

   How are the CGA parameters transported?

=> ID_KEY_ID (RFC 4306 section 3.5):
            An opaque octet stream which may be used to pass vendor-
            specific information necessary to do certain proprietary
            types of identification.

   Suggestion: if we can not provide
   full details, leave this part to another document.
   
=> what I propose works, it is just not the only way to do it.

   >    -  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 am not sure I follow. Can the specific vulnerability be documented
   here?

=> as it is written: you grant the authorization to use IPsec to protect
mobility and someone tries to apply IPsec to something else. And
the solution is to constraint the scope.

   Note: if you only include mobility signaling then triangular
   routing is not possible.

=> yes and this is a good example of the vulnerability: you try to
authorize the triangular routing for a traffic and by a side effect
you give unexpected/unwanted security property to this traffic.

   And it would be surprising if regular payload
   traffic protected by IPsec would caused privilege elevation, assuming
   the peers were OK with doing IPsec for their traffic.

=> no, the problem is when they are OK with doing IPsec for mobility
and IPsec is spread to the traffic itself.

   Is there some
   vulnerability related to the use of Mobile IPv6 in this case?
   
=> there is possible pitfall in the policy configuration so IMHO
we had to document it.

   >    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").
   
   I'm troubled by the "MAY" in this context. It does not appear
   to be a direct quote from anywhere, and this document should

=> the Appendixes are not normative so they don't include uppercase
keywords even the text is pretty clear. Is it your concern?

   not grant rights to use "any" mechanism. It should state that
   its defining a specific new mechanism, not anything about other
   mechanisms.
   
Regards
   
[e-mail]

_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6