3.3.6 mentions it quite explicitly, and I don't think need to say it again is
3.3.3:
"If the responder receives a proposal that contains a Transform Type it does
not understand, or a proposal that is missing a mandatory Transform Type, it
MUST consider this proposal unacceptable; however, other
Yaron Sheffer writes:
> Hi Tero,
>
> I was ready to accept your answer, until I came across the following
> sentence in -07.
>
> "Payloads are processed in the order in which they appear in an IKE
> message by invoking the appropriate processing routine according to
> the "Next Payload" field in
Jerome A. Solinas writes:
> We would recommend keeping the same numbers (19, 20, 21) since it
> appears that all existing implementations have made the correction.
Not true.
For example our QuickSec OEM IPsec toolkit did originally use only X,
but then some vendor complained that RFC4753 uses bo
Yaron Sheffer writes:
> The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might
> be helpful.
>
> Here's a first shot (we'll need to add some descriptive text):
>
> SA Payload
> |
> ---...
Paul Hoffman writes:
> Ditto for Proposal #2: is there a good reason for you to not have
> included an INTEG transform?
Proposal #2 is the combined mode cipher, thus it cannot have INTEG
other than none, and I though we agreed that it would be better to
leave the whole INTEG transform out in those
On Jan 22, 2010, at 11:57 PM, Yaron Sheffer wrote:
> The text in 3.3 requires "peace of mind" to fully appreciate. A diagram might
> be helpful.
>
> Here's a first shot (we'll need to add some descriptive text):
>
>SA Payload
>|
>
Yaron Sheffer writes:
> 2.21.: EAP Failure cases are missing altogether. Also, the first
> paragraph says that if an auth failure occurs at the responder,
> AUTHENTICATION_FAILED is included in the protected response (to
> IKE_AUTH),
Yes.
> while the last paragraph says it's a separate
> Informat
Yoav Nir writes:
> Issue #138 - Calculations involving Ni/Nr
> =
> Section 2.14: "only the first 64 bits of Ni and the first 64 bits of
> Nr are used in the calculation". This section has two calculations
> involving Ni/Nr, but this sentence should only apply
Valery Smyslov writes:
> I would suugest replacing current text from draft-07:
>
>For ESP and AH, a single Child SA negotiation results in two security
>associations (one in each direction). Keying material MUST be taken
>from th
On Jan 25, 2010, at 1:44 PM, Tero Kivinen wrote:
> Yoav Nir writes:
>
>> Issue #141 - Silently deleting the Child SA after a CHILD_SA_NOT_FOUND
>> ==
>> Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND
>> notification SH
Yoav Nir writes:
> I'm sorry I just noticed this, but is this even allowed? Can you
> include multiple key length attributes in the same transform?
Yes, you are right, you cannot include multiple key length attributes,
as they would be AND for all of them. So yes, they need to be separate
transfo
Section 4 lists conformance requirements for IKEv2 implementations.
First, the following text:
Every implementation MUST be capable of doing four-message
IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
one for ESP or AH).
is formally incorrect, because IKE_AUTH r
12 matches
Mail list logo
