remove TS from IKEv2 (RE: Addresses in traffic selectors in IKEv2)

[Michael Choung Shieh <mshieh@netscreen.com>]

I will propose to remove TS entirely so we don't need to worry about IP
subnet vs. range any more.

There are encountered numerous problems when puting proxy_id in IKEv1 (it's
improved when using TS in IKEv2 but the fundamental problem is not solved).
The basic problem I see is we try to put SPD inside key managemnt protocol,
which has lots of problems when dynamic routing is implemented.

I see the purposes of proxy_id (or TS) are
1. the index to find the sa when there are multiple IPsect tunnels.
2. indicate the SPD associate with the sa
3. a mechanism to detect misconfigured SPD in IKE instead of quietly
rejected later.


RFC2401 says there are SPD selectors associated with each SA.  However, it
should be local implemenation issue to bind them together.  Puting SPD in
IKE is just dulplicating effort in key managment protocol without much
benefit.  The general problems are:

1. Users want to limit their tunnel traffic by "services", eg. FTP, DNS,
AOL, UUCP.  However, many "services" have differnet control and data plane
and use multiple protocols and ports.  For example, FTP takes port 20 and
port 21.  Stateful firewall will even smarter to only open a single source
port for port 21.  another example is DNS may use TCP or UDP.  Bearing all
the knowledge into IKE is overkilled and without actual benefit.

2. puting SPD in form of TS won't simplify your SPD implementation.  SPD
still need to know all the complexity for each services.  You still check
every packet comes out of tunels against SPD, no matter what TS you received
before.

3. I was almost convinced that puting SPD in IKE can detect the
misconfiguration.  However, This has introduced many troubles when I try to
run dynamic routing and others (listed below) over tunnels.  

If admin misconfigure their firewall, the traffic will be dropped silently
(or log for potential attack) and they need to find out the reason.  I think
the same logic applies to ipsec traffic as well.  key mgmt protocol
shouldn't bear the responsibility to detect mis-configure SPD. 

4. There are lots of issues when running dynamic routing over tunnel since
it's difficult to figure out what the TS should be.

5. If you run NAT before tunnel and the nating address is from one of
multiple ip pools, it's difficult to figure out what the TS should be.


Giving the difficulty to do TS right, I would propose to use a simple ID
(e.g. sequence number) to identity the tunnel and leave all complexity of
SPD out of IKE.

Michael Shieh

-----Original Message-----
From: Markku Savela [mailto:msa@burp.tkv.asdf.org]
Sent: Tuesday, March 19, 2002 10:01 AM
To: ipsec@lists.tislabs.com
Subject: Re: Addresses in traffic selectors in IKEv2



> From: Chris Trobridge <CTrobridge@baltimore.com>
>
> We took the same approach as Markku mentioned.  We allow the user to
> specify individual addresses, subnets or ranges, but implementation
> only sees ranges.

Actually I don't prefer ranges, I only implemented address/mask.

What I was trying to say, choose one: either ranges only or
address/mask, but not both.

The SPD policy selectors will consist following components

  - IP protocol number (8 bits)
  - src address 128 bits (IPv6/IPv4)
  - dst address 128 bits ( -"-)
  - source port 16 bits
  - destination port 16 bits
and for IPv6 scoped architecture, we need at least locally
  - destination scope identifier (32 bits)
  - source scope identifies (32)
and private addition
  - ICMP type and code (16 bits)
--------
total selector bits 376 bits!

It just gets pretty messy if some of these can be expressed as
ranges. You have to compare each field separately.

It's much simpler if you don't implement ranges, then you can just
construct the 376 bits and compare under mask.

Now above was all for SPD side.

The traffic selector in IKE payload (IMHO) is supposed to describe
"qualifiers" for the negotiated SA. Scope identifiers are local issue,
so they don't need to be included. Pretty much all of the rest is
needed.

It's okay to use ranges here, as masks are easy to translate into
ranges.

It should be noted, that address ranges are not needed (or meaningful)
with transport mode SA's.

Again, I wish to express the difference between SPD selector and SAD
"qualifier", for example VPN tunnel

  dst=company/x -> "SA spec for SG"

Now if you want communications to all hosts within "company/x" to use
same sa, you specify "company/x" (=range) in traffic selector. If you
want each host behind the SG to get own SA, you specify individual
address in traffic selecter. Again, this choice is part of the "SA spec
for SG". Again, SPD entry is same for both variations.