Re: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-00.txt

Hi Tero, We have one working group draft dealing with new ESP-null implementations. We have another draft dealing with unchanged ESP-null implementations. I suggest we don't confuse everybody by adding a third category: just-a-little-tiny-bit changed implementations. In other words, I think the

Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt

04, 2009 19:39 To: Yaron Sheffer Cc: Yoav Nir; ipsec@ietf.org Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt Hi Yaron, Its clear that critical bit refer to the payload, than to its content. Point well taken. But i am not able to understand why we can't define critical

[IPsec] IKEv2 bis section order

Hi, RFC 4306 has an extremely long introductory section, which basically contains a normative description of the main protocol exchanges. In v2bis, we tried to stick to the original section order, but I think that making a change here would make the document much more understandable, especially

[IPsec] AES-CTR - call for volunteers

Hi, While working on the Roadmap document, Sheila and Suresh found out that the use of AES-CTR in IKEv2, although a SHOULD is RFC 4307, is not well defined anywhere (it *is* defined for IKEv1). We had some off list discussion, and came to the conclusion that a short document is needed here. If

[IPsec] IPsec-related academic papers

Hi, I took an initial stab at getting together a collection of recent academic papers that deal with IKE/IPsec. It is now on the IPsecME wiki http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/AcademicPapers . This is at the top of the page: The list below is by no means exhaustive. It

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt

Hi Pasi, Thanks for your review. Please see my comments below. Yaron -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of pasi.ero...@nokia.com Sent: Friday, May 29, 2009 21:47 To: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call:

Re: [IPsec] Next Header field in WESP header

Hi Tero, I agree that the HdrLen and TrailerLen fields MUST be 0 for encrypted WESP. So yes, we use WESP for encrypted traffic to get: - Extensibility (with the 8-bit Flags field). - A single protocol that can do both cases. Thanks, Yaron -Original Message- From:

[IPsec] Redirect -09 comments

Hi, While preparing to progress the draft to AD review, I reread it once again. Here are a few comments. Although not all are nits, none of them should block the document now. Thanks, Yaron Not-quite-nits: General: a long way back we discussed loop avoidance, but this

[IPsec] Issue #105, was: Draft minutes from the 2009-05-05 interim meeting

Session Resumption [...] Gabriel: Pasi had a draft on bypassing PK operations in certain EAP-based auth exchanges, what is the implication with resumption (assuming such an approach were resurrected)? We recently resurrected this draft,

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

Actually I'm suggesting to drop it altogether. Thanks, Yaron -Original Message- From: Grewal, Ken [mailto:ken.gre...@intel.com] Sent: Monday, May 04, 2009 20:43 To: Yaron Sheffer; ipsec@ietf.org Subject: RE: Issue #93: Next header value in tunnel mode for WESP Hi Yaron

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-08

3) Section 6, 1st paragraph: I think this text needs to be clearer about whether an IKE_SA is created or not (current the SHOULDs etc. make this somewhat unclear). IMHO if the client will always just close the IKE_SA, it doesn't make much sense to create it in the first place? But it

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

Yaron: 3.3.2: there is no explanation here or elsewhere that the D-H transform for ESP and AH is used for PFS. Paul (off list): Not done. I don't think it belongs in 3.3.2, and I also don't agree that the transform is the D-H transform for ESP and AH is used for PFS; that's an

[IPsec] Issue #58: Access control: add ref to IPsec architecture

Yaron: 3.5: this section is extremely liberal on what access control policies people can implement, but that's too late to change now. However, we CAN at least add a reference to RFC 4301, Sec. 4.4.3.1 (as was done in RFC 4945, pki4ipsec). Paul: Not done, take to the list. Yaron: I propose to

[IPsec] Virtual interim meeting agenda

Hi, As you recall, we are meeting on Tuesday 5/5, 15:00 GMT, 11:00 EDT, 8:00 PDT. Below is the meeting agenda. Document editors, please confirm your participation or let us know if you are unable to make it into the call. And please send us your slides by Monday, so we can post them on the

[IPsec] Preparing for the virtual interim meeting next week

Hi, Here's to remind you of the meeting we are holding next Tuesday, May 5. Please visit the ipsecme WG wiki (http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki) for exact details on the meeting. Make sure you download the conferencing client and try to connect to the host in advance of the call

[IPsec] Issue #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP

o Implementations MUST process received UDP-encapsulated ESP packets even when no NAT was detected. o The original source and destination IP address required for the transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) are obtained from the

[IPsec] Issue #13: INVALID_MAJOR_VESION similar to other notifies being discussed

{{ Clarif-7.7 }} There are two cases when such a one-way notification is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are sent outside of an IKE_SA. Note that such notifications are explicitly not Informational exchanges; these are one-way messages that

[IPsec] Issue #36: Interaction of IKE_SA_INIT retransmissions with specific notifies

IKE is a reliable protocol, in the sense that the initiator MUST retransmit a request until either it receives a corresponding reply OR it deems the IKE security association to have failed and it discards all state associated with the IKE_SA and any CHILD_SAs

[IPsec] Issue #37: UNSUPPORTED_CRITICAL_ERROR during initial IKE_INIT

2.5. Version Numbers and Forward Compatibility ... IKEv2 adds a 'critical' flag to each payload header for further flexibility for forward compatibility. If the critical flag is set and the payload type is unrecognized, the message MUST be rejected and the response to

[IPsec] Issue #54: PFKEY: categorization

Yaron: 2.9: I believe it is more appropriate to describe PFKEY as an API, rather than protocol. Paul: Not done, for the list. smime.p7s Description: S/MIME cryptographic signature ___ IPsec mailing list IPsec@ietf.org

[IPsec] Issue #79: Remove CP from Create_Child_SA ?

Yoav: Patricia noted in a post to the IPsec mailing list (12/12/2008) that section 2.19 says that request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload. IMO the normal way of doing things

Re: [IPsec] Issue #98: 1 or two round trips for resumption

, can you clarify why this would work better if we had a 2 RT protocol? Thanks, Yaron -Original Message- From: Tero Kivinen [mailto:kivi...@iki.fi] Sent: Tuesday, April 21, 2009 14:53 To: Narayanan, Vidya Cc: Yaron Sheffer; Paul Hoffman; IPsecme WG Subject: Re: [IPsec] Issue #98

Re: [IPsec] Issue #98: 1 or two round trips for resumption

[As a coauthor of this draft:] Hi Vidya, Can you please give a more detailed description of this use case, where: - The gateway doesn't care about CPU consumption, to the extent where it doesn't mind the extra DH+RSA operations for thousands of simultaneously arriving clients, and, - The number

[IPsec] FW: I-D Action:draft-eronen-ipsec-ikev2-eap-auth-06.txt

Hi everyone, We have revived this draft that specifies how to do IKEv2 authentication using EAP only, and no certificates. This can be very useful for mutually authenticating EAP methods, like EAP-AKA (RFC 4187) or our proposed EAP-EKE (http://tools.ietf.org/html/draft-sheffer-emu-eap-eke). At

Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go?

? Definitely _ From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Scott C Moonen Sent: Thursday, April 02, 2009 3:48 PM To: Yaron Sheffer Cc: IPsecme WG Subject: Re: [IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go? From Appendix C: The specification does

[IPsec] Issue #2: Where does N(SET_WINDOW_SIZE) go?

From Appendix C: The specification does not say which messages can contain N(SET_WINDOW_SIZE). It can possibly be included in any message, but it is not yet shown below. SF discussion: Paul said, wherever you wish. smime.p7s Description: S/MIME cryptographic signature

[IPsec] The next batch of issues

Hi everyone, Fresh after shaking off the jet lag from San Francisco, here's a new batch of IKEv2-bis open issues, all of which we introduced at the face to face meeting. Please review them and respond within a week, until April 10. I have included for each issue the original issue

[IPsec] Issue #61: Security considerations - admission control

Yaron: Additional proposed text for the Security Considerations: Admission control is critical to the security of the protocol. For example, IKE trust anchors must be separate from those used for other forms of trust, e.g. to identify trusted Web servers. Moreover, although IKE

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

Hi Vijay, I'd rather be consistent with IKE, i.e. send an explicit DELETE. I suggest to change the -04 text: Once the client sends an acknowledgement to the gateway, it SHOULD delete the existing security associations with the old gateway by sending an Informational message with a DELETE

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

is clear and useful. -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer Sent: Wednesday, February 25, 2009 2:34 PM To: IPsecme WG Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04

...@ietf.org] On Behalf Of Yaron Sheffer Sent: Monday, February 16, 2009 11:46 To: IPsecme WG Subject: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-redirect-04 This is a 2 week working group last call for draft-ietf-ipsecme-ikev2- redirect-04. The target status for this document is Proposed

Re: [IPsec] WESP questions

This is worthy of a TRAC issue. Yaron -Original Message- From: Dan McDonald [mailto:dan...@sun.com] Sent: Thursday, February 19, 2009 16:29 To: Yaron Sheffer Cc: ipsec@ietf.org Subject: Re: [IPsec] WESP questions On Wed, Feb 18, 2009 at 11:00:26PM +0200, Yaron Sheffer

Re: [IPsec] WESP questions

[snip] 2.) Is it permitted to use non-NULL encryption with WESP? I'm hoping the answer is NO, but I didn't see any such language in the November 2008 draft. I previously commented on the current draft that WESP had better support both null and non-null encryption. Much

[IPsec] Meeting minutes posted

Hi, I have posted the interim meeting minutes (with Tero's corrections) on the wiki: http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/Interim20090203Minutes Thanks, Yaron Email secured by Check Point ___ IPsec mailing list

<    1   2   3   4   5