Subject: Re: [IPsec] Reopening issue #12

From: Stephen Kent <[email-masked]>
Date: Sat, 2 May 2009 13:01:47 -0400

At 2:18 PM +0300 4/29/09, Tero Kivinen wrote:
>...
>
>In most case I would not expect Bob to create the old SA that way at
>all, as it would require it to combine two SPD rules together when
>accepting such entry. As the SPD entries are ordered list that would
>mean it was combining two entries which had different locations in the
>list, and I am not sure if combining two SPD entries when creating SA
>is actually allowed by the RFC4301.

4301 does not have any notion of "combining" SPD entries. As you 
note, the SPD is ordered, so whichever SPD entry matches and is 
encountered first is used.

Steve

---

From: <[email-masked]>
Date: Mon, 4 May 2009 14:29:39 +0200

Tero Kivinen wrote:

> > But now Bob cannot meet the requirement "new SA MUST NOT be narrower
> > than the old one", because it would violate his policy.
> 
> This depends which happens first, algorithm selection or narrowing. In
> most cases the first thing happens that traffic selectors are used to
> find suitable policy entry from SPD and then algorithms and traffic
> selectors are selected based on that.
> 

Well, nothing in RFC 4301 requires implementing the SPD internally as
an ordered list of entries; some kind of tree or associative array
data structure could work, too. The requirement for ordered list of
entries applies to the management UI, not the internals.

So I think an implementation that treats the following two policies
equivalently *is* allowed by RFC 4301 and 4306:

Policy A:
   traffic on UDP ports 1000 MUST use ESP w/AES
   traffic on UDP ports 1001 MUST use ESP w/AES

Policy B:
   traffic on UDP ports 1000-1001 MUST use ESP w/AES

> In general I do not expect implementations ever to do that, and if
> they happen to do that then they should also have code that
> understands the rekeying requirements, meaning they must select those
> same SPD entries for the rekeying and also use the policy restrictions
> from them to select algorithms for the rekey.
> 
> Meaning that, in your example the Bob can still pick same SA traffic
> selectors (UDP ports 1000-1999) and select algorithm which is
> acceptable for him (AES). He cannot select 3DES even when that is his
> preferred algorithm for one part of the range.
> 
> > So, I think the current text in 2.9.2 *does* assume that encryption
> > algorithm negotiation behaves differently when rekeying (and IMHO
> > this requirement is not in RFC 4306).
> 
> I do not find anything from 2.9.2 which would indicate that it assumes
> algorithms to stay same (which was the actual question of b).
> 
> It does require algorithm selection to work so it does result in
> algorithm that is acceptable for the whole old SA.

My main concern was whether this (new SA MUST NOT be narrower than old
one, but MAY be wider) is a new requirement compared to RFC 4306...

Best regards,
Pasi

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 May 2009 08:38:20 -0400

Pasi,

It is true that 4301 does not require that the SPD be implemented as 
an order list of entries. In fact, 4301 specifically adopts a 
de-correlated SPD model to explain the details of processing.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 May 2009 13:47:02 +0300

>    traffic on UDP ports 1000-1001 MUST use ESP w/AES

Perhaps, but it should not consider following policies equivalently:

Policy A:
   traffic on UDP ports 1000 MUST use ESP w/AES or w/3DES
   traffic on UDP ports 1001 MUST use ESP w/AES

Policy B:

meaning that it should delete the Child SA immediately when the one of
the policy entries in the policy A was changed to include 2
algorithms.

> one, but MAY be wider) is a new requirement compared to RFC 4306...

Does that really matter even if it is new requirement or not?

Is there something wrong with that requirement, i.e what is the reason
why we should not add that MUST NOT in document?

As we have already argued quite long about whether it is new
requirement or not, that really says that there was nothing that said
it was clearly allowed before. I.e. mostly RFC4306 was silent about
the issue, and by interpreting other MUSTs in RFC4301 and RFC4306 I
think we can derive same "MUST NOT" requirement we added there. 

I.e. we are just clarifying RFC4306 to explicitly say something that
could have beeen derived from very complex text combination from
RFC4301 and RFC4306.

I do not think we really must add that text, as I still think it can
be derived from other part of specifications, but I think it would
make it easier to understand how rekeying child SA is supposed to
work. 
-- 
[email-masked]

---

From: <[email-masked]>
Date: Tue, 5 May 2009 13:42:21 +0200

Tero Kivinen wrote:

> > My main concern was whether this (new SA MUST NOT be narrower than
> > old one, but MAY be wider) is a new requirement compared to RFC
> > 4306...
> 

Since we're not creating IKEv2.1 here, IMHO we need to be somewhat
conservative about adding new requirements. (But less
conservative when we're just clarifying existing ones.)

> make it easier to understand how rekeying child SA is supposed to

I agree that rekeying is currently not very easy to understand.  But
e.g. early drafts of ikev2-clarifications (-00 and -01) included some
text wondering about what exactly N(REKEY_SA) means (that is, what is
different when you do/don't include REKEY_SA in CREATE_CHILD_SA
exchange), and all of those reasons (which I think you also
commented back then) would IMHO allow the new SA to be narrower
than the old (even when N(REKEY_SA) is included)...
 
Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 May 2009 16:01:19 +0300

> than the old (even when N(REKEY_SA) is included)...

I originally also tought so, i.e. that is the reason this issue is
here in the first place. I.e. if the narrower traffic selectors are
allowed, then we MUST also have traffic selectors from the triggering
packet.

Then other people convinced me that if there would be reason for the
rekeyed SA to have narrower traffic selectors that are currently used,
then the SA would have been already deleted because it would have been
against policy, thus such situation cannot ever happen.

Check the original ticket description
(http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/12?version=1#L1).

I do not really have strong opinion which way to go, but we either
needs to make sure there is the triggering packet traffic selectors
(which might be problematic if SA was rekeyed because of time) and the
rekey can narrow down traffic selectors. Or we assume that narrowing
case cannot happen, as the SAs were already deleted before they were
rekeyed in such situations, and we can say that traffic selectors MUST
NOT narrow down.
-- 
[email-masked]

---

From: Dan McDonald <[email-masked]>
Date: Tue, 5 May 2009 09:46:35 -0400

On Tue, May 05, 2009 at 04:01:19PM +0300, Tero Kivinen wrote:

<SNIP!>

> rekeyed in such situations, and we can say that traffic selectors MUST

Let's assume the worst-case behavior and see what happens:

	- An SA requires renewal due to time (e.g. a PF_KEY *SOFT lifetime*
          expiration), and it does not contain original-triggering-packet
          information.  So an initiator just sends the selectors.  Let's say
          it's some sort of remote-port-only protection:

		TSi = 0.0.0.0-255.255.255.255, proto any, port any
		TSr = 0.0.0.0-255.255.255.255, proto TCP, port 2112

	- If the existing SA selector set matches or is a subset of the
          peer's SPD TS set, life is good.

	- If the responder now has a more narrow set than the expiring SA's
          selectors, (say some remote-peer's traffic for port 2112 is now
          treated differently) the responder can send TS_UNACCEPTABLE to an
          overly broad set of TSes.

	- The rekey then fails, and then the initiator's SA actually
          disappears due to time (e.g. a PF_KEY *HARD lifetime* expiration).
          The initiator tries again with no SA available, and it is treated
          like a brand-new negotiation (where triggering packet information
          is more readily available).

If we go with "assume that the narrowing case cannot happen", even the above
worst-case behavior will continue to work, so long as the responder does the
right thing and rejects rekeying if the proposed traffic selectors are too
broad for its policy.

I would lean toward "assume that the narrowing case cannot happen", because
if the narrowing case DOES happen, then even if SAs are still lying around,
they can expire and negotiations can begin from scratch.  It is much harder
to include the triggering packet's data all of the time, because if an SA
shared by many potential triggering packets, a time-expired renegotiation
CANNOT happen.

Dan

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2009 17:11:39 -0400

Dan McDonald described a worse case scenario.
It had the advantage that communication that could continue did
continue.  It had the disadvantage that the traffic to port 2112
got delayed because we needed the packet contents to get the policy
right.  This is bad due to the delay.

>           overly broad set of TSes.

that the responder change it's policy slightly.  As long as the
responder does not change it's policy again, I think that subsequent
rekeys may be fine.

It's nice that the responder can change its policy to a policy that
might in fact be a bit contradictory, yet communication continues.

(If the initiator sent packets through the old SA that the responder's
new policy does not allow, it may be able to drop those packets as being
from the wrong SA, so the responder does not need to be overly paranoid
and drop all SAs when it's policy changes.  Whether this happens in
practice depends a bit upon how the details of tunnel exit checks are done)

{ps: I am using gmane.org to read the list via NNTP. These last three
emails elicited a request to confirm from core3.amsl.com, which I think
all the gmane.org people saw. I confirmed, but my emails did not show 
up, so I am resending via SMTP instead of NNTP Post. My appologies if 
this breaks the threading.}

---

From: <[email-masked]>
Date: Fri, 8 May 2009 13:05:25 +0200

> against policy, thus such situation cannot ever happen.

Hmm... but it may mean that a narrowing algorithm that takes as inputs
the proposed TSi/TSr and your own policy isn't sufficient any more.
The algorithm also needs to consider the old SA.

If the original CREATE_CHILD_SA request also included the selectors
from the triggering packet, and the responder had multiple possible
subsets it could narrow to, it picked a subset that included the
triggering packet. When rekeying, the triggering packet isn't there
necessarily, but the responder still needs to pick the *same* subset
(and not one of the other acceptable subsets).

Best regards,
Pasi

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 8 May 2009 15:00:22 +0300

> The algorithm also needs to consider the old SA.

Only if your old SAs selectors are not based on one SPD rule. If you
do not combine multiple SPD entries and share an SA with them, then
you can simply take same (decorrelated) SPD entry and TSi/TSr and end
up with the exactly same traffic selectors as before.

If you do not end up with same traffic selectors, then that means that
the old SA had traffic selectors which were not allowed by your
policy, thus it would have been removed.

> (and not one of the other acceptable subsets).

Yes, this is true. In a sense you can consider the old traffic
selectors from the old SA as "triggering packet", so in that sense you
do conside the old SA. 

We really want to make sure the rekeyed SA will have traffic selectors
which are usable for the traffic which went through the SA before
rekey. 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 May 2009 10:45:27 -0400

Let me draw a time-sequence diagram to explain things as I understand 
them (fixed-width font alert)

         site to site policy
         policy: 1.0.0.0/8 <-> 2.0.0.0/8

         Alice-GW                     Bob-GW
--Trigger-->     (1.2.3.4->2.3.4.5)
(1)            <====IKEv2 exchange 1==>
                <***Trigger**IPsec SA**>

(2)            <====IKEv2 rekey ======>
                <***second***IPsec SA**>

(3)                               "POLICY CHANGE"

(4)            <====IKEv2 rekey: fail=>
(5) new trigger  (1.2.3.4 -> 2.3.4.5)
(6)            <====IKEv2 exchange 1==>
                <***third***IPsec SA***>
                1.2.3.4/32  <-> 2.0.0.0/8

The question is, what was this policy change at (3)?
Shouldn't such a policy change have caused any incompatible SAs to be 
removed?  Let me suggest that perhaps there are changes which are not 
clearly policy changes.

Postulate that Bob-GW also has a "road-warrior" (George) that normally 
lives at Alice's site.
Normally, George lives behind Alice-GW, and uses the site to site 
tunnel.  When George is on the road, he uses his 1.0.0.0/8 address
(which is 1.4.5.6)  (He may also bring up a tunnel with Alice-GW)

Let's say that the event at (3) is that George brought up his tunnel 
with Bob-GW. Bob now has two SAs in his SPD:

1.    src: 2.0.0.0/8 dst: 1.4.5.6/32  STUFF.
2.    src: 2.0.0.0/8 dst: 1.0.0.0/8   STUFF.

The SPD is nicely ordered, so traffic to George travels down the 
seperate tunnel, while traffic back to Alice-site uses the original 
tunnel.  The George tunnel had to be inserted before #2 so that it would 
have higher priority.

Now, when Alice rekeys, is that site allowed to assert control over
George's traffic?  There are many answers here.  I think that there are 
arguments for many things.

Note that in this situation, (3) is not a policy change from an 
administrative point of view, but simply George bringing up his tunnel.
The IP address 1.4.5.6 might not even be present in the PAD: it could 
come from a certificate.

Note that I am not saying that that the situation outlined above 
(whereby Bob-GW fails the rekey, forcing Alice-GW to try again when she 
has a trigger packet, resulting in a much narrower SA -- how narrow is 
up to Bob-GW) is correct.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 13 May 2009 12:05:54 +0300

> (6)            <====IKEv2 exchange 1==>

Which means now that traffic from tunnel from Alice having 1.4.5.6
address MUST be dropped as it is coming from wrong tunnel, as there is
higher priority SPD entry which says they should be coming from the
other SA. For me that would mean that SPD entry #2 is bad as now not
all traffic covered by the traffic selectors are not allowed to be
sent over that SA (meaning it will cause black hole if Alice tries
to send traffic using those addresses).

Thus the decorrelated version of the SPD would be:

1.    src: 2.0.0.0/8 dst: 1.4.5.6/32  STUFF.
2a.   src: 2.0.0.0/8 dst: 1.0.0.0 - 1.4.5.5   STUFF.
2b.   src: 2.0.0.0/8 dst: 1.4.5.7 - 1.255.255.255   STUFF.

Hmm... now reading RFC4301 I found out that it says you are allowed to
create such entries, as it says you can either

  a) send decorrelated entries as traffic selectors
  b) send original entry from correlated SPD
  c) send subset of decorrelated entries.

(RFC 4301 section 4.4.1 under decorrelation).

thus during rekey you can still rekey the original 1.0.0.0/8 <->
2.0.0.0/8 tunnel and that should not change anything as the first SPD
entry is still there with higher priority as #2 has.

It also says something about the handling changes to the SPD:
----------------------------------------------------------------------
   Handling Changes to the SPD While the System Is Running

      If a change is made to the SPD while the system is running, a
      check SHOULD be made of the effect of this change on extant SAs.
      An implementation SHOULD check the impact of an SPD change on
      extant SAs and SHOULD provide a user/administrator with a
      mechanism for configuring what actions to take, e.g., delete an
      affected SA, allow an affected SA to continue unchanged, etc.
----------------------------------------------------------------------

Which would indicate that RFC4301 does not actually require you to
remove SAs which violate your own policy (which I did expect it to
do). I.e. you can still keep SAs even when you know that some traffic
coming from those SAs will be thrown away immediately when you do
inbound traffic checks as the traffic selectors negotiatiated for the
SA do not match the SPD entries.

> The IP address 1.4.5.6 might not even be present in the PAD: it could 

If it results change to the SPD, I would consider that as a policy
change, regardless of the reason of the change.
-- 
[email-masked]