Re: Addresses in traffic selectors in IKEv2

[Markku Savela <msa@burp.tkv.asdf.org>]

Maybe I finally after 3 years realised part of the problem I have
communicating my ideas: apparently I've had "dynamic selectors" from
the beginning, and thought others had also. Apparently not?

What I mean, for example I can have policy

   remote=10.0.0.1, remote_port=25 -> SA

would generate traffic selector for SA negotiation as follows

   protocol      : *
   remote_address: 10.0.0.1
   local_address : *
   remote_port   : 25
   local_port    : *

Now, when talked about connection specific SA's, my policy has a
special flags to indicate this

   remote=10.0.0.1, remote_port=25 -> SA [specific ports, addresses]

then this is actually a shorthand notation for "static policy"

   remote=10.0.0.1, local_port=1, remote_port=25 -> SA1
   remote=10.0.0.1, local_port=2, remote_port=25 -> SA2
   remote=10.0.0.1, local_port=3, remote_port=25 -> SA3
   ...
   ...
   remote=10.0.0.1, local_port=65534, remote_port=25 -> SA65534
   remote=10.0.0.1, local_port=65535, remote_port=25 -> SA635535

and thus when a connection is opened, one possible traffic selector
will be

   protocol      : *
   remote_address: 10.0.0.1
   local_address : *
   remote_port   : 25
   local_port    : 34568

=================================

The TS contains the information from this "static policy"?

TS also defines the granularity of SA's. How much complexity is
really needed for the TS? I there really more needed except

  protocol   : any or specific
  remote_port: any or specific
  local_port : any or specific
  proxy_addr : any, specific, range

You may need another "proxy_addr", if you want to automatically
negotiate the SA to the other direction.

To explain, how proxy comes into play with tunnel mode (assuming my
side is host):

  remote=10.0.0.0/8 -> SG-SA1   

would get TS

  protocol: *
  remote_port: *
  local_port: *
  local_proxy_addr: * (or N/A)
  remote_proxy_addr: 10.0.0.0/8

however, again with dynamic policy

  remote=10.0.0.0/8 -> SG-SA [host specific]

is actually

  remote=10.0.0.1 -> SG-SA1
  remote=10.0.0.2 -> SG-SA2
  remote=10.0.0.3 -> SG-SG2
  ...

and an example of TS in this case would be

  protocol: *
  remote_port: *
  local_port: *
  local_proxy_addr: * (or N/A)
  remote_proxy_addr: 10.0.2.3

==================

What this leads? You can't really just look a the actual policy
selectors on some implementation. They are implementation
specific. Perhaps the "static selector" is something more
deterministic?