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

Re: deleting bundles (Re: SA byte lifetime)

To: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Subject: Re: deleting bundles (Re: SA byte lifetime)
From: itojun@iijlab.net
Date: Fri, 22 Sep 2000 00:31:40 +0900
cc: "Shoichi 'Ne' Sakane" <sakane@ydc.co.jp>, joern.sierwald@F-Secure.com, ipsec@lists.tislabs.com
In-reply-to: Ari.Huttunen's message of Thu, 21 Sep 2000 18:01:04 +0300. <39CA22B0.F1403932@F-Secure.com>
Sender: owner-ipsec@lists.tislabs.com


>We were discussing this in the San Diego interop Wednesday. No consensus
>emerged, but here's what I think.
>
>Imagine AH/ESP/IPCOMP (IPCOMP innermost). It seems to me that
>a) you should forbid using IPCOMP without a preceeding AH or ESP header

	my understanding is the opposite, I say IKE should not forbid it.
	having such knowledge into IKE protocol itself looks wrong to me.
	I don't think "IPCOMP must come with AH or ESP" belong to IKE spec,
	it belongs to elsewhere like your IKE policy.  if you reject certain
	combination of phase 2 proposal based on your policy (or intentionally
	reject it), that's no problem for me.

>b) you might allow using well-known CPI values, using Hugh Redelmeyer's
>   proposal of identifying the exact instance by the enclosing SA

	There were two strawpoll targets; (1) okay to negotiate with well-known
	CPI value, but don't negotiate lifetime and other attributes
	(2) identify IPCOMP with wellknown CPI as part of bundle.
	I would like to put another one: (3) for IKE negotiation wellknown CPI
	should not be used in IKE proposal, use >256 values.
	(3) looks similar to (1), but simpler.

itojun

References:

deleting bundles (Re: SA byte lifetime)

From: Ari Huttunen <Ari.Huttunen@F-Secure.com>

Prev by Date: RE: ISAKMP Delete Payload (2)
Next by Date: Re: ISAKMP Delete Payload (2)
Prev by thread: deleting bundles (Re: SA byte lifetime)
Next by thread: RE: SA byte lifetime
Index(es):
- Main
- Thread