[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multiple payloads via "ID_LIST"

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Roy" == Roy Pereira <rpereira@TimeStep.com> writes:
    Roy> I don't think this is a major problem, but it would 'be nice to
    Roy> have' the ability to set up one SA instead of multiple for the exact
    Roy> same policy.  Instead of waiting for 'x' * 'y' seconds to establish
    Roy> 'y' SAs, the user would only have to wait 'x' seconds.  The key is
    Roy> that the exact same policy is being used, so the subsequent
    Roy> QuickModes are superfluous because they are negotiating the exact

  As such, we should define this.
  However, we should realize that this isn't important enough to justify
rev'ing IKE for it. We have extension mechanisms to deal with this.
  So, let's agree that it is desireable, and try and figure out how to
create a new IKE payload that can be used for this kind of thing.

  I think that the following requirements may outline the problem:
	1. filter on source address+mask
	2. filter on destination address+mask
	3. filter on protocol field/next-header
	4. filter on TCP port number, > = <
	5. filter on UDP port number, > = <
	6. filter on ICMP type and code
	7. filter on AH SPI#
	8. filter on ESP SPI#
	9. filter on IPComp CPI#
	10. take the complement of 1-9
	11. take the intersection of 1-10
	12. take the union of 1-11

  things that might be missing:
	- IP options/extension headers, presence/absense of any, or 
		presence of a specific one
	- 

  Now, some of these may in fact be missing from the [Arch] document. 
I know that ICMP is, as is ranges on port numbers, and also the SPI/CPI
stuff.
  One way to form a more general solution is to go for a more generic
solution and use some kind of statement like "byte offset 4 > 5", but that
gets messy, and if you want to go that route, you might as well use a full
Packet Description Language.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
 Corporate: <A HREF="mailto:mcr@solidum.com">mcr@solidum.com</A>. 





-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBNhJhDtiXVu0RiA21AQHSjQL/Xkfy7KnlX47AmW0v/60WMOJfUbUZ12dL
te50gBMh5mY68Vke6DNX6hQ00uPaCZbz8VZervXT2zdzChQBh+99yhoIcLOGquC1
ejCc0f7IuxtyLIqqc+lId04lQqucka9i
=maIi
-----END PGP SIGNATURE-----
References: