Issue #47: Proposed change: all selectors can be a list of ranges, per IKEv2 spec and issue #69

[Tero Kivinen <kivinen@ssh.fi>]

The issue #47 change does not reflect the IKEv2 changes.

The IKEv2 have traffic selectors as follows:

	- Each traffic selector payload is list of traffic selectors.
	- Each traffic selectors contains:
		- type of traffic selector
		- protocol id
		- port range
		- address range
	- There is 2 traffic selector payloads, one for the initiator
	  and one for responder ends

	IKEv2 traffic selectors can express following selectors (from
	the clients point of view, i.e VPN client is initiator:

	TSi (initiator, from client)
		10.2.4.11 - 10.2.4.11, any protocol, 0-65535
	TSr (responder, from server)
		10.0.0.0 - 10.255.255.255, any protocol, 0-65535
		192.168.2.5-192.168.2.5, TCP, port 25-25 (smtp)
		192.168.2.8-192.168.2.8, TCP, port 80-80 (web)
		192.168.2.9-192.168.2.9, TCP, port 53-53 (dns)
		192.168.2.9-192.168.2.9, UDP, port 53-53 (dns)
		192.168.2.5-192.168.2.5, UDP, port 123-123 (ntp)

	I.e any traffic destioned to the client (configured with ip
	address 10.2.4.11) that originates either from the 10.0.0.0/8
	network (other clients, rest of the machines etc), or from the
	specific machine, protocol and port range. For example it does
	not allow traffic from 192.168.2.5, UDP, port 25.

If I understand correctly the issue #47 (Proposed change: all selectors
can be a list of ranges, per IKEv2 spec) there is no way to propose
that kind of thing in the SPD. The issue #47 allows to do

	From client
		10.2.4.11 - 10.2.4.11, any protocol, 0-65535
	From server
		10.0.0.0-10.255.255.255, 192.168.2.5, 192.168.2.8, 192.168.2.9
		any protocol
		port 25, 80, 53, or 123

I.e it does not allow restricting the port ranges to only specific ip
addresses. 

In addition to that there is issue #69 (Multiple protocols per SPD
entry), which tries to fix issue #47 little bit by adding multiple
protocols to each SPD entry, i.e in the above we could say TCP and UDP
protocols, but it actually would be incorrect as the original policy
allowed any protocol from 10.0.0.0/8 network.

The reason IKEv2 proposal syntax is good that because now IKEv2 allows
responder to choose subset of the traffic selector proposed by the
initiator. I.e the client can be configured to request

	TSi
	   	0.0.0.0-255.255.255.255, any protocol, 0-65535
	TSr
	   	0.0.0.0-255.255.255.255, any protocol, 0-65535

and the server (VPN SGW) can then have the proper policy, i.e it will
allocate ip number (10.2.4.11 above) to the client and select proper
subset for the client to be used (i.e only allow access to the
10.0.0.0/8 network and to those few server network hosts). This all
traffic will be using one single SA. 

To fix this we would need to change the issue #47 text so that SPD
entry contains list of SPD entry items, and each SPD entry item
contains one IP address range, one protocol, and one port range. The
issue #69 then goes obsolete, thus there is no need to have multiple
protocols per SPD entry item, as IKEv2 does not allow it, but there
will be multiple protocols per SPD entry, as each SPD entry contains
list of SPD entry items each having separate protocol.

I should have noticed this earlier, but I noticed only when I was
checking out the issue #69 and verifying that issue #47 was up to date
to the IKEv2. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/