Subject: RE: [Ipsec] IKEv2 needs a "policy usage mode"...

From: "Michael Roe" <[email-masked]>
Date: Fri, 11 Feb 2005 17:32:29 -0000

> Markku Savela writes:
> > I will have to reread the 2401bis and try to find where it 
> says that a
> > policy like
> > 
> >   (remoteport=1 and localport=1) or (remoteport=2 and localport=2)
> > 
> > is forbidden. Above is not negotiable in IKEv2.

Tero Kivinen replies:
> It is negotiable in IKE, but not as with one SA in single create child
> sa exchange.

I agree with Markku that 2401bis allows SPD entries that IKEv2 is
unable to represent in a single create child SA exchange. These
entries can often arise as a result of decorrelating the SPD
(which means that this issue is connected with the other thread,
on whether the ordered or the decorrelated SPD entry is used
to create the traffic selectors).

As Tero says, you can always split the entry up into multiple 
security associations. This leaks some information about the
plaintext to the attacker, because the attacker can see which
SA is used. In many cases, this may not matter.

Here's an example, which I hope I've got right:

local addr | local port | remote addr | remote port | action
X         TCP    *            *            25          APPLY(3DES)
Y         TCP    *            *            80          APPLY(3DES)
X or Y    TCP    *            *             *          APPLY(AES)

The third entry decorrelates to:
local addr | local port | remote addr | remote port | action
X               *            *            1-24      }
X               *            *            26-MAX    }
Y               *            *            1-79      } APPLY(AES)
Y               *            *            81-MAX    }

This can't be represented in a single create-child-sa, but it
can be represented in two:

1) Tsi = (TCP, X, ANY)
   Tsr = (TCP, ANY, 1-24),(TCP, ANY, 26-MAX)

2) Tsi = (TCP, Y, ANY)
   Tsr = (TCP, ANY, 1-79),(TCP, ANY, 81-MAX)

The effect of this is that you get two security associations
where you might have expected one, and an eavesdropper on the
link can distinguish packets from X from packets from Y.

Mike

PS. As far as I can tell, this problem didn't occur with IKEv1 and
IPsecv1
because RFC2401 says this:

   NOTE: The correct "matching" policy will not necessarily
   be the first inbound policy found.  If the check in (4)
   fails, steps (3) and (4) are repeated until all policy
   entries have been checked or until the check succeeds.

So in IKEv1, it was OK to negotiate an SA with 
local addr = X or Y, action = APPLY(AES)
and an incoming packet on this SA from port 25 to host
X would be accepted, even though there was a higher precedence
SPD entry that says this packet should be protected with 3DES.

In the 2401bis, we don't have this note, and this packet will
get dropped.

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

---

From: Markku Savela <[email-masked]>
Date: Fri, 11 Feb 2005 20:22:56 +0200

> From: "Michael Roe" <[email-masked]>

> SPD entry that says this packet should be protected with 3DES.

Just to set record right, thats not quite true. Even with old
IKEv1/2401, if policy said port 25 is to be protected with 3DES, such
packet arriving viad AES SA would not be accepted. The old IPSec was
not that broken!

There might have been broken implementations! The NOTE you referred
was supposed to tell the implementers not to fall into that trap.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Feb 2005 12:51:18 -0500

Folks,

Let me try to characterize what I think are the options for IKE 
traffic selector negotiation, for v1 vs. v2 and 2401 vs. 2401bis. I'm 
concerned that we have differing views of this, and frankly, I'm 
confused. I have to admit that I am not an IKE expert, especially 
with regard to IKE v1, where there was a big mismatch with the SPD. 
Still, let me try to explore the situation, to see if we can get a 
clearer understanding of what should happen.

Under 2401 and IKE v1:
	- (no decorrelation available)
	- initiator sends local SPD entry that matches outbound traffic,
	  based on linear search of local SPD, as the proposal
	- initiator does not send packet headers that triggered SA 
establishment
	- responder matches received, remote SPD entry against local SPD,
           based on an exact match
	- if successful, a pair of SAs is established, in the SAD at each end
         - inbound traffic received via an SA is matched against the SPD, and
	  to a check is made that the SPD entry matches the SAD in question.
	  this (slow) procedure is employed to ensure that the traffic is
	  consistent with the SPD at a responder, since the choice of
	  the matching SPD entry based on the IKE exchange might have selected
	  and entry that is not the first match for specific traffic.
	- outbound traffic from the responder, consistent with the SAD entry
	  created by IKE, may match a different rule at the responder (because
	  there is no caching) and thus trigger a new SA, rather than flowing
           over the extant SA, due to the imprecision of the procedure.

Under 2401bis and IKE v2:
	- decorrelation is an option, though not mandated. let's start
	  the analysis w/o assuming use of decorrelation
	- IKE v2 transports the headers of the packet that triggered the SA
	  to the responder, as a aide in selecting the right SPD entry
	- at the responder, these headers can be matched against the local
	  SPD (ordered search, since we assume no decorrelation here) to find
	  the entry that the responder would use to create an SA based
	- given this new feature, the receiver should match the selected SPD
	  entry against the proposal sent by the initiator, and "narrow" the
	  response. the narrowed response should be the intersection of the
	  local and remote SPD entries, thus ensuring that traffic sent in both
	  directions will be accepted at each end.
	- under 2401bis, traffic checking at a receiver is based only on the
	  SAD entry, with no reference to the SPD. this procedure ensures that
	  such checking suffices, because of the way the responder's SPD
	  entry was selected, and the way the responder narrowed the response.

so, what happens differently if one tries to take advantage of decorrelation?

	- 2401bis says that one should send the original, correlated SPD entry
	  in the IKE exchange. the reasoning is that one wants decorrelation
	  to not create multiple SAs where one would have been created if
	  correlation were not performed. thus the description above matches
	  what 2401bis says happens re the IKE exchange, with the added
	  detail that the SAD entries at each end will be decorrelated, if
	  each end used a decorrelated SPD. this latter detail arises because
	  2401bis calls for pulling in all of the decorrelated 
entries resulting
	  from the initial SPD entry when the SAD entry is created. 2401bis did
	  not say anything about narrowing, but if the returned proposal is
	  narrowed, then it could be compared to the decorrelated SPD entries
	  first, to yield an SAD entry that is a subset of all the decorrelated
	  ones based on the original SPD entry.
	- if the responder has a decorrelated SPD, the lookup based on the
	  transmitted packet header can make use of the decorrelation. but
	  2401bis implies (?) responding with the original SPD entry. again, no
	  mention of narrowing is present, but the procedure described
	  above could be used to narrow the SAD entries created.
	- because the responder narrows its proposal, and because the packet
	  headers are sent along with the proposal, there should be fewer
	  opportunities for mismatches between the peers re acceptable traffic
	  flowing over the SAs.

the question we have been discussing is whether the originator should 
send just the decorrelated entry, vs. the original entry.
	- If a decorrelated entry is sent, the responder will generally see a
	  much more restrictive IKE proposal. if the responder has decorrelated
	  his SPD, a match against the packet headers may find a similarly
	  narrow local SPD entry. the result may accomplish the 
narrowing called
	  for in IKE v2.  however, this behavior could cause more SAs to be
	  created than for a correlated SPD, even when there were identical
	  correlated entries at each end. this does not seem to be the right
	  response.
	- one could send the full set of decorrelated entries, instead of the
	  original entry. this would prevent unintended creation of additional
	  SAs. also, a recipient who has a decorrelated SPD can match 
each entry
	  at his end with the proposals from the responder. this might make the
	  narrowing process easier as well, and still prevent creation of
	  extra SAs.
	- if the responder does not have a decorrelated SPD, it can still
	  do the ordered SPD lookup based on the packet headers and then match
	  the resulting SPD entry against the set of decorrelated proposals the
	  initiator sent. the resulting narrowed proposal should represent

so, to avoid creation of extra SAs, we ought not send just a 
decorrelated entry as a proposal, but we could choose to send the set 
of linked, decorrelated entries to a peer to help in the narrowing 
process, especially if the peer has a decorrelated SPD.

Does this discussions help?

Steve

---

From: Markku Savela <[email-masked]>
Date: Tue, 15 Feb 2005 23:02:35 +0200

Let me tackle one point first...

> From: Stephen Kent <[email-masked]>

> 	  entry was selected, and the way the responder narrowed the response.

No, YOU STILL have to check the policy, even if packet matched the
narrowed responce! Consider (there is even no narrowing required)

Initiator policy:

 localport=25 -> A1
 remoteport=80 -> A2

Responder policy:

 localport=80 -> A2

The packet from initiator: localport=1234 remoteport=80. This results
an SA pair with only port=80 as selector (other port any).

Now, he responder can validly send packet with (localport=80,
remoteport=25) using A2. And if the initiator only checked he SA
selector, it would pass. But this not correct, the port 25 on receiver
is supposed to have some other security (A1)!

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Feb 2005 12:20:46 +0200

>            over the extant SA, due to the imprecision of the procedure.

Yes, I think that is quite correct interpretation. The key points
there is:

1) Everything works as long as the SPD in both end is exactly same.
2) If there is any changes in the SPD then either the negotiation will
   fail (no exact match found for entry from the recipients SPD for
   the initiators proposed SPD entry), or the traffic will disappear
   in the black hole (traffic coming out from SA is dropped as it does
   not match the local SPD). 

> 	  entry was selected, and the way the responder narrowed the response.

I do not think the last point is valid, regardless of narrowing, or at
least if you do it that way you will allow traffic not matching SPD to
pass through.

Lets take example:

Host A has SPD saying 10.0.0.0-10.0.0.255 as a selector (I assume we
have only one selector and that is one IPv4 address, to simplify the
example). The SPD says use AES for that

Host B has SPD saying that for selector 10.0.0.42 use 3DES, and lower
priority rule says that 10.0.0.0-10.0.0.255 can use either AES or
3DES.

Now when A makes SA for host 10.0.0.1 it will create SA having
seletors of 10.0.0.0-10.0.0.255 using AES, and B will accept that. Now
if A tries to send packets to 10.0.0.42 using that SA if B only checks
the SAD having 10.0.0.0-10.0.0.255 / AES it will accept the packets,
even when there is higher priority rule saying that traffic must use
3DES. 

> 	  correlation were not performed. 

I do not think that is valid to say it would create multiple SAs even
when decorrelated versions are used (protocol holes are an exception).
As the decorrelated SPD entry can still be (in most cases) be
presented as one traffic selector set, meaning it will still be one
SA.

Exception to this is when we need to decorrelate protocols, i.e. when
we have policy which says:

1) protocol:TCP use AES
2) protocol:any use 3DES

The decorrelated SPD will be:

1) protocol:TCP(6) use AES
2) protocol:1-5,7-255 use 3DES

and that second selector cannot really be expressed in the IKEV2
traffic selector (or it can, but it will expand to traffic selector
having 254 items). The best way in those kind of policies in IKE is to
expand it rule where we use SA per protocol (i.e. put the PFP on for
protocol).

I think it should send the decorrelated SPD entry if it is using
decorrelated policies, as otherwise we end up problems if the policies
do not match in both ends.

> thus the description above matches
> 	  from the initial SPD entry when the SAD entry is created.

If the SPDs are not identical in both ends the SAD entry created by
the above rules can be different in both ends. I.e. if we take my
first example with 10.0.0.0-10.0.0.255 but the host B initiating. The
B's second entry is decorrelated to 10.0.0.0-10.0.0.41,
10.0.0.43-10.0.0.255. When B initiates to the A for packet 10.0.0.1,
and if it takes the original SPD entry it will send
10.0.0.0-10.0.0.255 / AES to the host A, they will end up problems.
If B installs the decorreclated version to the SAD after the exchange,
then A and B has different selectors for the SA, and if B installs the
original SPD entry then that SAD entry will not follow his own policy.

> 2401bis did

But in that case the SAD entry in both ends will be different, as
initiator will modify selectors after they have been negotiated with
the other end.

> 	  above could be used to narrow the SAD entries created.

I think we cannot use the original SPD entry when responding, if
decorrelated policies are used. 

> 	  opportunities for mismatches between the peers re acceptable traffic

As long as either end modifies the SAD entries without telling the
other end there will be mismatch in the final selectors for the SA.
I.e. if original SPD entries are used and then they are modified when
installing them to SAD then we end up problems if the SPDs in hosts
are different.

> 	  correlated entries at each end. this does not seem to be the right

Why would it cause more SAs to be created? The decorrelated entry can
be expressed as one traffic selector in the IKE, thus we can create
one SA for it. And when the responder is calculating intersection
based on his own decorrelated SPD and the other ends policy it should
include all possible ranges which are allowed by both policies. If
some ranges are left out they are left out because they are not
allowed by the policy.

> 	  narrowing process easier as well, and still prevent creation of

Oh, when you were talking about the decorrelated SPD entry you were
only talking about one specific entry there? I was always assuming
that decorrelated SPD entry, is actually set of entries generated from
the original SPD, i.e. the "full set of decorrelated entries" you
mention here.

Now I understand your comments before. So read all the above text so
that decorrelated SPD entry ==> "full set of decorrelated entries
created from one original SPD entry".  

> process, especially if the peer has a decorrelated SPD.

Yes. And I think that is only way to really get things working when
the policies are different. 

> Does this discussions help?

Yes... 
-- 
[email-masked]