RE: Addresses in traffic selectors in IKEv2

["Andrew Krywaniuk" <andrew.krywaniuk@alcatel.com>]

I agree with this. There are lots of little pitfalls that I have seen when
dealing with subnets:

e.g. does 192.168.10.0/24 == 192.168.10.30/24? Not if you use memcmp.

What happens if someone receives a QM1 containing subnets and the peer
returns a QM2 containing ranges?

We would have liked to implement QM using only ranges, but we were forced to
convert to subnets whenever possible because some of the other IPsec
implementations aren't (or at least weren't at the time) able to handle
ranges.

There is no advantage to having multiple types in this case, so we should
ditch the less generic ones.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC
> Sent: Monday, March 11, 2002 11:07 PM
> To: ipsec@lists.tislabs.com
> Subject: Addresses in traffic selectors in IKEv2
>
>
> One of the most common configuration errors found in VPNC conformance
> testing is that people use the wrong address type in their traffic
> selectors. There are two ways to specify multiple addresses (ranges
> and subnets) and three ways to specify a single address (ranges,
> subnets, and address). This is silly.
>
> IKEv2 should have exactly one way to specify either a single or
> multiple addresses: a range. IKE implementations *could* match the
> different types to each other (some implementations do that), but
> there is no reason to force them to.
>
> --Paul Hoffman, Director
> --VPN Consortium
>