Valery Smyslov writes:
> 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).
>
>
Hi all. Time for another set of issues.
Issue #142 - Difference from RFC 4718 in rekeying IKE SA
Section 2.25.2, "If a peer receives a request to delete a Child SA when it is
currently rekeying the IKE SA, it SHOULD reply as usual, with a
Hi Tero, Valery,
As much as it would be fun to discuss the conformance criteria (personally I
agree that they are too stringent, and would become even less relevant if we
add things like password-based auth), it is out of scope of the IKEv2-bis
discussion. Referring to the guidelines we agreed
Valery Smyslov wrote:
> And I want to raise one more issue. Section 4 mandates support
> for both PKIX and preshared key for conformant implementation.
> Isnt't it too strong requirement?
This requirement has been in the document for 4+ years.
Unless there is concrete evidence of multiple impl
Hi Tero,
This picture looks correct to me.
Best regards,
Pasi
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of ext Tero Kivinen
> Sent: 25 January, 2010 14:33
> To: Yoav Nir
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] Issue #157: Illustra
Tero Kivinen wrote:
> pasi.ero...@nokia.com writes:
> > - Section 2.23.1: If the responder doesn't find SPD entry for
> > transport mode with the modified traffic selectors, and does a lookup
> > with the original selectors, if it finds an entry for transport mode,
> > can it use it?
>
> I do not
Tero Kivinen wrote:
>
> pasi.ero...@nokia.com writes:
> > - Section 2.25: "A peer that receives a CHILD_SA_NOT_FOUND
> > notification SHOULD silently delete the Child SA": Is this really
> > necessary? I think this notification should only occur in cases where
> > DELETE payload for this Child SA
I don't find current 2.6 confusing, so the path of least effort
would be to leave it as-is. (But I'm not opposed to some editing
if someone is willing to propose text.)
Best regards,
Pasi
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of e
Paul Hoffman wrote:
> >B.1 (Group 1): We may want to add: "Use of this group is NOT
> RECOMMENDED."
>
> Please open a tracker issue for this. Even though this is obvious, it
> is a tad late to be suggesting new normative language.
This "NOT RECOMMENDED" would belong in an update to RFC 4307,
not
Yoav Nir writes:
> Issue #142 - Difference from RFC 4718 in rekeying IKE SA
>
> Section 2.25.2, "If a peer receives a request to delete a Child SA
> when it is currently rekeying the IKE SA, it SHOULD reply as usual,
> with a Delete payload."
pasi.ero...@nokia.com writes:
> Paul Hoffman wrote:
>
> > >B.1 (Group 1): We may want to add: "Use of this group is NOT
> > RECOMMENDED."
> >
> > Please open a tracker issue for this. Even though this is obvious, it
> > is a tad late to be suggesting new normative language.
>
> This "NOT RECOMME
Hi Tero,
Tero Kivinen writes:
> >A minimal IPv4 responder implementation will ignore the contents of
> >the CP payload except to determine that it includes an
> >INTERNAL_IP4_ADDRESS attribute and will respond with the address and
> >other related attributes regardless of whether
pasi.ero...@nokia.com writes:
> Tero Kivinen wrote:
>
> > pasi.ero...@nokia.com writes:
> > > - Section 2.23.1: If the responder doesn't find SPD entry for
> > > transport mode with the modified traffic selectors, and does a lookup
> > > with the original selectors, if it finds an entry for transp
Hi Pasi,
Pasi Eronen writes:
> > And I want to raise one more issue. Section 4 mandates support
> > for both PKIX and preshared key for conformant implementation.
> > Isnt't it too strong requirement?
>
>
> This requirement has been in the document for 4+ years.
>
> Unless there is concrete e
Paul Hoffman writes:
> At 5:05 PM +0200 1/21/10, Tero Kivinen wrote:
>
> All changes made other than the following.
>
> >--
> >
> >Section 2.8.2 there was removed paragraph:
> >
> > However, there is a twist to the other case
Hi Tero, please see below.
Thanks,
Yaron
> -Original Message-
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Monday, January 25, 2010 13:31
> To: Yaron Sheffer
> Cc: IPsecme WG
> Subject: [IPsec] IKEv2-bis comments: 2.17 and onwards
>
> Yaron Sheffer writes:
> > 2.21.: EAP
I have closed the issue, but wanted to post my new text because it rearranges
some of Valery's proposed text. Please reply on this thread if you think I have
muffed it.
A single CHILD_SA negotiation may result in multiple security
associations. ESP and AH SAs exist in pairs (one in each d
Paul Hoffman writes:
I have closed the issue, but wanted to post my new text because it
rearranges some of Valery's proposed text. Please reply on this thread if
you think I have muffed it.
A single CHILD_SA negotiation may result in multiple security
associations. ESP and AH SAs exist i
The IESG has approved the following document:
- 'Wrapped ESP for Traffic Visibility '
as a Proposed Standard
This document is the product of the IP Security Maintenance and Extensions
Working Group.
The IESG contact persons are Pasi Eronen and Tim Polk.
A URL of this Internet-Draft is:
h
Comments should be sent to all of this list, the IESG, and the IAB.
--Paul Hoffman
>From: IESG Secretary
>To: i...@ietf.org, i...@iab.org, paul.hoff...@vpnc.org, yar...@checkpoint.com
>Subject: Internal WG Review: Recharter of IP Security Maintenance and
> Extensions (ipsecme)
>reply-to:
Hasn't this item just been approved by the IESG? Isn't it done?
>
>- A standards-track mechanism that allows an intermediary device, such
>as a firewall or intrusion detection system, to easily and reliably
>determine whether an ESP packet is encrypted wit
1. It's a race condition.
2. It ain't over till it's over - published by the RFC Editor.
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Yoav Nir
> Sent: Tuesday, January 26, 2010 23:28
> To: Paul Hoffman; IPsecme WG
> Subject: Re: [IPsec]
At 11:27 PM +0200 1/26/10, Yoav Nir wrote:
>Hasn't this item just been approved by the IESG? Isn't it done?
>
>
>>
>>- A standards-track mechanism that allows an intermediary device, such
>>as a firewall or intrusion detection system, to easily and reliably
All good points, Valery. Here's another attempt; please check carefully.
A single CHILD_SA negotiation may result in multiple security
associations. ESP and AH SAs exist in pairs (one in each direction),
so two SAs are created in a single Child SA negotiation for them.
Furthermore, Ch
Paul Hoffman writes:
> All good points, Valery. Here's another attempt; please check carefully.
>
>A single CHILD_SA negotiation may result in multiple security
>associations. ESP and AH SAs exist in pairs (one in each direction),
>so two SAs are created in a single Child SA negotia
Yes, but the heuristics document is not standards-track.
Never mind, I'm not trying to nit-pick our charter proposal.
On Jan 26, 2010, at 11:41 PM, Paul Hoffman wrote:
> At 11:27 PM +0200 1/26/10, Yoav Nir wrote:
>> Hasn't this item just been approved by the IESG? Isn't it done?
>> ___
26 matches
Mail list logo
