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

Re: IBM VPN Bakeoff Issues

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


>>>>> "Scott" == Scott G Kelly <skelly@redcreek.com> writes:
    >> What was agreed to back then was that for a _security gateway_, any
    >> transit traffic MUST be in tunnel mode so that in IP AH ESP IP <foo>
    >> both AH and ESP would be in tunnel mode. Steve Kent noted that this is

    >> not required by the Arch Doc (but I guess it's not forbidden
    >> either). So if that's the way a security gateway negotiates it why
    >> would we want to do something different for an end host? Aren't these
    >> things complicated enough?
 
    Scott> I *just* received this one, else I would have addressed it in my
    Scott> last post on this topic. I guess I understand your issue here: the
    Scott> architecture doc says that SGWs must use tunnel mode unless they
    Scott> are terminating the flow, and you don't think the SGW is doing
    Scott> that. I think it is. It's terminating the ESP tunnel, so it's okay
    Scott> to use transport mode AH on that flow.

  I think you are mincing words to say the same thing, but I realize that
this is relevant to IKE:
	Dan says:
		IP1 AH ESP IP2 <foo>

	AH - tunnel mode
	ESP- tunnel mode
  Which I would understand to mean:
		IP1 AH IP2 ESP IP3 <foo> 

  But, if IP1 is identical to IP2, there is really no point in putting them
both there. However, I think this heuristic is not specified anywhere, and
it is a bit more complicated than that due to the unique processing of AH
headers. 
(tell me if I'm wrong)

  Scott says that we should describe this sequence as:
	AH - transport mode for ESP SG1/SG2
	ESP- tunnel mode for IP2

  Which more directly translates into the desired pattern.

    Scott> This cuts across the earlier thread here about whether ESP/AH are
    Scott> suitable protocols for the 'transport protocol' selector
    Scott> designation. I guess at this point I'd argue that ESP *is* a
    Scott> transport protocol, while AH might more likely be simply an IP
    Scott> extension header, like IP options.  If we grant that ESP is a

  I think this is a good characterization.

    Scott> I recognize that this is a bit of a twisted web here, but I think
    Scott> you're asking that we agree on a convention which is
    Scott> unnecessary. Waddayathink?

  Some agreement is necessary, as it is necessary that IKE have a clear 
order for presenting transforms in a proposals: inner->outer or outer->inner.

   :!mcr!:            |  Network and security consulting/contract programming
   Michael Richardson |         Firewalls, TCP/IP and Unix administration
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
 Corporate: http://www.sandelman.ottawa.on.ca/SSW/
	ON HUMILITY: To err is human, to moo bovine.





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

iQB1AwUBNkSOsdiXVu0RiA21AQHRLAL/Y2W8A2a4eRZuMHti7rHkUunyDuLIGqNP
69qxn2wuUAYGG5yassITrc+1fPV+U4+B5AsmEW4mRNGkEHnhZHboCYhed3LokFeb
in4yPljsM1AIopVpUf3NC859GVTiOiFl
=hQwK
-----END PGP SIGNATURE-----
References: