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

From: Jari Arkko <[email-masked]>
Date: Wed, 05 Jul 2006 16:23:04 +0300

Francis,

I have reviewed this document. Please find my comments and
questions below.

In general, the document is in reasonable shape for something
to be published as Experimental (my current assumption), but I
found a number of issues below that I'd like you to correct before
we can take the document further. This means one new revision.
Some of the comments probably need some discussion as well.

Here are the comments:

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

>    -  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? If not, I would suggest deleting the part about it.

> 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? How is the policy / authorization
issue resolved?

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

>    Note that
>    some operators can not propose Mobile IPv6 based services knowing
>    that the Mobile IPv6 security is based on assumptions.

:-)

If you can write a specific problem statement, please do. If not, leave
it out.

(The assumptions include, for instance, that on-path attackers can
disturb your communications. They can already do so without Mobile
IPv6, too...)

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

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.

>    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? How are
the CGA parameters transported? Suggestion: if we can not provide
full details, leave this part to another document.

>    -  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? Note: if you only include mobility signaling then triangular
routing is not possible. 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. Is there some
vulnerability related to the use of Mobile IPv6 in this case?

>    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
not grant rights to use "any" mechanism. It should state that
its defining a specific new mechanism, not anything about other
mechanisms.

>    mobility signaling for routing optimizations.  The configuration

maybe "... for route optimization" (there's just one kind).

>    This document uses the "MUST", "SHOULD", "MAY", ..., key words
>    according to [RFC2119].  IKE terminology is copied from IKEv2
>    [IKEv2].

Please use the standard template keyword statement:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

>    send the packets via the home till a binding update is processed.

s/till/until/

>    Auxiliary
>    parameters MAY be transported in an Identification payload of type
>    ID_KEY_ID...

Too many dots.

--Jari

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Jul 2006 19:40:10 +0200

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.

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

   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,
   
=> in general in IPsec, we'd like to know and trust the entity at
the other end...

   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 (:-)...

   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.

   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.

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

   
=> it seems you are trying to read between the lines.

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

   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.

   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
   
=> there is possible pitfall in the policy configuration so IMHO
we had to document it.

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

Regards
   
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Jul 2006 23:53:14 +0200

Short second/higher level pass...

   Francis,
   
=> we are two authors (:-)...

A general comment: the idea is to take benefit of IPsec when IPsec
is already available, i.e., for many reasons IPsec should not be pushed
only to protect mobility. As RFC 4449, in special cases an alternative
to RO is used, in fact IMHO RFC 4449 and IPsec-CN are two faces of
the same concept so I don't understand why they should receive a very
different consideration...
To finish the main security concern against RO is MN impersonization
and solutions based on strong authentications will be always far
more secure than RR...

=> no, impersonation by an attacker at the right place in the path(s)
is a real (and first order) issue. The RR was proposed because there
is no general solution to this problem but you can't assume than
the limits of RO about security are acceptable by everybody.
So we have an explicit alternate mechanism (RFC 4449), another one
using the standard network layer security (CN-IPsec) and perhaps
will get something from the CGA & co stuff. BTW this was known at
the RFC 3775 time so provisions were made for further (at that time)
work...

   >    -  no care-of address test is required when ingress filtering can

=> note that ingress filtering and return routability check are two
versions of the same mechanism, in particular both share the same
limit (no defense against an attacker at the right place in the path)
The main difference is that ingress filtering is passive, which is better
when you can trust it is used at the right place, when RR is active,
so more expensive but doesn't rely on someone else's policy.
BTW in my new job we use labelization which makes ingress filtering
seems like a toy (:-)...
To finish the lack of ingress filtering general deployment is a major
(i.e., first order) threat against the Internet itself, so it is a minor
(i.e., second order) threat against mobility.

   >      as well as the support of real alternate care-of addresses.

=> this is the real reason I introduced the state cookie RR: at the
beginning I simply forbid real alternate care-ofs but it was not
very clear if they would be never needed...
To use it when it is not required is a concession to the indirect
flooding attack paranoia so I don't understand why you'd like to
reject it (or it is for a formal concern?)

=> I don't like the RFC 4449 to deal with the problem... My idea is
to provide an easy tool to perform the RR test when the CN believes
there can be a problem, i.e., not when ingress filtering is deployed,
not when the MN can be trusted, etc, i.e., not only the check is at
the initiative of the CN but the CN can choose its default policy.

=> suggestion: move it to a not normative appendix?

   >       using IPsec

=> two extra comments:
 - I've already seen cases where "there is IPsec" was changed into
 "now everything is safe so may be done", i.e., the pitfall is real.
 - a good security admin should understand the issue and just avoid
 IPsec for the only protection of mobility (i.e., as I've explained
 in the introduction of this message, the protection of IPsec is
 not enough as a reason to jump to IPsec).
   
   >    (cf. [RFC3775] Appendix 3 "New Authorization Methods").
   
=> I'll put a *may* to stress it without interfering with keywords.

   
=> if the standard template is required it should be a macro in xml2rfc!

Regards

---

From: Jari Arkko <[email-masked]>
Date: Thu, 06 Jul 2006 00:59:26 +0300

Francis,

>=> BTW I can't understand
FWIW, the arguments would have applied to RFC 4449 too
had it been my call, but it wasn't.

--Jari

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 6 Jul 2006 02:47:07 +0200

Hi Jari,

> => I leave this to my co-author who is an employee of an operator

I think I tried to explain the advantages of such a draft for an
operator in one of my previous emails :)

Do you want we clearly mention such motivations in the draft?

Best regards.

JMC.

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Thu, 6 Jul 2006 02:54:49 +0200

> => suggestion: move it to a not normative appendix?

draft-laganier-ike-ipv6-cga-01 may be cited but it is expired :(

Best regards.

JMC.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 06 Jul 2006 21:15:32 +0300

> draft-laganier-ike-ipv6-cga-01 may be cited but it is expired :(

Right. The goal should be that the cn-ipsec RFC is
either self-contained or points to other, already published
RFCs for its normative behaviour.

(And its often a good idea to not put many independent
things in the same RFC. You can always publish the next
RFC.)

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 06 Jul 2006 21:42:05 +0300

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 06 Jul 2006 21:42:05 +0300

> Do you want we clearly mention such motivations in the draft?

You should definately describe the security properties
of the method you are describing. It is often also useful
to describe differences to other, earlier methods. The
description needs to be explained in technical terms and
be complete and accurate, however.

--Jari

<[email-masked]>
Subject: Re: [Mip6] Re: AD review of draft-ietf-mip6-cn-ipsec
Cc: Francis Dupont <[email-masked]>,
	Mobile IPv6 Mailing List <[email-masked]>

> Do you want we clearly mention such motivations in the draft?

You should definately describe the security properties
of the method you are describing. It is often also useful
to describe differences to other, earlier methods. The
description needs to be explained in technical terms and
be complete and accurate, however.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sun, 09 Jul 2006 13:53:35 +0300

Hi Francis,

>and solutions based on strong authentications will be always far
It is not always a strictly ordered relationship. For instance,
RFC 4449 is more secure in terms of authenticating the
Binding Updates, but less secure in terms of  making it
possible for the mobile node to lie about its address.

>is a real (and first order) issue. 
>
This is true but you have to remember the limits of our
technology EVEN if you use things like RFC 4449. For instance,
on-path attackers will see your data packets. On-path attackers
will generally be able to DoS your connection by, e.g., dropping
packets. Or copy your packets elsewhere. Adding better security
for the mobility signaling helps protect the mobility signaling,
but it isn't always clear that it provides more protection if you
think about the entire system; Binding Updates can be secure
but you are still vulnerable for on-path attackers. What does
help is end-to-end protection of your traffic (but that's at least
partially an orthogonal issue).

>The RR was proposed because there
Right.

To conclude the discussion about the security properties, its
clear that there are security differences between cn-ipsec and
RR. The security of the cn-ipsec mechanism needs to be described
in the draft, obviously. And if you want you can also discuss the
relationship to RR. In both cases the description needs to be
accurate, complete, and formulated in technical terms. I think
we agree that changes and more text is needed, so perhaps it
would be best for you to write the next version and then we
can take another look.

>reject it (or it is for a formal concern?)
The concern I had was only formal at this stage. Your draft needs to be
self-contained
or contain references to existing RFCs (or to drafts that are known to
become
RFCs soon). Otherwise your draft would sit in the RFC Editor queue forever,
waiting for references to become stable.

>=> suggestion: move it to a not normative appendix?
I would like to see it either officially defined or dropped. Note: I
have not
reviewed the state cookie draft recently, so I don't know if it would bring
new technical issues to worry about. My initial reaction was that you
should drop the functionality and then publish later the cookie thing
as an extension.

> not enough as a reason to jump to IPsec).
Yes -- please explain these things in the document.

>=> I'll put a *may* to stress it without interfering with keywords.
OK.

>=> if the standard template is required it should be a macro in xml2rfc!
Perhaps, but our general policy is that you have to pass idnits before
getting through AD review phase.  The above is a part of the idnits check.

--Jari