[Openswan dev] Re: per-X controls

Michael Richardson mcr at sandelman.ottawa.on.ca
Sun May 21 13:40:27 CEST 2006

Hash: SHA1

{answering some old email... sorry}

>>>>> "Herbert" == Herbert Xu <herbert at gondor.apana.org.au> writes:
    >> For instance, it is now difficult to create a template that says
    >> to create a transport-mode SA where the origin port does not
    >> matter, but the destination port does.  I think that an example
    >> is of an L2TP transport mode SA behind a NAT.

    Herbert> I'm not sure that I understand your example correctly.

    Herbert> 1) For the L2TP server case you should already know what
    Herbert> the full selector is since you're receiving a new
    Herbert> connection from the client.  In fact, if you don't know
    Herbert> what the client's source port is you can't create a policy
    Herbert> at all.

  I'm not talking about kernel level things, but rather policy.
    Herbert> 2) For the L2TP client case you already know the server
    Herbert> address which allows you to specify a selector even using
    Herbert> today's pluto configuration language:

    Herbert> leftsubnet= rightsubnet= leftprotoport=udp/0
    Herbert> rightprotoport=udp/1701

  that's says:
	 create an SA with a specific origin port (specified by the

  you can not say:
	 create an SA with %any as the origin port 

  that is because "%any" is implemented as "0"
    >> The problem is that the templates may get instantiated with
    >> various fields filled in or not.
    >> I'm about to introduce new keywords: perhost pertransport (or
    >> "perprotocol") leftperport rightperport

    Herbert> So I'm afraid I don't understand the need for these yet.
    Herbert> Perhaps they're more useful in an opportunistic encryption
    Herbert> setup?

  OE is always /32<->/32. 
  It's policies are always "per-host", and in fact, many of our %trap
policies mean that. But not all.
    >> I would like to express these values to the kernel, such that
    >> appropriate %hold eroutes can be made.  This may require some
    >> revision to the policy interface and to the ACQUIRE interface, so
    >> should occur later. (I would like the ACQUIRE interface to
    >> provide ~96 bytes of the header of the packet that caused the
    >> ACQUIRE, as well as cooked values. This should let us do more
    >> intelligent things later on. 96 gets IPv6 + transport header)

    Herbert> Currently Linux sets the larval state's selector to the
    Herbert> narrowest possible value which lets you identify the
    Herbert> session uniquely.

  Yes. Which works great in the case where you have "perX" as the
policy. There is no better selection. When the case is not perX, then
you have to create a new (broader) SA, an then delete the larval case,
which is fine.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr at xelerance.com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

    "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr

Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Finger me for keys


More information about the Dev mailing list