Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails

pasi.ero...@nokia.com writes: > What do you think of the proposed text here? > http://www.ietf.org/mail-archive/web/ipsec/current/msg04096.html The NO_ADDITIONAL_SAS error should be added to the error list, and I am not completely happy with the last paragraph, i.e. it could be expanded bit more t

Re: [IPsec] Reopening issue #12

pasi.ero...@nokia.com writes: > Tero Kivinen wrote: > > > > But now Bob cannot meet the requirement "new SA MUST NOT be narrower > > > than the old one", because it would violate his policy. > > > > This depends which happens first, algorithm selection or narrowing. In > > most cases the first th

Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails

Yaron Sheffer writes: > Hi Pasi, > > Tero's mail gives a clearer explanation of the situation than your proposed > text. Gluing the two together, how about replacing your last paragraph with: > > If the failure is related to creating the IKE SA (for example, > AUTHENTICATION_FAILED), the IKE_SA i

Re: [IPsec] Issue #57: Clarify D-H transform

Yaron Sheffer writes: > Hi Tero, > > Sec. 3.3.2 mentions that you negotiate a D-H group for ESP/AH, even though > you only need encryption and integrity transforms for these protocols. I > find it confusing, certainly for newcomers. For clarity, I suggest to add > after the table in Sec. 3.3.3, th

Re: [IPsec] Reopening issue #12

Tero Kivinen wrote: > > My main concern was whether this (new SA MUST NOT be narrower than > > old one, but MAY be wider) is a new requirement compared to RFC > > 4306... > > Does that really matter even if it is new requirement or not? > > Is there something wrong with that requirement, i.e wha

Re: [IPsec] Comments to draft-ietf-ipsecme-ikev2-redirect-08

Vijay Devarapalli writes: > > In section 6 it should be: > > > > (IP_R:500 -> IP_I:500) > > <-- HDR(A,B), SK {IDr, [CERT,] AUTH, > >N(REDIRECT, New_GW_ID,)} > > Fixed all of the above. >

Re: [IPsec] Reopening issue #12

pasi.ero...@nokia.com writes: > I agree that rekeying is currently not very easy to understand. But > e.g. early drafts of ikev2-clarifications (-00 and -01) included some > text wondering about what exactly N(REKEY_SA) means (that is, what is > different when you do/don't include REKEY_SA in CREA

Re: [IPsec] Reopening issue #12

On Tue, May 05, 2009 at 04:01:19PM +0300, Tero Kivinen wrote: > I do not really have strong opinion which way to go, but we either > needs to make sure there is the triggering packet traffic selectors > (which might be problematic if SA was rekeyed because of time) and the > rekey can narrow dow

Re: [IPsec] Comments to draft-ietf-ipsecme-ikev2-redirect-08

Hi Tero, On 5/5/09 4:51 AM, "Tero Kivinen" wrote: >>> Secondly, it is not clear whether the "In such cases" only refers to >>> the cases wher gateway decides to do something (interact with AAA >>> server/ use external authentication server), or in all cases where EAP >>> or multiple authenticatio

[IPsec] Resumption and NAT detection and changing ports

When should we switch to port 4500 if NAT is detected. I assume we change ports just after IKE_SESSION_RESUME exchange, before going to IKE_AUTH, just like in IKE_SA_INIT case too? That should be mentioned in the draft too. -- kivi...@iki.fi ___ IPsec m

Re: [IPsec] [IKEv2] IKE_AUTH without TSi, TSr

Yoav Nir wrote: Hi Raj Matt is correct. There is no way in IKEv2 to do a phase1-only exchange, and then wait for traffic to establish the child SAs. While we do establish an IKE SA if the piggy-backed child SA failed for whatever reason (bad selectors, no proposal chosen), we don't allow

Re: [IPsec] Reopening issue #12

Dan McDonald described a worse case scenario. It had the advantage that communication that could continue did continue. It had the disadvantage that the traffic to port 2112 got delayed because we needed the packet contents to get the policy right. This is bad due to the delay. It required spec

Re: [IPsec] Issue #93: Next header value in tunnel mode for WESP

Yaron Sheffer wrote: Hi Ken, It seems to me this field is more trouble than it's worth. We are assuming that the hardware will be enforcing a very simplistic security policy (don't care if it's Tunnel or Transport, don't care if it's a TCP SYN or not etc.) and that the hardware is unable to perf

[IPsec] Recording of today's interim WG meeting

... is available at ; it's about 90 megabytes (90 minutes). We will leave the slides from the meeting up at --Paul Hoffman, Director --VPN Consortium

[IPsec] Draft minutes from the 2009-05-05 interim meeting

Please review the minutes and let us know if there are any omissions or inaccuracies. Please DO NOT use this thread to comment on the actual issues. --Paul Hoffman IPsecME WG interim meeting 2009-05-05 Agenda was bashed Roadmap hasn't been updated recently, but is expected to be soon, t

Re: [IPsec] Resumption and NAT detection and changing ports

I agree and will clarify. Issue #106. > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Tero Kivinen > Sent: Tuesday, May 05, 2009 18:48 > To: ipsec@ietf.org > Subject: [IPsec] Resumption and NAT detection and changing ports > > When should