Re: [IPsec] IKEv2 bis section order

Hi Team, I think we can have Introduction and IKE Protocol View [today's Sec. 1.2-1.5] as Section 1 and move Usage scenario to IKE Protocol Details and Variations. Usage scenario can make more sense after brief protocol description and it's difference with IKEv1. Regards, Raj On Thu, Jul 2, 2009

Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-11.txt

Hi Raj, That is exactly what I am saying. Two things: 1. permitting redirects during Init exchange (you have no choice when the destination is anycast) 2. usage of anycast These two are not serving any special purpose here instead it creates more problem. Thanks Padmakumar On Thu, Jul 2, 2009

Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-11.txt

Hi Padma, By having a policy for MAX no of re-direct means when spoke reaches max no of re-directs it will come to know that either it is under attack or there is some misconfiguration. Then spoke can choose to stop trying connection with anycast address and fall back to some other VPN gateway for

Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-11.txt

Hi Raj, The case I mentioned is with usage of redirect during init exchange destined to anycast. The router that tries to resolve the anycast address has no clue about this as it is syntactically same as that of unicast. But an attacker who has access to the link, precisely where anycast resolution

Re: [IPsec] IKEv2 bis section order

At 7:36 PM +0300 7/1/09, Yaron Sheffer wrote: >I'd like to propose: > > 1. Introduction > 1.1. Usage Scenarios > 1.1.1. Security Gateway to Security Gateway Tunnel Mode > 1.1.2. Endpoint-to-Endpoint Transport Mode > 1.1.3. Endpoint to Security Gateway Tunnel Mode >

Re: [IPsec] FW: IPSec responder cookie

At 11:22 AM +0530 7/1/09, Mohini Kaur wrote: >I have a doubt regarding the value of Responder cookie in ISAKMP protocol. > >When I read RFC 2408, Sec 2.5.3, it tells that the initiator and responder >cookie must be set to a random value. That section does not say that at all. It says "The details

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

Hi all. This is the fourth iteration of this draft. New in this iteration - Another co-author - Changed the name, so that this item is considered in the rechartering discussion - Fixed some notation and some discussion based on comments from the list Yoav

[IPsec] Stockholm meeting - call for agenda items

Hi everyone, First, some background: We will not start the formal rechartering process until after the face-to-face meeting, when enough documents have made sufficient progress. However we wanted to use the meeting for short presentations of documents that you believe should be included in the new

[IPsec] IKE's DH groups 19-21, NIST, FIPS 140-2, etc.

RFC 4753 documents that the shared secret obtained from an ECP Diffie-Hellman operation is the concatenation of the x and y coordinates of the derived point. Is that correct? That is a little strange to me, which is why I want to double check. The y coordinate is simply a dependent variable,

Re: [IPsec] IKEv2 bis section order

Yaron, Your proposed reordering seems fine to me. I agree with moving section 1.7 to an appendix. Moving sections 1.2-1.5 to sections 2-2.4 does not add a great deal of value, but does make sense. I think either way is fine. I have no preference realtive to the section 1.2-1.5 move. Dave Wier

[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] 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 to

Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-11.txt

Hi Padam, It possible and avoidable by configuring a policy on client for MAX no. of REDIRECTs. Draft has a mention of this scenario in Section 10. With Regards, Raj On Wed, Jul 1, 2009 at 4:24 PM, Padmakumar AV wrote: > Hi Vijay, > > I have a doubt regarding the usage of redirect during INIT

Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-11.txt

Hi Vijay, I have a doubt regarding the usage of redirect during INIT exchange. An attacker in between spoke and hub spoofs the init exchange to anycast address and then redirects it to another FAKE-HUB1 by specifying unicast address of the FAKE-HUB1. FAKE-HUB1 subsequently redirects it to FAKE-HU