Subject: [Ipsec] Question about "narrowing" ...

From: Markku Savela <[email-masked]>
Date: Mon, 7 Feb 2005 17:32:19 +0200

Is narrowing "well defined"? How to prevent "insane" narrowing or how
to deal with it, if and when it happens? Consider a policy (assume
"any" for things not specifically listed, and the packet specific "ts"
included)

 remote 10.0.0.0/8 -> protect

and packet
 remote=10.0.1.1 port=80
This will cause me to request for SA with
   SA1: remote 10.0.0.0 - 10.255.255.255
The other side can "narrow" it down to
   SA1: remote 10.0.1.0 - 10.0.1.255

Then, another packet
 remote=10.0.2.2 port=80
does not match the narrowed SA1, so I request again
  SA2: remote 10.0.0.0/8
this time the other end decides to narrow it with port range and
returns
  SA2: remote 10.0.0.0 - 10.255.255.255 port= 1-100

Now I suddenly have two possible choices to use for the original
packet, or other new packets like

  remote=10.0.1.2 port=90

Both SA1 and SA2 could be used for this. The questions arise...

- should this be detected as error condition?

- should I just pick either SA1 or SA2 randomly?

- should there be some deterministic rule to pick between SA1 and SA2?

Above are not trivial, because TS contains remote/local address,
remote/local port and protocol. Insane narrowing can happen in
"devious" ways and combinations, and finding some sensible algorithms
is not obvious to me. One solution is of course:

- scrap the narrowing concept.

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 07 Feb 2005 20:44:24 -0500

> - should this be detected as error condition?

No.

> - should I just pick either SA1 or SA2 randomly?

Yes.  From your point of view, they're equivalent.

>From the peer's point of view, they're equivalent.

Treat it just like any other case of multiple SA's matching the 
packet.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 8 Feb 2005 12:13:07 +0200

Markku Savela writes:
> Is narrowing "well defined"?

I think it is.

> How to prevent "insane" narrowing or how to deal with it, if and
> when it happens?

They are not insane they are allowed by policy. 

> packet, or other new packets like

Yes, and the problem being? 

> - should this be detected as error condition?

No. It is completely valid to create overlapping SAs in the rfc2401bis
architecture. They can be used do QoS and other things. 

> - should I just pick either SA1 or SA2 randomly?

You can select one randomly, or you can use some more complicated
method. 

> - should there be some deterministic rule to pick between SA1 and SA2?

Probably, but other responder does not care which you use, so it is
completely your internal matter what do you use to select SA. You can
use QoS parameter, phase of moon, last bit of the crc of the packet or
whatever. 

> - scrap the narrowing concept.

I do not think that is an option.

Anyways, I do not expect implementations to create such SAs unless
they have some proper reason for that from their policy.

Note, that in IKEv2 there is explicitly allowed to have multiple
overlapping SAs, and create child sa is never a rekey unless specified
as such by using notify. This means that there is never any reason to
assume that some traffic should move to another SA based on the new
IPsec SAs being created, only when there is a rekey.

When you have overlapping SAs you must accept traffic from all of
them, and you can use whatever method to select which one of them to
use when sending. 
-- 
[email-masked]

---

From: Markku Savela <[email-masked]>
Date: Tue, 8 Feb 2005 12:46:59 +0200

> From: Tero Kivinen <[email-masked]>

> You can select one randomly, or you can use some more complicated

Node A has policy: 
 C1: remote 10/8 -> A1

Node B has policy
 C1: local port = 80 -> A1
 C2: local 10/8 -> A1

(with the idea, that two SA's are used, one for port =80, and another
for the rest).

Now, if Node A can pick SA randomly (for example packet
"remote=10.0.0.1, port=80" would match both narrowed selectors), then
the whole point of narrowing has been lost. Why do it at all?
[Rhetorical question]

With my question, I only wanted to clarify, that it is the
responsibily of the "narrower" to do the right thing.

 A offers: remote=10/8,port=any (packet: port=80,remote= 10.0.0.1)

How is this narrowed down, so that B's policy is followed in A? Or is
this impossible?

---

From: Markku Savela <[email-masked]>
Date: Tue, 8 Feb 2005 14:03:14 +0200

Ok, I will answer my own question... sorry about confusion :-)

> From: Markku Savela <[email-masked]>

> ..

narrowed to "remote=10/8, port=80"

and another

  A offers: remote=10/8,port=any (packet: port=100,remote= 10.0.0.1)

then this is narrowed into

  remote=10/8, port != 80

=> if you do narrowing, you have to use decorrelated policy
in the narrowing process?

---

From: Yoav Nir <[email-masked]>
Date: Tue, 8 Feb 2005 14:20:38 +0200

The traffic selector can be narrowed down to include only port 80.

I fear that the case you describe below is one of a configuration 
mismatch.  When Node A asks for 10.0.0.0/8, how can Node B know whether 
the matching SA is C1 or C2?  It might pick one at random (say C1), and 
then, assuming that Node A wanted to send FTP, then it's now stuck with 
a useless SA.  If A tries the same thing again, there's no reason to 
assume that B chooses differently this time.  The only way out is for A 
to request 10.0.0.0(port=21).  But now B answers with a narrow SA, and 
we are stuck with creating a different SA for each port.

Now, let's suppose that node B originally did reply, but according to 
C2.  Then it would answer with two traffic selectors: one for ports 
0-79, the other for ports 81-65536.  This is kind of kludgy, but it 
would allow A to know that it still has no SA for port 80.  If it ever 
needs one, it can always negotiate another SA for port 80.

I suggest that a good heuristic would be as follows:
- Responders should reply with the broadest possible SA included in the 
request.
- Initiators should be ready to initiate new Create_child_SA exchanges 
to get at the narrow SA that they actually want.

Suppose our initiator is an endpoint, that its address is 192.0.1.17, 
and that the packet that triggered the SA creation is 
192.0.1.17:3333-->10.0.0.1:80.  Because all it has is its C1 rule, it 
will offer:

   192.0.1.17(0-65536) <--> 10.0.0.0/24(0-65536)

On node B this more closely matches C2, so node B responds like this:

   192.0.1.17(0-65536) <--> 10.0.0.0/24(0-79,81-65536)

Node A is missing an SA that actually matches its packet, so it creates 
a new exchange, this time with:

   192.0.1.17(3333) <--> 10.0.0.1(80)

Which will be accepted.  Note that the need to do this heuristic is 
only if there is a policy mismatch.

Perhaps the implementation guideline draft can include something like 
this heuristic.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 8 Feb 2005 14:50:34 +0200

> in the narrowing process?

Yes. And also when you are proposing traffic selectors to the other
end you should send decorrelated policy, as otherwise the responder
can select something to the SA which are not allowed by your policy. 
-- 
[email-masked]

---

From: Markku Savela <[email-masked]>
Date: Tue, 8 Feb 2005 14:52:50 +0200

One more silly question...

I wrote

>  C1: local port = 80 -> A1

...and it works fine if A is the initiator, and B is doing the
narrowing using decorrelated policy.

But, what about other way? Assume B is the initiator, and is *NOT*
using decorrelated policy (decorrelation is not mandated by
2401bis).

 B offers:
  local ANY, local port=80 (packet: local=10.0.0.1, local  port=80)
 A replies?
  local 10/8, local port=80

 B offers:
  local 10/8, local port=ANY (packet: local=10.0.0.1, local port=100)
 A replies
  local 10/8, local port=ANY

Now, as far as A is concerned, for a packet "remote=10.0.0.1, remote
port=80", both SA's are valid, and it can use either one. But, B's
policy will drop port=80 packets, if not sent with the port specific
SA.

There would be no problem, if both A and B had matching policies.

The conclusion here: either policies must match exactly so that
narrowing never occurs, or if policies are not quite matching as in
above, BOTH sides must be using decorrelated policies and reflect this
in already in their offers?

Seems that IKEv2 would need to know whether other side is using
decorrelated policies or not?

Remember: decorrelation is not mandatory by 2401bis!

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 8 Feb 2005 14:54:36 +0200

> to get at the narrow SA that they actually want.

All these problems go away if you use the decorrelated traffic
selectors (as pointed out by Markku) when you are proposing and use
the same decorrelated traffic selectors when narrowing. That way the
resulting SA will also be matching exactly one policy rule in both
ends.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Tue, 8 Feb 2005 15:06:45 +0200

In both cases A offered the same thing (remote=10.0.0.0/8,port=any).  
How is B to know what to answer the first and second time?  B doesn't 
get to see the packet.

---

From: Markku Savela <[email-masked]>
Date: Tue, 8 Feb 2005 16:47:12 +0200

> From: Yoav Nir <[email-masked]>

> How is B to know what to answer the first and second time?  B doesn't 

Yes, B does get to see the packet. Somewhere in IKEv2 there is a
statement that the first entry in the selector list describes the
packet information.

It should be noted that this "packet information selector" is only for
IKE use, it should not be actually included in the TS selectors of the
resulting SA in SADB.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 08 Feb 2005 13:03:27 -0500

> they have some proper reason for that from their policy.

There's another way to trigger the scenario Markku is worried about:

The responder's policy may not be static -- it could have changed between the
first and second SA creation.

if the first SA remained consistent with the new policy there would be no
reason for the responder to delete it.

					- Bill

---

From: Yoav Nir <[email-masked]>
Date: Wed, 9 Feb 2005 09:46:15 +0200

Can't believe I haven't noticed this before.  It's right there on page 
24.

Thanks.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 9 Feb 2005 16:22:44 +0200

> IKE use, it should not be actually included in the TS selectors of the

It does not matter wheather it ends in the SADB or not, as normally
the final TS selectors include that address inside one of the other
selectors (and if they do not, then it MUST be included in the SADB
selector).

I would guess IKE implementations will optimize that kind of redundant
items in the list away before giving it to the IPsec.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 9 Feb 2005 16:39:49 +0200

> reason for the responder to delete it.

Good think we already have the notify for that, i.e. if the other end
sends data to the SA which is not allowed to be sent to that SA, then
recipient of that data should send INVALID_SELECTORS notification to
the initiator. The recipient of INVALID_SELECTORS can then remove the
IPsec SA and recreate it, and now the other end will probably narrow
it to match to the newly installed policy, fixing the situation.

This still requires both ends to use decorrelated policy. 
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Feb 2005 13:57:22 -0500

>can select something to the SA which are not allowed by your policy.

Tero,

I'm a bit concerned by this suggestion.

2401bis says one should send the original SPD entry, not a 
decorrelated one, to preserve the external perspective of the SPD and 
keep the decorrelation a purely local optimization.

steve

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 09 Feb 2005 16:30:19 -0500

> keep the decorrelation a purely local optimization.

this seems wrong; if the initiator's original SPD entry has a hole punched 
in it by a previous rule and the responder is unaware of the hole, it may 
misroute traffic onto the wrong SA rather than creating the correct SA..

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 10 Feb 2005 12:00:45 +0200

> keep the decorrelation a purely local optimization.

You need to send the policy out you are following. If you are
following the decorrelated policy, you also need to communcate that to
the other end, or otherwise the policies in both end must match
exactly (in, which case the narrowing is not that useful).

I.e. if host A policy is (for simplicy I am assuming the policy is
only based by single IP-address selector):

1. 10.0.0.42 => ESP(AES)
2. 10.0.0.0-10.0.0.255 => AH(SHA1)

The decorrelated policy will be:

1. 10.0.0.42 => ESP(AES)
2. 10.0.0.0-10.0.0.41, 10.0.0.43-10.0.0.255 => AH(SHA1)

The responder host B is the SGW having policy which says that either
ESP(AES) or AH(SHA1) is accepted from whatever places as dictated by
the initiators policy (i.e. 1. 0.0.0.0-255.255.255.255 => either
AH(SHA1) or ESP(AES)).

Lets say the packet causing the trigger will have IP address 10.0.0.5.

Now if you use original policy to negotiate the SA, the SA will have
traffic selector 10.0.0.0-10.0.0.255 and uses AH(SHA1). Now if the
host B wants to send packet having IP of 10.0.0.42, then the host A
will reject that packet when it comes out from the tunnel as it should
have had ESP(AES). The host A will send INVALID_SELECTORS
notification, but the host B does not have any way to know how to fix
the situation, as he does not have information about the policy of the
other end.

If the host A uses decorrelated policy then the SA created will have
traffic selectors 10.0.0.0-10.0.0.41, 10.0.0.43-10.0.0.255 and uses
AH(SHA1), and if host B tries to send packet with IP address of
10.0.0.42, he notices there is no SA for it. It starts creating the SA
offering both ESP(AES) and AH(SHA1) as valid algorithms. The host A
will select ESP(AES), and we will have second SA with traffic
selectors 10.0.0.42 which uses ESP(AES).

So if you want to use narrowing, and you are having the policies in
both ends different, you should use the decorrelated policies if you
want to to automatically detect and fix the mismatches in the policies.
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Feb 2005 10:11:51 -0500

>misroute traffic onto the wrong SA rather than creating the correct SA..

Bill,

I may have lost track of where we are in discussion the IKE exchange.

Let's ignore decorrelation, since it is optional. What is correct 
behavior for an initiator? I thought that IKE  (v1 + v2) called for 
sending the SPD entry that matched the packet that triggered SA 
creation.  IKE v2 added the feature of sending the packet headers as 
well, to help the responder determine if there is an overlap, when 
the initiator's SPD entry is a superset of an SPD entry at the 
responder.  This allows the narrowing that I thought was the topic of 
this discussion. If this is the correct behavior for an initiator 
when decorrelation as not applied, then why change it when 
decorrelaton is applied? Decorrelation was not intended to change the 
external behavior of an IPsec implementation, but rather to allow an 
implementation to cache SPD data to achieve better performance.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Feb 2005 10:48:04 -0500

>exactly (in, which case the narrowing is not that useful).

First, decorrelation of the SPD does not change the policy expressed 
by the SPD.

If you do not have an extant SA that matches an outbound packet, you 
search the decorrelated SPD to find a match. the matching 
decorrelated entry and all entries linked to it because they were 
derived from  the same original entry, are used to create the SAD 
entry, which in turn forms the cache for outbound packet matching. 
This is what 2401bis says today in the section on decorrelation 
(page 23 of the 05 version, December 2004).

The text should probably be clarified by noting that the SA 
management protocol may "narrow" the resulting SPD entry, i.e., cause 
the SAD to be populated with a subset of the linked entries, rather 
than all of them, reflecting a mutually agreed upon subset of 
original SPD entry that both peers have elected to employ.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 11 Feb 2005 10:31:51 +0200

> (page 23 of the 05 version, December 2004).

That is fine, and yes, in IKE you use the full list of all entries
linked together, i.e. created by the same SPD entry.

> original SPD entry that both peers have elected to employ.

Yes.

But the problem is not only in narrowing. It is in the mismatching
policy. If I have policy which says all http traffic uses AES, and all
(other) traffic uses 3DES, and I create SA for the all other traffic
using the original SPD entry (all traffic uses 3DES), then the other
end could be send us a traffic following that rule, including http
traffic, which will then be rejected by the other end.

So this problem is not in the narrowing, but simply in the case of
mismatched policies. The reason it came out as a problem in the
narrowing is that the narrowing is only useful or usable if you have
mismatched policies, so both these are related to mismatched policies.
-- 
[email-masked]