Subject: [Ipsec] IKEv2 Traffic Selectors?

From: Markku Savela <[email-masked]>
Date: Thu, 10 Feb 2005 11:37:26 +0200

I'm not myself involved in IKEv2 impelementations, which is why I may
be misreading the IKEv2 draft. But, perhaps some expert can quickly
answer to my concern:

>From 2401bis I get the following picture for traffic selector:

 - list of "basic selectors"

 - a "basic selector" is a unit defining local and remote port range, local
   and remote address range and protocol range.

The basic selector matches if *ALL* of the range conditions are met
(AND rule), and the full selector matches if *ANY* of the basic ones
matches (OR rule).

>From my reading of IKE, it seems to split the traffic selector into
two selector payloads: TSi and TSr. For example, the "per packet
information" is supposed to be added to the front of the traffic
selector. Assuming I'm the initiator for outgoing packet, seems to
indicate that the packet information will be split into two

  TSi[1] = packet protocol, src address, src port
  TSr[1] = packet protocol, dst address, dst port

This leads me to believe, that TSi and TSi *must* have exactly the
same number of entries, and the entry on same "index" must correspond
to one 2401 "basic selector"?

How else could you express a selector like "localport=1234 and
remoteport=80"?

Thus, the matching rule for TS payloads in IKEv2 are

  for (i = all traffic selector in TS payload)
       if (TSi[i] and TSr[i] match the condition)
           selector match;

The question of course is then: why two payloads in the first place?
Both must have exactly same number of entries, and must be in synch. I
would think single TS payload with combined initiator and responder
values would be less error prone?

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

---

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

Markku Savela writes:
> same number of entries,

No such requirement. They can have different number of entries, and it
is very common to have different number of entries.

> and the entry on same "index" must correspond

Nope. 

> How else could you express a selector like "localport=1234 and

All TSi payloads are ORed together and all TSr payloads or ORed
together, to get the final local and remove selectors. Any item in the
local selectors can be combined with any item in the remote selectors.  

>        if (TSi[i] and TSr[i] match the condition)

Nope.

It is:

match = false;
foreach i (TSi)
    if (TSi matches the condition)
	match = true;

if (!match)
	return not_matched_failure

match = false;
foreach i (TSr)
    if (TSr matches the condition)
	match = true;

if (!match)
	return not_matched_failure
return matches.

> The question of course is then: why two payloads in the first place?

So thay you can express things like:

   TSi = 10.0.0.1, tcp, port 79
or TSi = 10.0.0.1, tcp, port 22
or TSi = 2001:670:83:f00:202:b3ff:fe1f:7884, any

to

    TSr = 0.0.0.0-255.255.255.255, any
or  TSr = 0::0-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, any

which means that any IPv4 traffic having local tcp port 79 or 22 can
be allowed from anywhere from the world, and also any IPv6 traffic
to given local addres scan be allowed.

There would also be insane combinations like having source IP of IPv4,
and destination IP of IPv6, but there cannot be any packets matching
those combinations so no problem there.

The most common policy will most likely be the remote client policy,
i.e, where the initiator proposes

      TSi = (0, 0-65536,0.0.0.0-255.255.255.255)
      TSr = (0, 0-65536,0.0.0.0-255.255.255.255)

and responder replies with:

      TSi = (0, 0-65536,192.0.2.202-192.0.2.202)
      TSr = (0, 0-65536,192.0.2.0-192.0.2.255),
	    (0, 0-65536,10.0.0.0-10.255.255.255)

I.e. it allocates the IP address of 192.0.0.2.202 to the device, and
says that other remove clients can also be accessed through it
(192.0.2.0-192.0.2.255 range), and it also says that the 10.0.0.0/8
network can be acccessed through it, as this is the internal network
used by the corporate. 

> values would be less error prone?

That would cause the comibnatory explosion of the rules, as then that
kind of complicated rules would need to be expanded as separate
payloads. This is same thing that was done to the algorithm proposals,
i.e. we can take any algorithms from each set, no need to list that
AES-SHA1, AES-MD5, 3DES-SHA1, 3DES-MD5, CAST-SHA1, CAST-MD5, etc, but
simply say AES, 3DES, CAST for encryption and SHA1, MD5 for auth. 
-- 
[email-masked]

---

From: Markku Savela <[email-masked]>
Date: Thu, 10 Feb 2005 14:06:29 +0200

> 	return not_matched_failure

Thanks for clarifying this. It has implications for me, because in my
policy, I can express the following condition:

(localport=1 and remoteport=1) or (localport=2 and remoteport=2) -> A1

IKEv2 cannot express this selector in negotiation.