>>I agree with the wording Tero has provided and I think that is
>>what the intent of the original text was.
>
>We disagree here. The point of hash-and-URL was to prevent people from
sending certs.
We do not disagree. The point of hash-and-URL is to prevent people from
sending certs and it does.
At 10:12 PM -0500 1/19/10, David Wierbowski wrote:
> >At 2:03 PM +0200 1/19/10, Tero Kivinen wrote:
>>>Paul Hoffman writes:
In section 3.6 we have text which says:
Certificate payloads SHOULD be included in an exchange if
certificates are available to the sender u
>At 2:03 PM +0200 1/19/10, Tero Kivinen wrote:
>>Paul Hoffman writes:
>>> In section 3.6 we have text which says:
>>>
>>> Certificate payloads SHOULD be included in an exchange if
>>>certificates are available to the sender unless the peer has
>>>indicated an ability to retrieve
Thanks for the careful review (although co-authors of the document are kinda
expected to do this...). Only two things that stuck out as not done:
- Section 3.13.1: the paragraph about Mobility Header is very
confusing; suggested rephrasing:
Traffic selectors can use IP Protocol ID 135 to matc
At 11:24 AM +0200 1/19/10, Tero Kivinen wrote:
>pasi.ero...@nokia.com writes:
>> - Section 1.5: I noticed the 1st paragraph nowadays (well, since -00
>> of the WG draft) allows sending INVALID_IKE_SPI notification inside an
>> existing IKE_SA. This contradicts a MUST NOT in RFC 4306, and I'm not
>>
At 3:46 PM +0200 1/19/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> Section 1.3.1 now talks about the USE_TRANSPORT_MODE,
>> ESP_TFC_PADDING_NOT_SUPPORTED and NON_FIRST_FRAMENTS_ALSO notifications,
>> and says they can be included, but the packet figure does not include
>> them. Adding them to t
At 2:12 PM +0200 1/19/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> Following things might or might not need to be added to section 1.7
>> (taken from appendix E):
>>
>> [[ Response: I included only some of those. 1.7 is not meant to be
>> exhaustive: it can't be. But I did add a bunch you had s
At 2:00 PM +0200 1/19/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> Also the bullet
>>
>>- Store the original traffic selector IP addresses as real source
>> and destination address in case we need to undo address
>> substitution.
>>
>> needs to be changed to
>>
>>- Store the o
At 2:03 PM +0200 1/19/10, Tero Kivinen wrote:
>Paul Hoffman writes:
>> In section 3.6 we have text which says:
>>
>> Certificate payloads SHOULD be included in an exchange if
>>certificates are available to the sender unless the peer has
>>indicated an ability to retrieve this infor
At 8:57 AM +0200 1/19/10, Yaron Sheffer wrote:
>I agree with Tero, regardless of the discussion we had on where to put the
>tables etc., the document needs to be internally consistent. So we should add
>the new notify types that we're defining in *this* document to the notify
>types table. Lucki
At 4:01 PM +0200 1/19/10, Tero Kivinen wrote:
>I do not think they are different cases.
On further staring at this, I agree, and I agree that your rewording is fine.
Done.
--Paul Hoffman, Director
--VPN Consortium
___
IPsec mailing list
IPsec@ietf.org
Tero Kivinen wrote:
> Should we note something that we know this is against MUST in section
> 3.1, but sending zero initiator SPI is still ok?
Yes, we probably should. Proposed rephrasing of that sentence:
There are no IKE SPI values that would be meaningful to the
recipient of such a noti
> I think it would be better to have the table in 3.10.1 to be complete
> set of notify message types which are used by this document. It does
> not need to include notify message types from other documents or new
> extensions, but it should include everything which is defined in this
> document.
pasi.ero...@nokia.com writes:
> > This is against the text in the section 3.1 which says:
> >
> >o Initiator's SPI (8 octets) - A value chosen by the initiator to
> > identify a unique IKE security association. This value MUST NOT
> > be zero.
> >
> > Was that intentional, i.e.
Paul Hoffman writes:
> In section 2.19 there is FAILED_CP_REQUIRED text twice:
>
>The FAILED_CP_REQUIRED notification is sent by responder in the case
>where CP(CFG_REQUEST) was expected but not received, and so is a
>conflict with locally configured policy. There is no associated
>
Paul Hoffman writes:
> XX In section 2.8 the sentence:
>
> Note that, when
>rekeying, the new Child SA SHOULD NOT have different traffic
>selectors and algorithms than the old one.
>
> is in wrong place, it is after the paragraph talking about IKE SA rekey,
> it should be moved t
Paul Hoffman writes:
> Also the section 1.3.1 has text which perhaps should be removed:
>
>Failure of an attempt to create a Child SA SHOULD NOT tear down the
>IKE SA: there is no reason to lose the work done to set up the IKE
>SA. When an IKE SA is not created, the error message retu
Paul Hoffman writes:
> Section 1.3.1 now talks about the USE_TRANSPORT_MODE,
> ESP_TFC_PADDING_NOT_SUPPORTED and NON_FIRST_FRAMENTS_ALSO notifications,
> and says they can be included, but the packet figure does not include
> them. Adding them to the figure would be easy, but the problem is that we
Removing the whole bit numbering mess, and showing the flags
in the main figure as you suggest, sounds good to me.
(But since nobody has noticed this before -- AFAIK, at least --
perhaps leaving this as-is would also be acceptable...)
Best regards,
Pasi
> -Original Message-
> From: ipsec
Tero Kivinen wrote:
> pasi.ero...@nokia.com writes:
> >There are couple of cases when a node receives a packet it cannot
> >process, but may want to notify the sender about this situation:
> >
> >o If an ESP or AH packet arrives with an unrecognized SPI, it
> > could be because
pasi.ero...@nokia.com writes:
>There are couple of cases when a node receives a packet it cannot
>process, but may want to notify the sender about this situation:
>
>o If an ESP or AH packet arrives with an unrecognized SPI, it
> could be because the receiving node has recently
pasi.ero...@nokia.com writes:
> - Section 3.1: "The bits are defined LSB first, so bit 0 would be the
> least significant bit of the Flags octet." This seems to be exactly
> the opposite of the bit numbering used in the figure above, which
> sounds confusing. Instead of using numbers, we should jus
Paul Hoffman writes:
> Following things might or might not need to be added to section 1.7
> (taken from appendix E):
>
> [[ Response: I included only some of those. 1.7 is not meant to be
> exhaustive: it can't be. But I did add a bunch you had suggested
> that I had missed on my pass. ]]
Can y
Paul Hoffman writes:
> Section "3.10.1. Notify Message Types" should include:
>
>
>TEMPORARY_FAILURE {TBA1}
>See section 2.25.
>
>CHILD_SA_NOT_FOUND {TBA2}
>See section 2.25.
>
> [[ Response: Can't do that: the WG decided we have to leave the
> tables
Paul Hoffman writes:
> In section 3.6 we have text which says:
>
> Certificate payloads SHOULD be included in an exchange if
>certificates are available to the sender unless the peer has
>indicated an ability to retrieve this information from elsewhere
>using an HTTP_CERT_LOOK
Paul Hoffman writes:
> Also the bullet
>
>- Store the original traffic selector IP addresses as real source
> and destination address in case we need to undo address
> substitution.
>
> needs to be changed to
>
>- Store the original traffic selector IP addresses as real source
I agree with the proposed change.
Best regards,
Pasi
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of ext Paul Hoffman
> Sent: 17 January, 2010 18:06
> To: IPsecme WG
> Subject: [IPsec] Issue #134: SAi1 in cookies
>
> In section 2.6.1 it
Paul Hoffman wrote:
> Section 1.5 doesn't read well, and needs a rewrite. Pasi can
> provide text once the substantial issue re: INVALID_IKE_SPI
> is decided.
That substantial issue is #137; assuming it's resolved the way
Tero proposed (and I agree), I'm proposing the following text:
There ar
Tero,
I agree with your analysis (I hadn't noticed that this
doesn't even work).
Best regards,
Pasi
> -Original Message-
> From: ext Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: 19 January, 2010 11:25
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: ipsec@ietf.org
> Subject: INVALID_IKE_SPI
I think the tables should list the values needed to implement *this*
specification; in all cases except here, that's the same as "defined
in RFC 4306", but not in this case.
Best regards,
Pasi
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
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 pair has already been sent, and
>
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 think it can use the transport mo
Somewhat substantial:
- Section 3.13.1: the paragraph about Mobility Header is very
confusing; suggested rephrasing:
Traffic selectors can use IP Protocol ID 135 to match the IPv6
mobility header [MIPV6]. As specified in [IPSECARCH], the IPv6
mobility header (MH) message type is placed
pasi.ero...@nokia.com writes:
> - Section 1.5: I noticed the 1st paragraph nowadays (well, since -00
> of the WG draft) allows sending INVALID_IKE_SPI notification inside an
> existing IKE_SA. This contradicts a MUST NOT in RFC 4306, and I'm not
> sure if it really brings any benefits?
There is no
To clarify, I was only referring to the notifications defined in -bis. Not in
any other documents.
-Original Message-
From: Valery Smyslov [mailto:sva...@gmail.com]
Sent: Tuesday, January 19, 2010 9:35
To: Yaron Sheffer; Paul Hoffman; Tero Kivinen; ipsec@ietf.org
Subject: Re: [IPsec] Not
+1
Anybody who starts implementing IKEv2 in a few months using the new RFC should
not have to care about the history, and which notify type was added at which
point, except to know that some implementations in the field may not support
these newer notifications.
-Original Message-
From
36 matches
Mail list logo
