Re: Addresses in traffic selectors in IKEv2

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

>>>>> "David" == David Waitzman <djw@bbn.com> writes:
    David> We recommend against ranges and for masks for two reasons:

    David>  - ranges are less natural to network administrators; they tend to
    David>    work more with IP prefixes (masks) when handling configuration
    David>    tasks; IP prefixes also tend to reflect the sub-topology of a local
    David>    network, while ranges don't.  (However, ranges are more flexible,
    David>    and *don't* bind you to subnet topology, so they're also useful,
    David>    especially for things like web farms.)

  This is a red-herring argument. If netmasks are more natural, then the user 
interface can present netmasks for the naive admin. Ranges are the more
general object, and we are talking about protocols, not user interfaces.

    David>  - (as stated already) arbitrary ranges don't compile into ternary
    David>    CAMs very well, especially if there are multiple range-based
    David>    selectors in a policy or SAD entry; in the worst case, it uses

  Nor, btw, do port ranges, IPv6 addresses, or ordered SPD entries.
  If you expect to put your SPD literally into a CAM, then you are going to
lose period. Use your CAM as a per-flow forwarding cache (and you can even
buy binary CAMs).  
  There are many other vendors of classification hardware that do not have
this problem, btw.

    David>    2*(log2 rangeSize)-1 entries per range; if multiple ranges are
    David>    found in the same selector, you need the *product* of the number of
    David>    CAM entries for each field, in total.  (Don't expect this happens
    David>    much in the real world, though.)  IP prefixes (or other mask/value
    David>    entries) only require a single CAM entry.

  So, do not support unaligned ranges. But that is your implementation, not
the key negotiation protocol.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [