Subject: [Ipsec] Traffic selectors violating own policy

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Jun 2005 12:34:02 -0700

Greetings again. The IKEv2 clarifications document has the following section:

-----
4.6  Traffic selectors violating own policy

    Section 2.9 describes traffic selector negotiation in great detail.
    One aspect of this negotiation that may need some clarification is
    that when creating a new SA, the initiator should not propose traffic
    selectors that violate its own policy.  If this rule is not followed,
    valid traffic may be dropped.

    This is best illustrated by an example.  Suppose that host A has a
    policy whose effect is that traffic to 192.0.1.66 is sent via host B
    encrypted using AES, and traffic to all other hosts in 192.0.1.0/24
    is also sent via B, but must use 3DES.  Suppose also that host B
    accepts any combination of AES and 3DES.

    If host A now proposes an SA that uses 3DES, and includes TSr
    containing (192.0.1.0-192.0.1.0.255), this will be accepted by host
    B. Now, host B can also use this SA to send traffic from 192.0.1.66,
    but those packets will be dropped by A since it requires the use of
    AES for those traffic.  Even if host A creates a new SA only for
    192.0.1.66 that uses AES, host B may freely continue to use the first
    SA for the traffic.  In this situation, when proposing the SA, host A
    should have followed its own policy, and included a TSr containing
    ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.

    In general, if (1) the initiator makes a proposal "for traffic X
    (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
    does not actually accept traffic X' with SA, and (3) the initiator
    would be willing to accept traffic X' with some SA' (!=SAi), valid
    traffic can be unnecessarily dropped since the responder can apply
    either SA or SA' to traffic X'.

    (References: "Question about "narrowing" ..." thread, Feb 2005.
    "IKEv2 needs a "policy usage mode"..." thread, Feb 2005.  "IKEv2
    Traffic Selectors?" thread, Feb 2005.  "IKEv2 traffic selector
    negotiation examples", 2004-08-08.)
-----

This was a thorny issue when we discussed it earlier this year, but 
it needs to be resolved. I see three options:

a) Say that the situation is unfortunate but a reality

b) Add a SHOULD-level prohibition on SAs with traffic selectors that 
violate their own policy

c) Add a MUST-level prohibition on SAs with traffic selectors that 
violate their own policy

First question: are there more options?

Second question: do people have a preference between these two 
options? The second and third seem cleaner but probably will add 
large overhead for what is clearly a corner case. The first seems 
unclean but possibly sufficient.

Suggestions?

--Paul Hoffman, Director
--VPN Consortium

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

---

From: Geoffrey Huang <[email-masked]>
Date: Tue, 14 Jun 2005 13:48:12 -0700

Hi Paul,

I don't see there are any other options; at least not without
complicating matters greatly.

W.r.t. your second question, I want to point out that (b) also implies
(a).  If you don't make it a MUST, then it's still a "best-effort"
attempt to avoid the situation.  That being said, I believe that such an
occurrence is a misconfiguration on A's part.  I don't believe that the
protocol needs to go out of its way to avoid a fairly obscure case.  I
vote for (a), but I would accept (b).

-g

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 14 Jun 2005 15:48:58 -0500

> First question: are there more options?

d) Forbid policy which leads to this problem -- kick the can to
   administrators and have them break up aggregate policies into
   non-conflicting entries.

No, I don't like (d) :)

e) When an incoming packet is protected with an SA which violates policy
   then drop the packet, negotiate a new SA with narrower TSs
   corresponding to the dropped packet and let the transport and/or
   application re-transmit the dropped packet.

(e) is not great, but tolerable, I think.

I think it should be possible to programmatically ensure that SAs with
TSs that conflict with local policy are never negotiated, so (c) it
should be.

> unclean but possibly sufficient.

They amount to much the same thing -- an implementation that incorrectly
negotiates SAs with TSs that conflict with local policy will run into
this problem and the only difference between (b) and (c) then will be
the degree of non-compliance with the RFC.

Nico
--

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 15 Jun 2005 10:54:04 -0700

> c) Add a MUST-level prohibition on SAs with traffic selectors that 
As IKEv2 allows different policy configurations to exist on the two ends,
the only option is "c" for things to work. So, i really don't know why we
have so many options :-)

-mohan

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Jun 2005 16:29:46 -0400

Paul,

>    valid traffic may be dropped.

I'd go for option (c), making the above statement into a MUST.

Steve

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 16 Jun 2005 17:33:05 -0400

> First question: are there more options?

Silly question.  There are always more options!  

> unclean but possibly sufficient.

We can, and SHOULD do better than (a).

Prefer (c) (maximises interoperability, minimises black holes). 

Can live with (b) if other implementors really need an escape clause.

						- Bill

---

From: "William Dixon" <[email-masked]>
Date: Mon, 20 Jun 2005 20:00:33 -0400

Based on implementation & deployment experience with IKEv1, I'd prefer
another option. If you choose either B or C below, then you aren't providing
sufficient guidance to enable interop. 

IKEv1 had this issue as well. Windows solved it by always proposing the most
specific selector in policy. This is efficient aggregator of traffic. But my
experience has shown this forces too much a-priori configuration
coordination, so it makes the policy system quite cumbersome to use. I think
Bill told me Solaris has the option of proposing the policy selector OR a
5-tuple generated from the traffic. 

Option D. An IKE initiator MUST not propose a more general selector when it
has a more specific selector for that traffic. It SHOULD propose both the
most specific selector it has configured in policy, as well as a selector
constructed from the 5-tuple of the packet, unless the most specific policy
selector is permit or block. An IKE responder SHOULD match the most specific
selector, and SHOULD respond with the most general matching subset.

Example:

Host A Configuration:
Require IPsec ESP for all traffic to 192.0.1.66
Require IPsec AH for all traffic to 192.0.1.0-192.0.1.255

Host B Configuration:
Require IPsec AH for all traffic to/from 192.0.1.0-192.0.1.255

There exists the case, starting from a no SA state, that host B (with only
subnet policy) initiates upper layer new connection from 192.0.1.66, and
thus is the IKE initiator, proposing only what is in policy, it's subnet
selector, which results in the inbound traffic from 192.0.1.66 being blocked
for the reason Paul described. However, this selector could also require
blocking traffic, in which case the traffic will of course be dropped. There
are any number of perfectly valid policy configurations on Host A & B, such
that what I propose is the best way to negotiate these. Such as:

Block all TCP from 192.0.1.66
Block all UDP from 192.0.1.66

Require IPsec ESP transport mode for TCP src *, dst 445 from 192.0.1.66
 (encrypt SMB file sharing traffic)

Require IPsec AH transport mode for TCP src *, dst 3389 from 192.0.1.66
 (authenticate Remote Desktop protocol, since it provides it's own
encryption)

Permit TCP src *, dst 443 from 192.0.1.66

The source address, 192.0.1.66 could be a subnet, Any or other wildcards as
needed. Thus the most flexible option is to propose what is both in policy
and in traffic.

Clearly for IPsec gateways, requiring IKE to propose full 5-tuple options
for every new 5 tuple would be a burdensome requirement, thus it's a SHOULD
or we add more text to explain. We would expect gateways to have
administratively coordinated policy, such that only the selectors in policy
are proposed, and thus aggregate much traffic inside the same IPsec SA pair.
However, there are scenarios where different organizations would like to
configure their own gateways to allow certain types of IPsec protected
traffic inbound, and would need the initiating gateway to propose the
specific 5-tuple.

Regarding:
http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-
03.txt

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Paul Hoffman
> Sent: Tuesday, June 14, 2005 3:34 PM
> To: IPsec WG
> Subject: [Ipsec] Traffic selectors violating own policy
> 

<snip>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 27 Jun 2005 10:47:37 -0400

William,

>selector, and SHOULD respond with the most general matching subset.

2401 and 2401bis specify how to select the SPD entry for an outbound 
packet. The fact that the SPD is ordered under user/admin control (or 
decorrelated in 2401bis) provides the basis for policy selection, 
before one gets to the stage of constructing proposals in IKE.

I recall that MS used to have a non-compliant implementation for the 
Windows SPD, which imposed an arbitrary notion of specificity 
relative to the 5-tuple selector space, and thus imposed an ordering 
not controlled by the user/admin. Has this been fixed in more recent 
implementations? If not, does this non-complaint aspect of the MS 
IPsec implementation have any bearing on your proposal?

Steve

---

From: "William Dixon" <[email-masked]>
Date: Tue, 28 Jun 2005 01:46:43 -0400

Steve, sorry to confuse things, yes 2401 and 2401bis gives specific
direction on ordering preference. I confused the discussion by talking about
filter ordering in terms of specificity. This does not have bearing on what
I'm proposing.

What I'm suggesting for the IKEv2 clarifications draft is that both the
selector matched in policy, and a dynamically built selector based on the
full 5-tuple from the packet be proposed (as optional but recommended for
transport mode). The reason is because my deployment experience shows that
it is a much needed capability to enable host-to-host IPsec SA establishment
when policies on either host are customized for that host, but not
necessarily coordinated down to the port level between the two hosts. If you
don't propose the full 5-tuple from the packet, there are many circumstances
where two host IPsec policies would allow an IPsec SA specific to the
5-tuple to be established, but they would fail if IKE proposes only the
selector from policy.

You are right, Windows 2000, XP and 2003 does not allow administrator
control over selector order. The selector ordering is automatically
determined based on an algorithm for specificity (weight). The detailed
documentation for selector ordering was made available recently here:
http://www.microsoft.com/technet/community/columns/cableguy/cg0205.mspx

The weight value itself is shown in the IPsec monitor GUI in XP and 2003,
not in Windows 2000. Automatic ordering does not adhere to the requirement
in RFC2401 & 2401bis for manual ordering. I have not seen interop problems
myself in deployments that result from this difference. Certainly if anyone
has, please let me know. However, it's clear how interop might be affected
if two different platforms use exactly the same policy design, and the side
with manual ordering doesn't also order the filters in the same order as the
automatic algorithm in Windows. What I've seen is that the capabilities &
supported options of host OS IPsec implementations are sufficiently
different that a custom policy is required anyway, one that is tested
interoperable with respect to selector negotiation. I don't know the plans
for Longhorn for this specific issue. There are many changes for the IPsec
implementation in Longhorn, so we'll have to see when the beta is released.

> On Behalf Of Stephen Kent
> Sent: Monday, June 27, 2005 10:48 AM
> To: William Dixon
> Cc: 'IPsec WG'
> Subject: RE: [Ipsec] Traffic selectors violating own policy
> 
> William,
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Jun 2005 08:15:00 -0400

>filter ordering in terms of specificity. This does not have bearing on what

OK.

>5-tuple to be established, but they would fail if IKE proposes only the

Sounds reasonable to me. Thanks for the clarification.

>implementation in Longhorn, so we'll have to see when the beta is released.
It is not a matter of interoperability; explicit (manual) ordering is 
mandated for IPsec to enable a user/admin to express a specific 
access control policy in a precise fashion. The need o be able to 
order entries in an ACL where wild cards are allowed in names is a 
common one, dating back at least 30 years, e.g., Multics.  This 
convention is almost universally employed in firewalls to manage rule 
sets, in router filters, etc. Not providing this facility makes it 
harder for a user/admin to ensure that a specific access control 
policy is properly represented in the SPD.

Steve