From paul.hoffman@vpnc.org Fri Nov 2 11:27:59 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAB821F965D for ; Fri, 2 Nov 2012 11:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQj6K0YfmCDF for ; Fri, 2 Nov 2012 11:27:58 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7B521F962F for ; Fri, 2 Nov 2012 11:27:58 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qA2IRrQn043130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 2 Nov 2012 11:27:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 2 Nov 2012 11:27:53 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPsec] ECDSA for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 18:27:59 -0000 Greetings again. Here is the long-sought-after consensus report from the = design team that was tasked with a proposal for better supporting ECDSA = certificates in IKEv2. If you have any concern for this topic, please read the proposal below = and send comments to the list. Thank you to the design team (Tero Kivinen, Johannes Merkle, Dan = Harkins, Yoav Nir, David McGrew) for their efforts. --Paul Hoffman The design team decided it is best to add just one new authentication method, that will support all kinds of signature methods. This includes all ECDSA and other EC-based methods (ECGDSA) and can also support other algorithms too (RSA-PSS or even ElGamal). The EC group is assumed to be known from the certificate or raw key, and there is no need to explicitly negotiate or identify it. The Authentication Data field in the Authetication Payload will contain the signature algorithm OID (sha1WithRSAEncryption, dsa-with-sha1, dsa-with-sha256, ecdsa-with-SHA1, ecdsa-with-SHA256 etc) and the actual signature. The design group considered adding full AlgorithmIdentifier ASN.1 blob too big and as the other information (EC group etc) is already known from the certificate or raw key, the only thing needed here is the actual signature algorithm and hash OID. To make skipping the OID easier it is prefixed with 8-bit length field (even though the ASN.1 encoding of the OID has length of oid value in 2nd byte). To select suitable hash function for each EC-group we should refer to the existing guidance (SEC1 and RFC5639), and specify that the method of X9.62, SEC1 and IO 14888-3 MUST be used for hash truncation. We can add some non-normative guidance also in the draft for "common" curves. This new method will be negotiated using the Notify Payloads in the IKE_SA_INIT, and those same payloads can be used to indicate the supported hash algoritms. The old EC-DSA method should be deprecated, but only after the new methods are supported, meaning the document should say that if new method is supported by both ends it SHOULD/MUST be used. ---------------------------------------------------------------------- The Authentication Paylod will look like this: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Method | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Authentication Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Authentication Payload Format o Auth Method (1 octet) - Specifies the method of authentication used. =20 Mechanism Value ----------------------------------------------------------------- Digital Signature Computed as specified in Section 2.15 of RFC5996 using a private key associated with the public key sent in certificate payload, and using one of the hash algoritms sent by the other end in the SIGNATURE_HASH_ALGORITHMS notify payload. If both ends send and receive SIGNATURE_HASH_ALGORITHMS and signature authentication is to be used, then this method MUST be used. The Authentication Data field has different format than in other Authentication methods (see below). o Authentication Data (variable length) - see Section 2.15 of RFC5996. For "Digital Signature" format the Authentication data contains special format as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OID Length | OID (0x06) . OID value len . OID value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ OID value continuing ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Authentication Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the OID Length is the length of the ASN.1 encoded OID value, and after that is the actual Signature Algorithm OID followed by the actual signature value. There is no padding between OID and signature value. ASN.1 encoded OIDs always start with byte of 0x06 followed by the length of the actual OID value (which is shown in the figure abow). ---------------------------------------------------------------------- The method is negotiated by sending and receiving SIGNATURE_HASH_ALGORITHMS Notify payload: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol ID | SPI Size | Notify Message Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Security Parameter Index (SPI) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Notification Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Protocol ID is 0, SPI Size 0, and Notify Message Type . The Notification Data value contains list of 16-bit hash algorithm identifiers from the newly created Hash Algorithm Identifiers for the IKEv2 IANA registry. Sending this notification tells that new "Digital Signature" authentication method is supported and that following hash functions are supported by sending peer. Both ends sends their list of supported hash-algorithms and when calculating signature a peer MUST pick one algorithm sent by the other peer. Note, that different algorithms can be used in different directions. The actual algoritm used when calculating the signature is sent inside the Authentication Data field of the Authentication Payload. From paul.hoffman@vpnc.org Fri Nov 2 18:08:52 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5724421F9BA4 for ; Fri, 2 Nov 2012 18:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ39Q4A9dlcA for ; Fri, 2 Nov 2012 18:08:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C499221F9BA5 for ; Fri, 2 Nov 2012 18:08:51 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qA318lXw053482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 2 Nov 2012 18:08:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <0AE85D37-FC4A-4F4B-A66B-262B19EFF0AA@vpnc.org> Date: Fri, 2 Nov 2012 18:08:47 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPsec] Pre-meeting reading X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 01:08:52 -0000 Greetings again. Here's the agenda for Monday's meeting. Notice how many = of those drafts you have not read? Imagine how much useful our time = together will be if you, and most of the other people in the room or = listening to the audio, had read them all! --Paul Hoffman IPsecME WG Monday, November 5, 2012, 1740-1940 Easiest way to get slides: = http://www.ietf.org/proceedings/85/ipsecme.html Blue sheets, agenda -- 2 mins WG status -- 5 mins draft-ietf-ipsecme-ad-vpn-problem ECDSA design team=09 draft-ietf-ipsecme-ike-tcp -- 15 mins Status report Open issues Next steps draft-kivinen-ipsecme-oob-pubkey -- 15 mins Motivations Description of problem that is being solved Question about whether this updated 5996 to replace RSA raw key = format draft-mcgrew-ipsec-me-esp-ah-reqts -- 15 mins Motivations Description of problem that is being solved draft-zhang-ipsecme-multi-path-ipsec -- 15 mins Motivations Description of problem that is being solved draft-harkins-ikev3 and draft-kivinen-ipsecme-ikev2-minimal -- 15 mins = each Motivations Description of problem that is being solved draft-mglt-mif-security-requirements -- 10 mins Introduction and where to follow up draft-gont-opsec-vpn-leakages -- 10 mins Introduction and where to follow up From mglt.ietf@gmail.com Sat Nov 3 06:46:31 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C77021F9C34 for ; Sat, 3 Nov 2012 06:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFI7gyUKBPv1 for ; Sat, 3 Nov 2012 06:46:30 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3451421F8755 for ; Sat, 3 Nov 2012 06:46:30 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so5093842vcb.31 for ; Sat, 03 Nov 2012 06:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1hijihMYe35qyVopUGvBFTUKkcDMNGDxplim3qoy7rw=; b=C118rIO/AIYbtHXy1WsM0K3vYs04N1Uo45/Qv3zjEWpRAaTGSpu3HBDEoiU3JeHOcJ P9xsWTSxYPt364vy/UmXMDxdYERSLR2d9d32fQ5fqLHhcrFh9cwOG/Zyav6rvWNqpzYh OaRvLwWxOXhc9cK2QjWe7HCb7c/3GjtkFvUPuKCqOpGjKP4i1V3mJPCi1yf2WGipVJjg nDmCxoaUlOyOrk6tC77WRe6YuaEK8e47tO4vPZOVKRqBHSO8TVcbvUCFbQFL8YINmgOQ oU06BHUeOw3o69PG2/zn6DuLqybUQpG4zWtGO3cBmQNxY31d7WIhohmkqNVjfJV7EFZ7 D8Zw== MIME-Version: 1.0 Received: by 10.220.223.13 with SMTP id ii13mr4612921vcb.2.1351950389627; Sat, 03 Nov 2012 06:46:29 -0700 (PDT) Received: by 10.58.155.69 with HTTP; Sat, 3 Nov 2012 06:46:29 -0700 (PDT) In-Reply-To: <0AE85D37-FC4A-4F4B-A66B-262B19EFF0AA@vpnc.org> References: <0AE85D37-FC4A-4F4B-A66B-262B19EFF0AA@vpnc.org> Date: Sat, 3 Nov 2012 14:46:29 +0100 Message-ID: From: Daniel Migault To: Paul Hoffman Content-Type: multipart/alternative; boundary=14dae9cdc84fba4cd004cd977af1 Cc: IPsecme WG Subject: Re: [IPsec] Pre-meeting reading X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 13:46:31 -0000 --14dae9cdc84fba4cd004cd977af1 Content-Type: text/plain; charset=ISO-8859-1 Hi, Here is an updated version of the draft-mglt-mif-security-requirements-03. https://docs.google.com/file/d/0B4Irj7ik6yY1XzBTeVFrUjkxXzQ/edit Best Regards, Daniel On Sat, Nov 3, 2012 at 2:08 AM, Paul Hoffman wrote: > Greetings again. Here's the agenda for Monday's meeting. Notice how many > of those drafts you have not read? Imagine how much useful our time > together will be if you, and most of the other people in the room or > listening to the audio, had read them all! > > --Paul Hoffman > > IPsecME WG > Monday, November 5, 2012, 1740-1940 > > Easiest way to get slides: http://www.ietf.org/proceedings/85/ipsecme.html > > Blue sheets, agenda -- 2 mins > WG status -- 5 mins > draft-ietf-ipsecme-ad-vpn-problem > ECDSA design team > > draft-ietf-ipsecme-ike-tcp -- 15 mins > Status report > Open issues > Next steps > > draft-kivinen-ipsecme-oob-pubkey -- 15 mins > Motivations > Description of problem that is being solved > Question about whether this updated 5996 to replace RSA raw key > format > > draft-mcgrew-ipsec-me-esp-ah-reqts -- 15 mins > Motivations > Description of problem that is being solved > > draft-zhang-ipsecme-multi-path-ipsec -- 15 mins > Motivations > Description of problem that is being solved > > draft-harkins-ikev3 and draft-kivinen-ipsecme-ikev2-minimal -- 15 mins each > Motivations > Description of problem that is being solved > > draft-mglt-mif-security-requirements -- 10 mins > Introduction and where to follow up > > draft-gont-opsec-vpn-leakages -- 10 mins > Introduction and where to follow up > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --14dae9cdc84fba4cd004cd977af1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Here is an updated version of the draft-mglt-mif-security-requi= rements-03. https://docs.google.com/file/d/0B4Irj7ik6yY1XzBTeVFrUjkxXzQ/e= dit

Best Regards,

Daniel

On Sat, = Nov 3, 2012 at 2:08 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
Greetings again. Here's the agenda for M= onday's meeting. Notice how many of those drafts you have not read? Ima= gine how much useful our time together will be if you, and most of the othe= r people in the room or listening to the audio, had read them all!

--Paul Hoffman

IPsecME WG
Monday, November 5, 2012, 1740-1940

Easiest way to get slides: http://www.ietf.org/proceedings/85/ipsecme.ht= ml

Blue sheets, agenda -- 2 mins
WG status -- 5 mins
=A0 =A0 =A0 =A0 draft-ietf-ipsecme-ad-vpn-problem
=A0 =A0 =A0 =A0 ECDSA design team

draft-ietf-ipsecme-ike-tcp -- 15 mins
=A0 =A0 =A0 =A0 Status report
=A0 =A0 =A0 =A0 Open issues
=A0 =A0 =A0 =A0 Next steps

draft-kivinen-ipsecme-oob-pubkey =A0-- 15 mins
=A0 =A0 =A0 =A0 Motivations
=A0 =A0 =A0 =A0 Description of problem that is being solved
=A0 =A0 =A0 =A0 Question about whether this updated 5996 to replace RSA raw= key format

draft-mcgrew-ipsec-me-esp-ah-reqts =A0-- 15 mins
=A0 =A0 =A0 =A0 Motivations
=A0 =A0 =A0 =A0 Description of problem that is being solved

draft-zhang-ipsecme-multi-path-ipsec -- 15 mins
=A0 =A0 =A0 =A0 Motivations
=A0 =A0 =A0 =A0 Description of problem that is being solved

draft-harkins-ikev3 and draft-kivinen-ipsecme-ikev2-minimal -- 15 mins each=
=A0 =A0 =A0 =A0 Motivations
=A0 =A0 =A0 =A0 Description of problem that is being solved

draft-mglt-mif-security-requirements -- 10 mins
=A0 =A0 =A0 =A0 Introduction and where to follow up

draft-gont-opsec-vpn-leakages -- 10 mins
=A0 =A0 =A0 =A0 Introduction and where to follow up

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--14dae9cdc84fba4cd004cd977af1-- From kivinen@iki.fi Sat Nov 3 18:51:53 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3078621F976D for ; Sat, 3 Nov 2012 18:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VR2sNDhxpPt for ; Sat, 3 Nov 2012 18:51:52 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE4F21F9766 for ; Sat, 3 Nov 2012 18:51:50 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA41pkEb009287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 03:51:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA41pjtc010403; Sun, 4 Nov 2012 03:51:45 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20629.51761.388715.484632@fireball.kivinen.iki.fi> Date: Sun, 4 Nov 2012 03:51:45 +0200 From: Tero Kivinen To: draft-ietf-ipsecme-ike-tcp@tools.ietf.org, ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 21 min X-Total-Time: 25 min Subject: [IPsec] Comments to draft-ietf-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 01:51:53 -0000 In the section 1 there is text: ---------------------------------------------------------------------- Specifically, the messages of the IKE_AUTH exchange can become quite large, as they may contain a chain of certificates, an "Auth" payload (that may contain a public key signature), CRLs, and some configuration information that is carried in the CFG payload. ---------------------------------------------------------------------- In addition to the IKE_AUTH there is another big class of UPD packets which can be large, and which might get fragmented, i.e udp encapsulated nat traversal IPsec UDP packets. If the protocol run inside the transport mode IPsec connection sends large packets they may get fragmented too. This should not be problem for TCP, as PMTU should make the packets small enough not to get them fragmented, but if you run some UDP based application then this might be issue. For tunnel mode IPsec traffic, the gateway can fragment inner packets before wrapping them to ESP, so the outer ESP packets visible to nat box are not fragmented. Another thing that should be mentioned here that IKEv2 already have several optional features which will solve the large IKE_AUTH packet problem: the certificate can be replaced with hash and url format; The child sa negotiation can be postponed with childless sa exchange (removes the traffic selectors); Postponing the child sa creation also allows running the cfg mode exchange can be done as separate informational exchange (i.e. removing even configuration payloads from the IKE_AUTH packet); Using elliptic curves instead of RSA will make auth payload smaller. All these optional features should make the IKE_AUTH packet to be less than 300 bytes. I think this document should mention those optional features, as implementing them allows much more efficient protocol than transmitting the IKE_AUTH over TCP. In section "3. Operational Considerations" there is text saying: ---------------------------------------------------------------------- An alternative method, that is probably easier for the Initiator to implement, is to do an entire "mission" using the same transport. So if TCP is needed for long messages and an IKE SA has not yet been created, the Initiator will open a TCP connection, and perform all 2-4 requests needed to set up a child SA over the same connection. ---------------------------------------------------------------------- Note, that NAT detection might not work properly, when IKE_SA_INIT is run over TCP (i.e. over different protocol), especially if IKE_SA_INIT is first tried with UDP, and then retransmitted over different protocol. The IKEv2 RFC5996 says that "A retransmission from the initiator MUST be bitwise identical to the original request." (section 2.1 or RFC5996), which means we cannot modify the NAT_DETECTION_*_IP payloads when switching from UPD to TCP. This might cause NAT to be detected even when there is none there (i.e. the UDP source port is 500, but TCP source port is most likely going to be random). Also I think this document should tell the justifications why the TCP session is not kept alive all the time, but only created for sending one packet and then immediately teared down. I assume the idea there is that open TCP session actually requires quite a lot of resources from the SGW, i.e. maintaining the send and receive windows requires tens of kilobytes of memory. Of course the downside of such short TCP sessions is that sending one exchange over TCP now requires 2 round trips of delay, and most likely around 10 packets, compared to the 1 round trip and 2 packets. -- kivinen@iki.fi From kivinen@iki.fi Sat Nov 3 19:13:36 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579C821F8558 for ; Sat, 3 Nov 2012 19:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r866-MZg9skB for ; Sat, 3 Nov 2012 19:13:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4BD21F853E for ; Sat, 3 Nov 2012 19:13:31 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA42DR8e013060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 04:13:27 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA42DPTJ008131; Sun, 4 Nov 2012 04:13:25 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20629.53061.77451.107237@fireball.kivinen.iki.fi> Date: Sun, 4 Nov 2012 04:13:25 +0200 From: Tero Kivinen To: Masanobu.Katagi@jp.sony.com, ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 20 min Subject: [IPsec] Comments to the draft-katagi-ipsecme-clefia-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 02:13:36 -0000 This document defines clefia ciphers for IKEv1 and IKEv2. I see no point of adding anything to the already obsoleted IKEv1 protocol, so I think it is better to remove all references to IKEv1 from this document (i.e section 3) and IKEv1 parts from section 1 and section 6. We need to be consistent here and reject all additions to IKEv1. Also some of the IKEv1 registries (IPSEC ESP Transform Identifiers) are "Standards Track RFC" required registries, meaning this document would have to be standard track document. The document is currently listed as being informational. In the section 2.4 this document adds CLEFIA-CMAC-PRF-128, in similar way than AES-CMAC-PRF-128 was added. I thought we had already discussion in the ipsec-list about whether any CMAC-PRF for IKEv2 KDF use is safe, but I cannot find it now. I think some cryptographers were saying that CMAC is not good enough for using as KDF (which is where IKEv2 PRF is used for) as its output is not random enough or something. We should really look in to this issue, and see whether we need to deprecate the other CMAC PRFs too. -- kivinen@iki.fi From kivinen@iki.fi Sat Nov 3 19:29:30 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6BA21F936A for ; Sat, 3 Nov 2012 19:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q1CiTka8vpP for ; Sat, 3 Nov 2012 19:29:30 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id C28CD21F851C for ; Sat, 3 Nov 2012 19:29:29 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA42QpBO024667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 04:26:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA42Qigf026631; Sun, 4 Nov 2012 04:26:44 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20629.53860.721523.621998@fireball.kivinen.iki.fi> Date: Sun, 4 Nov 2012 04:26:44 +0200 From: Tero Kivinen To: ynir@checkpoint.com, sunseawq@huawei.com, ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 12 min Subject: [IPsec] Comments to the draft-nir-ipsecme-erx-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 02:29:30 -0000 In Introduction section (1) there is text saying: ---------------------------------------------------------------------- Bringing these two technologies together allows a remote access IPsec client to create multiple tunnels with different gateways that belong to a single domain, as well as using the keys from other contexts of using EAP, such as network access within the same domain, to transparently connect to VPN gateways within this domain. ---------------------------------------------------------------------- I think that is missing one possible use for the EAP Re-authentication Protocol, then one that has been proposed for example in the IEEE 802.11ai. I.e the possibility that the client does full EAP with AAA backend only once, and then reuses that authentication later to recreate the IPsec connection when it was lost for some reason (network problems, device suspending, going out of range etc). I.e. use it in similar ways as resumption protocol can be used, but now the state is stored in the AAA backend, not in the SGW. In section "3. Protocol Outline" there is text saying: ---------------------------------------------------------------------- The responder sends the EAP payload content to a backend AAA server, and receives the rMSK and an EAP-Finish/Re-auth message. It then forwards the EAP-Finish/Re-auth message to the Initiator in an EAP payload within the first IKE_AUTH response. ---------------------------------------------------------------------- There is possibility that even when the client has ERX connection still up, but the backend AAA server might have already destroyed it. This means that it is possible that when initiator sends the first EAP_Initiate/Re-Auth message to the SGW, which forwards it to the AAA server, the AAA server will NOT respond with EAP-Finish/Re-auth message, but simply starts normal full EAP. This should be explained here. It does not really change the actual protocol flow, as AAA server will send EAP packet back, and then the initiator and responder will exchange some number of EAP packets before responder sends the EAP-Finish to initiator and they do the final AUTH exchange. If it is not mentioned here, some implementations might assume they always get EAP-Finish/Re-auth back and not work if the AAA server goes through the full EAP exchange. In section "4. ERX_SUPPORTED Notification" there is text saying: ---------------------------------------------------------------------- o Protocol ID (1 octet) MUST be 1, as this message is related to an IKE SA. ---------------------------------------------------------------------- This is wrong. The RFC 5996 in section 3.10 says: ---------------------------------------------------------------------- o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS and REKEY_SA. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. ---------------------------------------------------------------------- I.e. the Protocol ID MUST be sent as zero if the SPI field is empty. -- kivinen@iki.fi From kivinen@iki.fi Sat Nov 3 19:38:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE60B21F9851 for ; Sat, 3 Nov 2012 19:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF2naY7HXExv for ; Sat, 3 Nov 2012 19:38:03 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id A9E9021F97C5 for ; Sat, 3 Nov 2012 19:38:02 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA42bu1N001573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 04:37:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA42buVH009090; Sun, 4 Nov 2012 04:37:56 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20629.54531.886356.890857@fireball.kivinen.iki.fi> Date: Sun, 4 Nov 2012 04:37:55 +0200 From: Tero Kivinen To: svan@elvis.ru, ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Subject: [IPsec] Comments to the draft-smyslov-ipsecme-ikev2-fragmentation-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 02:38:04 -0000 A general comment: I think we already decided in the WG that we will go with the tcp approach, not with this fragmentation layer in the IKEv2. Why do we have this document here? Some other comments In section 2.5 the header contains "Total Framgments" field. This means the initiator must decide the number of framents it is sending out in the beginning, i.e. it cannot dynamically adjust this if it sees that it is sending so long fragments that they get lost. It would be better to use standard way of doing this, i.e. sending the offset to the start of the fragment, and some kind of indication whether this was last fragment or not. Also it is not clear how retransmission is done here at all. I assume we will send all fragments in case of the retransmission, but again we cannot adjust the fragment size to be smaller, even if we start to suspect that there is something between which is eating our fragments. Only way to do that would be to delete the IKE SA and start over with lower fragment size parameter (as it is possible that the responder did got some of the fragments, for example last one, which was small enough, and as we only have fragment number, not offset we cannot know at which offset that packet belongs to). -- kivinen@iki.fi From kivinen@iki.fi Sat Nov 3 19:57:20 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8027421F8D78 for ; Sat, 3 Nov 2012 19:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0j4KFYe+8JT for ; Sat, 3 Nov 2012 19:57:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 86B7921F8C71 for ; Sat, 3 Nov 2012 19:57:17 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA42vCjU025612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 04:57:12 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA42vBL2008950; Sun, 4 Nov 2012 04:57:11 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20629.55687.641230.919667@fireball.kivinen.iki.fi> Date: Sun, 4 Nov 2012 04:57:11 +0200 From: Tero Kivinen To: vzhang2008@yahoo.com, tina.tsou.zouting@huawei.com, liushucheng@huawei.com, ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 19 min X-Total-Time: 18 min Subject: [IPsec] Comments to the draft-zhang-ipsecme-multi-path-ipsec-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 02:57:20 -0000 In section 4 this draft claims: ---------------------------------------------------------------------- The method enhances the security service by spreading the traffic onto multiple paths. ---------------------------------------------------------------------- I do not think the multiple paths really enhances the security. Also as the sequence number in sending and receive window handling is different (it is shared with all sub-SAs) this feature must be negotiated between the peers. The claim: ---------------------------------------------------------------------- For example, it makes it harder for the attacker to intercept all the packets if different routes are used. ---------------------------------------------------------------------- If attacker can intercept and decrypt one path, that is quite often already big enough problem that security is completely lost. Also ---------------------------------------------------------------------- Even with the same route used, it is harder for the attacker to know which set of SAs are clustered SA, thus harder to decrypt the intercepted packets. ---------------------------------------------------------------------- This kind of things are usually very easy to see from traffic analysis. Especially if the packets are round robined over the all sub-SAs. Also as the SPI and sequence numbers are in clear, and as sequence number counter is shared between all sub-SAs it is trivial to see which packets belong to the same clustered SA set. Also using different keys to encrypt the different sub-SAs will not add that much to the security. If the underlaying crypto algorithm has 2^128 bits of security, splitting the data over for example 4 sub-SAs will simply add 2 more bits of security. On the other hand it is usually much better for attacker to attack the IKEv2 negotiation itself (the Diffie-Hellman etc), as those most likely have less security than the symmetric crypto used to protect the data, and if that can be broken then that will also reveal all sub-SA keys. In section 6 there is text saying: ---------------------------------------------------------------------- SA cluster provides the option to perform the different cryptographic transformation on the different packet. ---------------------------------------------------------------------- which actually lowers the security. If one sub-SA uses DES and another uses 3DES, the overall security is lowered to the level of DES... Even if both algorithms are supposed to have same strength (AES, CAMELLIA etc) that does not mean that they in practice have exactly same security. In this case attacker will attack the weaker algorithm and again gains benefits over than if same stronger algorithm was used on all of the data. -- kivinen@iki.fi From paul.hoffman@vpnc.org Sun Nov 4 05:29:43 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6801421F85F3 for ; Sun, 4 Nov 2012 05:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0XUPVKduy9w for ; Sun, 4 Nov 2012 05:29:43 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AEDD221F8500 for ; Sun, 4 Nov 2012 05:29:41 -0800 (PST) Received: from [10.71.6.93] (173-15-223-105-BusName-Atlanta.hfc.comcastbusiness.net [173.15.223.105]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qA4DTS5X015212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 4 Nov 2012 06:29:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20629.54531.886356.890857@fireball.kivinen.iki.fi> Date: Sun, 4 Nov 2012 08:29:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <44BCB928-0220-4687-BF60-70C148ACC771@vpnc.org> References: <20629.54531.886356.890857@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1499) Cc: ipsec@ietf.org, svan@elvis.ru Subject: Re: [IPsec] Comments to the draft-smyslov-ipsecme-ikev2-fragmentation-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 13:29:43 -0000 On Nov 3, 2012, at 10:37 PM, Tero Kivinen wrote: > A general comment: I think we already decided in the WG that we will > go with the tcp approach, not with this fragmentation layer in the > IKEv2. Why do we have this document here? We don't. Documents listed as "Related Documents" on the Datatracker = page are just that: related. They are not WG work items. --Paul Hoffman= From cuiyang@huawei.com Sun Nov 4 06:48:41 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6177521F84C5 for ; Sun, 4 Nov 2012 06:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBSSLfQp651I for ; Sun, 4 Nov 2012 06:48:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1B34E21F8476 for ; Sun, 4 Nov 2012 06:48:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMK27591; Sun, 04 Nov 2012 14:48:37 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 4 Nov 2012 14:48:32 +0000 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 4 Nov 2012 14:48:33 +0000 Received: from SZXEML508-MBX.china.huawei.com ([169.254.5.236]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Sun, 4 Nov 2012 22:48:22 +0800 From: Cuiyang To: Tero Kivinen , "vzhang2008@yahoo.com" , Tina TSOU , "Will Liu (Shucheng)" , "ipsec@ietf.org" Thread-Topic: [IPsec] Comments to the draft-zhang-ipsecme-multi-path-ipsec-02 Thread-Index: AQHNujgj2eAmYdhs9UaGO6iBamcN7ZfZvFBp Date: Sun, 4 Nov 2012 14:48:20 +0000 Message-ID: <8CC0CB0BCAE52F46882E17828A9AE21636876DA3@SZXEML508-MBX.china.huawei.com> References: <20629.55687.641230.919667@fireball.kivinen.iki.fi> In-Reply-To: <20629.55687.641230.919667@fireball.kivinen.iki.fi> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.245] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [IPsec] Comments to the draft-zhang-ipsecme-multi-path-ipsec-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 14:48:41 -0000 SSBhbSBhZnJhaWQgdGhhdCBvbmx5IG11bHRpLXBhdGhzIGNhbm5vdCBlbmhhbmNlIHRoZSBzZWN1 cml0eS4NCkFzIFRlcm8gY29tbWVudGVkLCBpZiBvbmUgY2FuIGRlY3J5cHQgb25lIHBhdGgsIHRo ZW4gaXQgaXMgYSBzdWNjZXNzZnVsIHNlY3VyaXR5IGJyZWFjaCBhbHJlYWR5Lg0KSSB0aGluayB0 aGUgcG9pbnQgaXMgdGhhdCB3aGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mICJpbnNlY3VyZSBuZXR3 b3JrIiwgYW5kIHRoZSBkZWZpbml0aW9uIG9mIHRoZSAic2VjdXJpdHkiIGhlcmUuIA0KDQpGcm9t IGEgY3J5cHRvZ3JhcGhpYyBwb2ludCBvZiB2aWV3LCBpdCBtYXkgYmUgaGVscGZ1bCB0byBlbmhh bmNlIHRoZSBwcm90b2NvbCBpbiB0aGlzIHdheS4NClN1Y2ggYXMsIGVuY29kZSB0aGUgb3JpZ2lu YWwgZmxvdyBpbnRvIHBpZWNlcywgd2l0aCBhbiBBbGwtb3ItTm90aGluZy1UcmFuc2Zvcm0gKEFP TlQpLCB3aGljaCBkb2VzIE5PVCByZXF1aXJlIGEgc2VjcmV0IGtleSBhbmQgaGFzIGEgcHJvcGVy dHkgdGhhdCBpdCBpcyBoYXJkIHRvIGludmVydCB1bmxlc3MgYWxsIG9mIHRoZSBvdXRwdXQgaXMg a25vd24uIChPQUVQIGlzIGFuIGV4YW1wbGUsIGluIHRoZSByYW5kb20gb3JhY2xlIG1vZGVsKQ0K VGhlbiwgZW5jYXBzdWxhdGUgdGhlIGVuY29kZWQgZmxvdyBpbnRvIG11bHRpLXBhdGggSVBzZWMg dHVubmVscyBhcyBwcm9wb3NlZC4NClRoaXMgdGltZSwgdGhlIHNlY3VyaXR5IHdpbGwgYmUgZGVm aW5pdGVseSBlbmhhbmNlZCBzaW5jZSB0aGUgYXR0YWNrZXIgd2lsbCBub3QgZ2V0IGFueXRoaW5n IHVubGVzcyBpdCBicmVha3MgY29uZmlkZW50aWFsaXR5IG9mIGFsbCBzdWItdHVubmVscy4gDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGlwc2VjLWJv dW5jZXNAaWV0Zi5vcmcgW2lwc2VjLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gVGVybyBLaXZpbmVu IFtraXZpbmVuQGlraS5maV0NCreiy83KsbzkOiAyMDEyxOoxMdTCNMjVIDEwOjU3DQq1vTogdnpo YW5nMjAwOEB5YWhvby5jb207IFRpbmEgVFNPVTsgV2lsbCBMaXUgKFNodWNoZW5nKTsgaXBzZWNA aWV0Zi5vcmcNCtb3zOI6IFtJUHNlY10gQ29tbWVudHMgdG8gdGhlIGRyYWZ0LXpoYW5nLWlwc2Vj bWUtbXVsdGktcGF0aC1pcHNlYy0wMg0KDQpJbiBzZWN0aW9uIDQgdGhpcyBkcmFmdCBjbGFpbXM6 DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiAgIFRoZSBtZXRob2QgZW5oYW5jZXMgdGhlIHNlY3VyaXR5IHNl cnZpY2UgYnkgc3ByZWFkaW5nIHRoZSB0cmFmZmljDQogICBvbnRvIG11bHRpcGxlIHBhdGhzLg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQpJIGRvIG5vdCB0aGluayB0aGUgbXVsdGlwbGUgcGF0aHMgcmVhbGx5 IGVuaGFuY2VzIHRoZSBzZWN1cml0eS4NCg0KQWxzbyBhcyB0aGUgc2VxdWVuY2UgbnVtYmVyIGlu IHNlbmRpbmcgYW5kIHJlY2VpdmUgd2luZG93IGhhbmRsaW5nIGlzDQpkaWZmZXJlbnQgKGl0IGlz IHNoYXJlZCB3aXRoIGFsbCBzdWItU0FzKSB0aGlzIGZlYXR1cmUgbXVzdCBiZQ0KbmVnb3RpYXRl ZCBiZXR3ZWVuIHRoZSBwZWVycy4NCg0KVGhlIGNsYWltOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAg ICAgICAgIEZvciBleGFtcGxlLCBpdCBtYWtlcyBpdCBoYXJkZXIgZm9yIHRoZQ0KICAgYXR0YWNr ZXIgdG8gaW50ZXJjZXB0IGFsbCB0aGUgcGFja2V0cyBpZiBkaWZmZXJlbnQgcm91dGVzIGFyZSB1 c2VkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpJZiBhdHRhY2tlciBjYW4gaW50ZXJjZXB0IGFuZCBkZWNy eXB0IG9uZSBwYXRoLCB0aGF0IGlzIHF1aXRlIG9mdGVuDQphbHJlYWR5IGJpZyBlbm91Z2ggcHJv YmxlbSB0aGF0IHNlY3VyaXR5IGlzIGNvbXBsZXRlbHkgbG9zdC4NCg0KQWxzbw0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQogICBFdmVuIHdpdGggdGhlIHNhbWUgcm91dGUgdXNlZCwgaXQgaXMgaGFyZGVyIGZv ciB0aGUgYXR0YWNrZXIgdG8ga25vdw0KICAgd2hpY2ggc2V0IG9mIFNBcyBhcmUgY2x1c3RlcmVk IFNBLCB0aHVzIGhhcmRlciB0byBkZWNyeXB0IHRoZQ0KICAgaW50ZXJjZXB0ZWQgcGFja2V0cy4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCg0KVGhpcyBraW5kIG9mIHRoaW5ncyBhcmUgdXN1YWxseSB2ZXJ5IGVh c3kgdG8gc2VlIGZyb20gdHJhZmZpYw0KYW5hbHlzaXMuIEVzcGVjaWFsbHkgaWYgdGhlIHBhY2tl dHMgYXJlIHJvdW5kIHJvYmluZWQgb3ZlciB0aGUgYWxsDQpzdWItU0FzLiBBbHNvIGFzIHRoZSBT UEkgYW5kIHNlcXVlbmNlIG51bWJlcnMgYXJlIGluIGNsZWFyLCBhbmQgYXMNCnNlcXVlbmNlIG51 bWJlciBjb3VudGVyIGlzIHNoYXJlZCBiZXR3ZWVuIGFsbCBzdWItU0FzIGl0IGlzIHRyaXZpYWwg dG8NCnNlZSB3aGljaCBwYWNrZXRzIGJlbG9uZyB0byB0aGUgc2FtZSBjbHVzdGVyZWQgU0Egc2V0 Lg0KDQpBbHNvIHVzaW5nIGRpZmZlcmVudCBrZXlzIHRvIGVuY3J5cHQgdGhlIGRpZmZlcmVudCBz dWItU0FzIHdpbGwgbm90DQphZGQgdGhhdCBtdWNoIHRvIHRoZSBzZWN1cml0eS4gSWYgdGhlIHVu ZGVybGF5aW5nIGNyeXB0byBhbGdvcml0aG0gaGFzDQoyXjEyOCBiaXRzIG9mIHNlY3VyaXR5LCBz cGxpdHRpbmcgdGhlIGRhdGEgb3ZlciBmb3IgZXhhbXBsZSA0IHN1Yi1TQXMNCndpbGwgc2ltcGx5 IGFkZCAyIG1vcmUgYml0cyBvZiBzZWN1cml0eS4gT24gdGhlIG90aGVyIGhhbmQgaXQgaXMNCnVz dWFsbHkgbXVjaCBiZXR0ZXIgZm9yIGF0dGFja2VyIHRvIGF0dGFjayB0aGUgSUtFdjIgbmVnb3Rp YXRpb24NCml0c2VsZiAodGhlIERpZmZpZS1IZWxsbWFuIGV0YyksIGFzIHRob3NlIG1vc3QgbGlr ZWx5IGhhdmUgbGVzcw0Kc2VjdXJpdHkgdGhhbiB0aGUgc3ltbWV0cmljIGNyeXB0byB1c2VkIHRv IHByb3RlY3QgdGhlIGRhdGEsIGFuZCBpZg0KdGhhdCBjYW4gYmUgYnJva2VuIHRoZW4gdGhhdCB3 aWxsIGFsc28gcmV2ZWFsIGFsbCBzdWItU0Ega2V5cy4NCg0KSW4gc2VjdGlvbiA2IHRoZXJlIGlz IHRleHQgc2F5aW5nOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgIFNBIGNsdXN0ZXIgcHJvdmlkZXMg dGhlIG9wdGlvbiB0byBwZXJmb3JtIHRoZSBkaWZmZXJlbnQNCiAgIGNyeXB0b2dyYXBoaWMgdHJh bnNmb3JtYXRpb24gb24gdGhlIGRpZmZlcmVudCBwYWNrZXQuDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCndo aWNoIGFjdHVhbGx5IGxvd2VycyB0aGUgc2VjdXJpdHkuIElmIG9uZSBzdWItU0EgdXNlcyBERVMg YW5kIGFub3RoZXINCnVzZXMgM0RFUywgdGhlIG92ZXJhbGwgc2VjdXJpdHkgaXMgbG93ZXJlZCB0 byB0aGUgbGV2ZWwgb2YgREVTLi4uIEV2ZW4NCmlmIGJvdGggYWxnb3JpdGhtcyBhcmUgc3VwcG9z ZWQgdG8gaGF2ZSBzYW1lIHN0cmVuZ3RoIChBRVMsIENBTUVMTElBDQpldGMpIHRoYXQgZG9lcyBu b3QgbWVhbiB0aGF0IHRoZXkgaW4gcHJhY3RpY2UgaGF2ZSBleGFjdGx5IHNhbWUNCnNlY3VyaXR5 LiBJbiB0aGlzIGNhc2UgYXR0YWNrZXIgd2lsbCBhdHRhY2sgdGhlIHdlYWtlciBhbGdvcml0aG0g YW5kDQphZ2FpbiBnYWlucyBiZW5lZml0cyBvdmVyIHRoYW4gaWYgc2FtZSBzdHJvbmdlciBhbGdv cml0aG0gd2FzIHVzZWQgb24NCmFsbCBvZiB0aGUgZGF0YS4NCi0tDQpraXZpbmVuQGlraS5maQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklQc2VjIG1h aWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXBzZWM= From dharkins@lounge.org Sun Nov 4 07:35:09 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8462221F86B7 for ; Sun, 4 Nov 2012 07:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkmb9ykw37zL for ; Sun, 4 Nov 2012 07:35:09 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1B24321F8679 for ; Sun, 4 Nov 2012 07:35:09 -0800 (PST) Received: from colo.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1A45B10224008; Sun, 4 Nov 2012 07:35:07 -0800 (PST) Received: from 64.168.229.50 (SquirrelMail authenticated user dharkins@lounge.org) by colo.trepanning.net with HTTP; Sun, 4 Nov 2012 07:35:08 -0800 (PST) Message-ID: In-Reply-To: <44BCB928-0220-4687-BF60-70C148ACC771@vpnc.org> References: <20629.54531.886356.890857@fireball.kivinen.iki.fi> <44BCB928-0220-4687-BF60-70C148ACC771@vpnc.org> Date: Sun, 4 Nov 2012 07:35:08 -0800 (PST) From: "Dan Harkins" To: "Paul Hoffman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, Tero Kivinen , svan@elvis.ru Subject: Re: [IPsec] Comments to the draft-smyslov-ipsecme-ikev2-fragmentation-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 15:35:09 -0000 On Sun, November 4, 2012 5:29 am, Paul Hoffman wrote: > On Nov 3, 2012, at 10:37 PM, Tero Kivinen wrote: > >> A general comment: I think we already decided in the WG that we will >> go with the tcp approach, not with this fragmentation layer in the >> IKEv2. Why do we have this document here? > > We don't. Documents listed as "Related Documents" on the Datatracker page > are just that: related. They are not WG work items. Can IKEv3 be added to the related documents section? Thanks, Dan. From turners@ieca.com Sun Nov 4 08:26:15 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC74421F85A0 for ; Sun, 4 Nov 2012 08:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.1 X-Spam-Level: X-Spam-Status: No, score=-102.1 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KipEJvaYPdfd for ; Sun, 4 Nov 2012 08:26:15 -0800 (PST) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [69.56.144.11]) by ietfa.amsl.com (Postfix) with ESMTP id B605621F8463 for ; Sun, 4 Nov 2012 08:26:07 -0800 (PST) Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id 23F345E12ABE4; Sun, 4 Nov 2012 10:26:08 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id 153915E12ABA4 for ; Sun, 4 Nov 2012 10:26:08 -0600 (CST) Received: from [130.129.19.104] (port=50321 helo=dhcp-1368.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TV31S-0000h3-8m for ipsec@ietf.org; Sun, 04 Nov 2012 10:26:06 -0600 Message-ID: <5096971D.5040909@ieca.com> Date: Sun, 04 Nov 2012 11:26:05 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: IPsecme WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-1368.meeting.ietf.org) [130.129.19.104]:50321 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [IPsec] ECDSA for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 16:26:15 -0000 On 11/2/12 2:27 PM, Paul Hoffman wrote: > Greetings again. Here is the long-sought-after consensus report from the design team that was tasked with a proposal for better supporting ECDSA certificates in IKEv2. > > If you have any concern for this topic, please read the proposal below and send comments to the list. > > Thank you to the design team (Tero Kivinen, Johannes Merkle, Dan Harkins, Yoav Nir, David McGrew) for their efforts. I'd like to echo the thanks. > --Paul Hoffman > > > The design team decided it is best to add just one new authentication > method, that will support all kinds of signature methods. This > includes all ECDSA and other EC-based methods (ECGDSA) and can also > support other algorithms too (RSA-PSS or even ElGamal). > > The EC group is assumed to be known from the certificate or raw key, > and there is no need to explicitly negotiate or identify it. For the certificate case, I assume this means the draft will follow what's in the RFC 5480 wrt the SPKI AlgorithmIdentifier - i.e., the curve is always named by the OID. Aside: For RSA-PSS parameters don't always appear in the SPKI AlgorithmIdentifier field - see RFC 5756. > The Authentication Data field in the Authetication Payload will > contain the signature algorithm OID (sha1WithRSAEncryption, > dsa-with-sha1, dsa-with-sha256, ecdsa-with-SHA1, ecdsa-with-SHA256 > etc) and the actual signature. > > The design group considered adding full AlgorithmIdentifier ASN.1 blob > too big and as the other information (EC group etc) is already known > from the certificate or raw key, the only thing needed here is the > actual signature algorithm and hash OID. To make skipping the OID > easier it is prefixed with 8-bit length field (even though the ASN.1 > encoding of the OID has length of oid value in 2nd byte). > > To select suitable hash function for each EC-group we should refer to > the existing guidance (SEC1 and RFC5639), and specify that the method > of X9.62, SEC1 and IO 14888-3 MUST be used for hash truncation. We can > add some non-normative guidance also in the draft for "common" curves. RFC 5480 which has some recommendations about this topic and is probably a better reference than RFC 5639 (one is IETF stream one is ISE stream). It's basically the same recommendations, but RFC 5480 narrows the curve/hash algorithm recommendations more. I want to avoid as many downrefs as possible. > This new method will be negotiated using the Notify Payloads in the > IKE_SA_INIT, and those same payloads can be used to indicate the > supported hash algoritms. A new registry I assume? (yep after reading farther down it's listed). > The old EC-DSA method should be deprecated, but only after the new > methods are supported, meaning the document should say that if new > method is supported by both ends it SHOULD/MUST be used. Make sure the draft indicates it updates RFC 5996. In the examples above, *WithRSAEncryption and dsa-with-* are listed so are we really talking about deprecating all of the previous "signature" values from the IANA registry: V Alg Ref -------------------------------------------------- 1 RSA Digital Signature [RFC5996] 3 DSS Digital Signature [RFC5996] 9 ECDSA with SHA-256 on the P-256 curve [RFC4754] 10 ECDSA with SHA-384 on the P-384 curve [RFC4754] 11 ECDSA with SHA-512 on the P-521 curve [RFC4754] > ---------------------------------------------------------------------- > The Authentication Paylod will look like this: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Payload |C| RESERVED | Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Auth Method | RESERVED | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Authentication Data ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 14: Authentication Payload Format > > o Auth Method (1 octet) - Specifies the method of authentication > used. > > Mechanism Value > ----------------------------------------------------------------- > Digital Signature > Computed as specified in Section 2.15 of RFC5996 using a private > key associated with the public key sent in certificate payload, > and using one of the hash algoritms sent by the other end in the > SIGNATURE_HASH_ALGORITHMS notify payload. If both ends send and > receive SIGNATURE_HASH_ALGORITHMS and signature authentication > is to be used, then this method MUST be used. The Authentication > Data field has different format than in other Authentication > methods (see below). > > o Authentication Data (variable length) - see Section 2.15 of > RFC5996. For "Digital Signature" format the Authentication data > contains special format as follows: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OID Length | OID (0x06) . OID value len . OID value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ OID value continuing ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Authentication Data ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Where the OID Length is the length of the ASN.1 encoded OID > value, and after that is the actual Signature Algorithm OID > followed by the actual signature value. There is no padding > between OID and signature value. ASN.1 encoded OIDs always > start with byte of 0x06 followed by the length of the actual > OID value (which is shown in the figure abow). > > ---------------------------------------------------------------------- > > The method is negotiated by sending and receiving > SIGNATURE_HASH_ALGORITHMS Notify payload: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Payload |C| RESERVED | Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Protocol ID | SPI Size | Notify Message Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Security Parameter Index (SPI) ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Notification Data ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The Protocol ID is 0, SPI Size 0, and Notify Message Type status types>. The Notification Data value contains list of 16-bit > hash algorithm identifiers from the newly created Hash Algorithm > Identifiers for the IKEv2 IANA registry. > > Sending this notification tells that new "Digital Signature" > authentication method is supported and that following hash functions > are supported by sending peer. Both ends sends their list of supported > hash-algorithms and when calculating signature a peer MUST pick one > algorithm sent by the other peer. Note, that different algorithms can > be used in different directions. The actual algoritm used when > calculating the signature is sent inside the Authentication Data field > of the Authentication Payload. Assuming here that this new notify is normally sent during the IKE_SA_INIT exchange from the responder to the initiator: a) The initiator actually figures out the signature algorithms supported by the responder based on the new Notify message, Alg ID parameter, and the cert's key usage extension? The SPKI will include id-ecPublicKey not ecdsa-with-* right so you can't rely on that. You can't rely on just the Alg ID parameter because the key usage extension can have any combination of digitalSignature, nonRepudiation, and keyAgreement set. So don't you have to look at all three? Note: This approach ought to work for DSA to because they indicate the id-dsa and you'll also have the new hash value. RSA is going to have the same problem as EC algs though because the parameters are NULL and the key usage might just be set to keyTransport. b) I guess the question I have is whether inclusion of this notify means that the entity only supports the new way? That is in the above is it: Sending this notification tells that new "Digital Signature" authentication method is supported and that following hash function are supported by sending peer. or Sending this notification tells that new "Digital Signature" authentication method is *also* supported and that following hash functions are supported by sending peer. If the initiator doesn't support it, then it just fails straight off? How would we transition? spt From kivinen@iki.fi Sun Nov 4 08:30:51 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9786F21F85DD for ; Sun, 4 Nov 2012 08:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDfEHePBjaTN for ; Sun, 4 Nov 2012 08:30:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0203821F85AA for ; Sun, 4 Nov 2012 08:30:43 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA4GUZa9027387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 18:30:35 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA4GUWIs027554; Sun, 4 Nov 2012 18:30:32 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20630.38952.34362.913612@fireball.kivinen.iki.fi> Date: Sun, 4 Nov 2012 18:30:32 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <44BCB928-0220-4687-BF60-70C148ACC771@vpnc.org> References: <20629.54531.886356.890857@fireball.kivinen.iki.fi> <44BCB928-0220-4687-BF60-70C148ACC771@vpnc.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: ipsec@ietf.org, svan@elvis.ru Subject: Re: [IPsec] Comments to the draft-smyslov-ipsecme-ikev2-fragmentation-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 16:30:51 -0000 Paul Hoffman writes: > On Nov 3, 2012, at 10:37 PM, Tero Kivinen wrote: > > A general comment: I think we already decided in the WG that we will > > go with the tcp approach, not with this fragmentation layer in the > > IKEv2. Why do we have this document here? > We don't. Documents listed as "Related Documents" on the Datatracker > page are just that: related. They are not WG work items. Ah, I misremembered in the plane then when I was reading this. I tought this was on the agenda for the ipsecme meeting on monday... On the other hand the ikev3 draft was not listed in the related documents, as it does not have -ipsecme- in its name, which caused that my sec-area WG ebook containing all WG and WG related drafts and RFC did not include it... Need to read it now... -- kivinen@iki.fi From yaronf.ietf@gmail.com Sun Nov 4 09:51:20 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC3321F8787 for ; Sun, 4 Nov 2012 09:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpk42gK6yLiD for ; Sun, 4 Nov 2012 09:51:18 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 09C9A21F869A for ; Sun, 4 Nov 2012 09:51:07 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so2265284eaa.31 for ; Sun, 04 Nov 2012 09:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HUtqaDGhYRfXpDGA0qWR/alJCT50otIEo9qnzZpIgG4=; b=qYFEgUb7xQXhuXokj8/WILltA/bh2eLvwNJpZ3SUQX9Kc6ABCbX48EqKDdgVCmcWtF 4Ix4giSTjkRZBk80yHndetqjcDuP4JbTnHdZ9LWgQnnLrYwBPcGHOFpWsQNe/7YuSPRM kd0pcMVJAj+AYJBbtrUput3+JpEmz2sasq2xyLc7c47l2U6d2WrLMvPSepLdVn3u+uj5 Q8NDA6oKg6B0Lh2k3oifLQa7VizsIU3kpgb9m5ISPDa/9Qc2SwYM0OOP9JXuLe3tVb6+ DiOQNq1K+CsYAEjE0mnzJYuzEHKJsSKhMaOYtrzG4pHuaHv/bfYGxSsBvFNbf1ClVtxE iAVw== Received: by 10.14.182.9 with SMTP id n9mr28194336eem.24.1352051466931; Sun, 04 Nov 2012 09:51:06 -0800 (PST) Received: from [192.168.1.130] ([176.13.234.146]) by mx.google.com with ESMTPS id g5sm41634676eem.4.2012.11.04.09.51.04 (version=SSLv3 cipher=OTHER); Sun, 04 Nov 2012 09:51:05 -0800 (PST) Message-ID: <5096AAFC.102@gmail.com> Date: Sun, 04 Nov 2012 19:50:52 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Dan Harkins References: <20629.54531.886356.890857@fireball.kivinen.iki.fi> <44BCB928-0220-4687-BF60-70C148ACC771@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Paul Hoffman , Tero Kivinen , svan@elvis.ru Subject: Re: [IPsec] Comments to the draft-smyslov-ipsecme-ikev2-fragmentation-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 17:51:20 -0000 As Tero mentioned on another thread, the "related docs" section is created automatically based on keyword matching. You'll need to rename the I-D to draft-harkins-ipsecme-ikev3. Thanks, Yaron On 11/04/2012 05:35 PM, Dan Harkins wrote: > > > On Sun, November 4, 2012 5:29 am, Paul Hoffman wrote: >> On Nov 3, 2012, at 10:37 PM, Tero Kivinen wrote: >> >>> A general comment: I think we already decided in the WG that we will >>> go with the tcp approach, not with this fragmentation layer in the >>> IKEv2. Why do we have this document here? >> >> We don't. Documents listed as "Related Documents" on the Datatracker page >> are just that: related. They are not WG work items. > > Can IKEv3 be added to the related documents section? > > Thanks, > > Dan. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From mcr@sandelman.ca Sun Nov 4 12:08:28 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D6321F87E1 for ; Sun, 4 Nov 2012 12:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcCJrP0IAq7O for ; Sun, 4 Nov 2012 12:08:27 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8497621F87E6 for ; Sun, 4 Nov 2012 12:08:23 -0800 (PST) Received: from sandelman.ca (107-1-119-250-ip-static.hfc.comcastbusiness.net [107.1.119.250]) by relay.sandelman.ca (Postfix) with ESMTPS id D7C3081A9 for ; Sun, 4 Nov 2012 15:00:21 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 44867CA0CE for ; Sun, 4 Nov 2012 12:40:45 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org In-reply-to: <20629.51761.388715.484632@fireball.kivinen.iki.fi> References: <20629.51761.388715.484632@fireball.kivinen.iki.fi> Comments: In-reply-to Tero Kivinen message dated "Sun, 04 Nov 2012 03:51:45 +0200." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 04 Nov 2012 12:40:45 -0500 Message-ID: <25304.1352050845@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:08:28 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: TK> -------------------------------------------------------------------= --- TK> Specifically, the messages of the IKE_AUTH exchange can become TK> quite large, as they may contain a chain of certificates, an TK> "Auth" payload (that may contain a public key signature), CRLs, TK> and some configuration information that is carried in the CFG TK> payload. TK> -------------------------------------------------------------------= --- TK> In addition to the IKE_AUTH there is another big class of UPD TK> packets which can be large, and which might get fragmented, i.e TK> udp encapsulated nat traversal IPsec UDP packets. If the I don't think you are suggesting any specific technical change to support this. I think that you are saying that we need to be more clear that we aren't proposing anything here. And that if TCP gets used for the AUTH payload, that might be a clue to the IPsec layer that it should do: TK> For tunnel mode IPsec traffic, the gateway can fragment inner TK> packets before wrapping them to ESP, so the outer ESP packets TK> visible to nat box are not fragmented. which the gateway machine might not otherwise do. But, this can't be done for IPv6. (There isn't really any significant downside to doing this. If anything, this moves the memory expense of fragment reassembly from gateways to end nodes.) TK> which means we cannot modify the NAT_DETECTION_*_IP payloads TK> when switching from UPD to TCP. This might cause NAT to be TK> detected even when there is none there (i.e. the UDP source port TK> is 500, but TCP source port is most likely going to be random). The document does not tell us if we have to originate from port-500. I don't think that we can. TK> Also I think this document should tell the justifications why TK> the TCP session is not kept alive all the time, but only created TK> for sending one packet and then immediately teared down. I TK> assume the idea there is that open TCP session actually requires TK> quite a lot of resources from the SGW, i.e. maintaining the send TK> and receive windows requires tens of kilobytes of memory. Of TK> course the downside of such short TCP sessions is that sending TK> one exchange over TCP now requires 2 round trips of delay, and TK> most likely around 10 packets, compared to the 1 round trip and TK> 2 packets.=20=20 Yes. I think that the congestion window argument is probably not relevant. I don't think the congestion window will open much even if the first round trip goes through.=20=20=20 =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQlqicAAoJEKD0KQ7Gj3P2ZcMH/1PgKq2T9136eOJ+lYHfNciG oauXbk+3LI0LYjkcZC+EM8VQdgBmBRWxKGcsIuDeGM/Uhx6ujrUJL6ucSMcapcqC jbJ6K2qvosqGx8OyYYym8BLULLZDxYEOQB601Zwol8oGoQ7RMiLBgktn4D2j2Pob b3MM31gaObha2hA4+6noHACr4Asub3mxm1D20QBccUhdwfQ4w9eZpyYORlnTJE94 AfrnxyJiKPUOZFO1emLmWbGWzcAv8gCbnyFyF5LCDbdJgc2dKtAzwx6fWHtDBzV3 t4DJW11KGUdAnPOfWW14qI0PFuhUOn8WXy4+C1hD5v2EYXlDejCwTvT5qYnLas8= =Ind8 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sun Nov 4 12:13:22 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D94521F85D1 for ; Sun, 4 Nov 2012 12:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Anbkw3zy9u0g for ; Sun, 4 Nov 2012 12:13:21 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id E378221F85CF for ; Sun, 4 Nov 2012 12:13:21 -0800 (PST) Received: from sandelman.ca (107-1-119-250-ip-static.hfc.comcastbusiness.net [107.1.119.250]) by relay.sandelman.ca (Postfix) with ESMTPS id B3AF281A9 for ; Sun, 4 Nov 2012 15:05:21 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A2A0DCA0BC for ; Sun, 4 Nov 2012 10:25:35 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 04 Nov 2012 10:25:35 -0500 Message-ID: <22808.1352042735@sandelman.ca> Sender: mcr@sandelman.ca Subject: [IPsec] ike-tcp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:13:22 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I read ipsec-ike-tcp-00. I found it very clear. section 3 says: > An initiator using this policy MUST NOT go to TCP if the responder > has not indicated support by sending the IKE_TCP_SUPPORTED > notification (Section 2.5) in the Initial response. ... > Yet another policy would be to begin by using UDP, and at the same > time set up the TCP connection. If at any point the TCP handshake > completes, the next requests go over that connection. This method These two parts seem to be in contradiction unless this isn't the first=20 time the initator has talked to this responder, and cached this state. Even so, a responder that is under attack may want to limit who it talks TCP to, but the kernel usually does the three-way handshake itself. The responder might want=20 1) to prioritize which initiators are allowed to use TCP by omitting the IKE_TCP_SUPPORTED payload. 2) to never have initiators use TCP for the initial exchange so that it can use COOKIE payloads. > the three-way handshake just when IKE over UDP has finished. The > requirements from the responder ensure that all these policies will > work. An initiator that did this would seem to be effectively taking twice the resources on the responder.=20=20=20 I think that it's important to note really loundly, and maybe repeatedly, that the duration of the TCP connection is not related to the duration of the IKE SA. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQlojvAAoJEKD0KQ7Gj3P2OFAH/19vKx7J3Pxvxjrgb9/o/CXT nxIV72XhIceQYpYZssdRitWK1vfoAlhhcIp+ye5OyUvCzAwannQxKeEnNmq4ZaC3 mlpi7/6svA5WVq3i86JSzdRjXnOd5ViUF0fKbOq9dd07OSorW8jjy+fmbDD6JcMV yBvcAm5I1FWz9abzgaKtgd7u8f4X0zoCNCfUcydxQtXTsKT1KScEYRdVl5TallAz EcqljH4f7QeLKEhMbmZifp0b4aKEc+Ucq3ODBBu+pxXNoeJPXMdWwNTCi2A1glt5 lkL5SRxidaqzQrh+Jw4MfaVqPelLceDkMwIIRhnkXTAMZSw8YrPA9V2xcO1n+wo= =ZDHC -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sun Nov 4 12:14:27 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E7821F8829 for ; Sun, 4 Nov 2012 12:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P312AnsKquV for ; Sun, 4 Nov 2012 12:14:27 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5E39D21F8825 for ; Sun, 4 Nov 2012 12:14:27 -0800 (PST) Received: from sandelman.ca (107-1-119-250-ip-static.hfc.comcastbusiness.net [107.1.119.250]) by relay.sandelman.ca (Postfix) with ESMTPS id CB6B381A9 for ; Sun, 4 Nov 2012 15:06:26 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id ABBC0CA0C7 for ; Sun, 4 Nov 2012 10:46:01 -0500 (EST) From: Michael Richardson To: IPsecme WG In-reply-to: <0AE85D37-FC4A-4F4B-A66B-262B19EFF0AA@vpnc.org> References: <0AE85D37-FC4A-4F4B-A66B-262B19EFF0AA@vpnc.org> Comments: In-reply-to Paul Hoffman message dated "Fri, 02 Nov 2012 18:08:47 -0700." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) Date: Sun, 04 Nov 2012 10:46:01 -0500 Message-ID: <23426.1352043961@sandelman.ca> Sender: mcr@sandelman.ca Subject: [IPsec] draft-mcgrew-ipsec-me-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:14:27 -0000 What in practice, for an implementer and/or his marketing manager, is the difference between "MAY" for algorithm and not listing it at all? I would understand if we had "MAY+", but really, that is what "SHOULD" means. Could there implications on UIs, such that things listed SHOULD/MUST are listed in the first page, things listed MAY are on the "Advanced options" page, and whatever country-specific vanity ciphers that might get included are under some even more obscure button. Or is the intent of MAY to give a clue to cryptoanalysis people as to what things to focus on? Or for people GREP'ing the RFC archives as a result of an attack will come up with IPsec as a user/ -- Michael Richardson -on the road- From mcr@sandelman.ca Sun Nov 4 12:14:28 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7C321F8828 for ; Sun, 4 Nov 2012 12:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XP3a2KQz-fMD for ; Sun, 4 Nov 2012 12:14:28 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 87BC921F8822 for ; Sun, 4 Nov 2012 12:14:28 -0800 (PST) Received: from sandelman.ca (107-1-119-250-ip-static.hfc.comcastbusiness.net [107.1.119.250]) by relay.sandelman.ca (Postfix) with ESMTPS id 5A41C81C4 for ; Sun, 4 Nov 2012 15:06:28 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 63FB8CA0C6 for ; Sun, 4 Nov 2012 10:34:49 -0500 (EST) From: Michael Richardson To: IPsecme WG In-reply-to: <0AE85D37-FC4A-4F4B-A66B-262B19EFF0AA@vpnc.org> References: <0AE85D37-FC4A-4F4B-A66B-262B19EFF0AA@vpnc.org> Comments: In-reply-to Paul Hoffman message dated "Fri, 02 Nov 2012 18:08:47 -0700." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 04 Nov 2012 10:34:49 -0500 Message-ID: <23063.1352043289@sandelman.ca> Sender: mcr@sandelman.ca Subject: [IPsec] ipsecme-oob-pubkey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:14:29 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable draft-kivinen-ipsecme-oob-pubkey -- 15 mins Motivations Description of problem that is being solved Question about whether this updated 5996 to replace RSA raw key format The question is, I think whether this is an extension to 5996, or an update? If an update, then it could obsolete payload 11? Could new implementations decline to implement type 11? I think that this would be marginally acceptable. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQlosZAAoJEKD0KQ7Gj3P2Ry0IALARuBxtuThxxw7oOgx2Tnt2 H8+avWmY1ASgR75dhVxx3mZrgXj5VzRy9f/O0L0jj8Xbvcj2Sr36kvQLeq2Vmk95 xiJay/VS23v9/7+jv5s/sFtdEHSq9zy5pU0xuVOBr7mFjUj3aF/P6wsgWU+afV43 sqBsEhmJ3NmYkgS9yFvccOt7V/gNruZKPSmrzVd+H+lDwj+Cyyhu6ser55iCd3uG DpyQoMOHls3lBB1bR2acDZf3HCANF34abfJy4NbicMZZZavL7SuDQXuKOH6i0Ozi yfs6g7/tsMnuq3GoNMBU/C5TShl2Ls8oOmd16tQmbvoGoeQ0/IyRhiO05dZ/+Lo= =Ltgl -----END PGP SIGNATURE----- --=-=-=-- From kivinen@iki.fi Sun Nov 4 12:25:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134E121F885B for ; Sun, 4 Nov 2012 12:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AA5EAY9BjEbi for ; Sun, 4 Nov 2012 12:25:03 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 264D621F8805 for ; Sun, 4 Nov 2012 12:25:02 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA4KP00c013293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Nov 2012 22:25:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA4KP0eb028681; Sun, 4 Nov 2012 22:25:00 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20630.53020.522052.651631@fireball.kivinen.iki.fi> Date: Sun, 4 Nov 2012 22:25:00 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <25304.1352050845@sandelman.ca> References: <20629.51761.388715.484632@fireball.kivinen.iki.fi> <25304.1352050845@sandelman.ca> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:25:04 -0000 Michael Richardson writes: > Tero Kivinen wrote: > TK> In addition to the IKE_AUTH there is another big class of UPD > TK> packets which can be large, and which might get fragmented, i.e > TK> udp encapsulated nat traversal IPsec UDP packets. If the > > I don't think you are suggesting any specific technical change to > support this. I think that you are saying that we need to be more clear > that we aren't proposing anything here. And that if TCP gets used for > the AUTH payload, that might be a clue to the IPsec layer that it should > do: No, I was just pointing out that IKE_AUTH is not the only packet which can be big packets, and UDP encapsulated packets might also have problems bypassing the NATs dropping all fragments. > TK> For tunnel mode IPsec traffic, the gateway can fragment inner > TK> packets before wrapping them to ESP, so the outer ESP packets > TK> visible to nat box are not fragmented. > > which the gateway machine might not otherwise do. But, this can't be > done for IPv6. > (There isn't really any significant downside to doing this. If > anything, this moves the memory expense of fragment reassembly from > gateways to end nodes.) On the other hand I am not sure NAT boxes do drop IPv6 fragments... IPv6 and NAT are not used that often together. > TK> which means we cannot modify the NAT_DETECTION_*_IP payloads > TK> when switching from UPD to TCP. This might cause NAT to be > TK> detected even when there is none there (i.e. the UDP source port > TK> is 500, but TCP source port is most likely going to be random). > > The document does not tell us if we have to originate from port-500. > I don't think that we can. I think it says for TCP we use random port, but for UDP the IKEv2 RFC5996 says you use port 500 (but must allow source port to be other than 500). With TCP there is problems if we try to use source and dest port of 500 for all requests, as there might still be old connections waiting for cleanup in the system when we start next one. > TK> Also I think this document should tell the justifications why > TK> the TCP session is not kept alive all the time, but only created > TK> for sending one packet and then immediately teared down. I > TK> assume the idea there is that open TCP session actually requires > TK> quite a lot of resources from the SGW, i.e. maintaining the send > TK> and receive windows requires tens of kilobytes of memory. Of > TK> course the downside of such short TCP sessions is that sending > TK> one exchange over TCP now requires 2 round trips of delay, and > TK> most likely around 10 packets, compared to the 1 round trip and > TK> 2 packets. > > Yes. I think that the congestion window argument is probably not > relevant. I don't think the congestion window will open much even if the > first round trip goes through. In most systems just opening the TCP session will reserve 32 kB buffers for sending and receiving immediately when you open tcp connection. Earlier that was one of the parameters you needed to tune down for web servers if you wanted to support lots of clients. -- kivinen@iki.fi From ynir@checkpoint.com Sun Nov 4 12:53:29 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4D221F84B3 for ; Sun, 4 Nov 2012 12:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZSyevRKyXu7 for ; Sun, 4 Nov 2012 12:53:26 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF9121F84D8 for ; Sun, 4 Nov 2012 12:53:25 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qA4KrMo7024924 for ; Sun, 4 Nov 2012 22:53:22 +0200 X-CheckPoint: {5096D32A-15-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 4 Nov 2012 22:53:22 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sun, 4 Nov 2012 22:53:22 +0200 From: Yoav Nir To: IPsecme WG Date: Sun, 4 Nov 2012 22:53:20 +0200 Thread-Topic: Comments to the draft-nir-ipsecme-erx-07.txt Thread-Index: Ac26zmyLo6Xbjmw+SrO7IcHlal3DwA== Message-ID: <42AE5063-43FA-42D3-B16A-BDBE9CD50FF6@checkpoint.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_42AE506343FA42D3B16ABDBE9CD50FF6checkpointcom_" MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: [IPsec] Fwd: Comments to the draft-nir-ipsecme-erx-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 20:53:31 -0000 --_000_42AE506343FA42D3B16ABDBE9CD50FF6checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have forwarded this to the IETF, and left out the IPsec mailing list on p= urpose, so that future messages are not copied here. Please reply to that list. Yoav Begin forwarded message: From: Yoav Nir > Subject: Re: Comments to the draft-nir-ipsecme-erx-07.txt Date: November 4, 2012 3:52:21 PM EST To: Tero Kivinen >, IETF list > Cc: "sunseawq@huawei.com Wu" > Forwarding to the IETF mailing list, which is the proper home for this disc= ussion. On Nov 3, 2012, at 10:26 PM, Tero Kivinen wrote: In Introduction section (1) there is text saying: ---------------------------------------------------------------------- Bringing these two technologies together allows a remote access IPsec client to create multiple tunnels with different gateways that belong to a single domain, as well as using the keys from other contexts of using EAP, such as network access within the same domain, to transparently connect to VPN gateways within this domain. ---------------------------------------------------------------------- I think that is missing one possible use for the EAP Re-authentication Protocol, then one that has been proposed for example in the IEEE 802.11ai. I.e the possibility that the client does full EAP with AAA backend only once, and then reuses that authentication later to recreate the IPsec connection when it was lost for some reason (network problems, device suspending, going out of range etc). I.e. use it in similar ways as resumption protocol can be used, but now the state is stored in the AAA backend, not in the SGW. In section "3. Protocol Outline" there is text saying: ---------------------------------------------------------------------- The responder sends the EAP payload content to a backend AAA server, and receives the rMSK and an EAP-Finish/Re-auth message. It then forwards the EAP-Finish/Re-auth message to the Initiator in an EAP payload within the first IKE_AUTH response. ---------------------------------------------------------------------- There is possibility that even when the client has ERX connection still up, but the backend AAA server might have already destroyed it. This means that it is possible that when initiator sends the first EAP_Initiate/Re-Auth message to the SGW, which forwards it to the AAA server, the AAA server will NOT respond with EAP-Finish/Re-auth message, but simply starts normal full EAP. This should be explained here. It does not really change the actual protocol flow, as AAA server will send EAP packet back, and then the initiator and responder will exchange some number of EAP packets before responder sends the EAP-Finish to initiator and they do the final AUTH exchange. If it is not mentioned here, some implementations might assume they always get EAP-Finish/Re-auth back and not work if the AAA server goes through the full EAP exchange. In section "4. ERX_SUPPORTED Notification" there is text saying: ---------------------------------------------------------------------- o Protocol ID (1 octet) MUST be 1, as this message is related to an IKE SA. ---------------------------------------------------------------------- This is wrong. The RFC 5996 in section 3.10 says: ---------------------------------------------------------------------- o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS and REKEY_SA. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. ---------------------------------------------------------------------- I.e. the Protocol ID MUST be sent as zero if the SPI field is empty. -- kivinen@iki.fi Scanned by Check Point Total Security Gateway. --_000_42AE506343FA42D3B16ABDBE9CD50FF6checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have forwarded this to t= he IETF, and left out the IPsec mailing list on purpose, so that future mes= sages are not copied here.

Please reply to that list.

Yoav


Begin forwarded mes= sage:

From: Yoav Nir <ynir@checkpoint.com>
= Subject: Re: Comments to the draft-nir-ipsecme-erx-07.txt
Date: November 4, 2012 3:52:21 PM EST
<= /div>
To: Tero Kivinen <kivinen@iki.fi>, IETF list <ietf@ietf.org>
Forwarding to the IETF mailing list, which is the proper home for thi= s discussion.

On Nov 3, 2012, at 10:26 PM, Tero Kivinen wrote:
In Introduction section (1) there is text sayin= g:

--------------------------------------------------------------= --------
 Bringing these tw= o technologies together allows a remote access IPsec
 client to create multiple tunnels with different= gateways that belong
 to a= single domain, as well as using the keys from other contexts of
 using EAP, such as network access wi= thin the same domain, to
 t= ransparently connect to VPN gateways within this domain.
---------------------------------------------------= -------------------

I think that is missing one possible use for = the EAP Re-authentication
Protoco= l, then one that has been proposed for example in the IEEE
=
802.11ai. I.e the possibility that the client doe= s full EAP with AAA
backend only = once, and then reuses that authentication later to
recreate the IPsec connection when it was lost for some r= eason
(network problems, device s= uspending, going out of range etc).

I.e. use it in similar ways a= s resumption protocol can be used, but
now the state is stored in the AAA backend, not in the SGW.

In section "3. Protocol Outline" there is text saying:

---------= -------------------------------------------------------------
 The responder sends the EAP payload con= tent to a backend AAA server,
&n= bsp;and receives the rMSK and an EAP-Finish/Re-auth message.  It then<= br>
 forwards the EAP-Finish/Re= -auth message to the Initiator in an EAP
 payload within the first IKE_AUTH response.
-----------------------------------------------= -----------------------

There is possibility that even when the c= lient has ERX connection
still up= , but the backend AAA server might have already destroyed it.
This means that it is possible that when initi= ator sends the first
EAP_Initiate= /Re-Auth message to the SGW, which forwards it to the AAA
<= blockquote type=3D"cite">server, the AAA server will NOT respond with EAP-F= inish/Re-auth
message, but simply= starts normal full EAP. This should be explained
here. It does not really change the actual protocol flow, = as AAA
server will send EAP packe= t back, and then the initiator and responder
will exchange some number of EAP packets before responder sends= the
EAP-Finish to initiator and = they do the final AUTH exchange.
=
If it is not mentioned here, som= e implementations might assume they
always get EAP-Finish/Re-auth back and not work if the AAA server goes
through the full EAP exchange.
=

In section "4. ERX_SUPPORTED Notification" there is text saying:
=

--------------------------------------------------------------------= --
 o  Protocol ID (1 = octet) MUST be 1, as this message is related to an
    IKE SA.
---------------------------------------------------------= -------------

This is wrong. The RFC 5996 in section 3.10 says:

-----------------------------------------------------------------= -----
 o  Protocol ID = (1 octet) - If this notification concerns an existing
    SA whose SPI is given in the = SPI field, this field indicates the
    type of that SA.  For notifications concer= ning Child SAs, this
  = ;  field MUST contain either (2) to indicate AH or (3) to indicat= e
    ESP. &= nbsp;Of the notifications defined in this document, the SPI is
    included only with I= NVALID_SELECTORS and REKEY_SA.  If the SPI
    field is empty, this field MUST be = sent as zero and MUST be
 &= nbsp;  ignored on receipt.
----------------------------------------------------------------------<= br>

I.e. the Protocol ID MUST be sent as zero if the SPI field is emp= ty.
--
kivinen@iki.fi
<= /blockquote>

Scanned by Check Point Total Security Gateway.


= --_000_42AE506343FA42D3B16ABDBE9CD50FF6checkpointcom_-- From mcr@sandelman.ca Sun Nov 4 13:02:33 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921F321F87D6 for ; Sun, 4 Nov 2012 13:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcL5J9cSGphs for ; Sun, 4 Nov 2012 13:02:30 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 115F521F87D4 for ; Sun, 4 Nov 2012 13:02:30 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 4EE8681A9 for ; Sun, 4 Nov 2012 15:54:27 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 69B26CA0BC for ; Sun, 4 Nov 2012 16:02:29 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org In-reply-to: <20630.53020.522052.651631@fireball.kivinen.iki.fi> References: <20629.51761.388715.484632@fireball.kivinen.iki.fi> <25304.1352050845@sandelman.ca> <20630.53020.522052.651631@fireball.kivinen.iki.fi> Comments: In-reply-to Tero Kivinen message dated "Sun, 04 Nov 2012 22:25:00 +0200." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 04 Nov 2012 16:02:29 -0500 Message-ID: <32506.1352062949@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-ike-tcp-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 21:02:33 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: TK> In addition to the IKE_AUTH there is another big class of UPD TK> packets which can be large, and which might get fragmented, i.e TK> udp encapsulated nat traversal IPsec UDP packets. If the >> I don't think you are suggesting any specific technical change to >> support this. I think that you are saying that we need to be >> more clear that we aren't proposing anything here. And that if >> TCP gets used for the AUTH payload, that might be a clue to the >> IPsec layer that it should do: TK> No, I was just pointing out that IKE_AUTH is not the only packet TK> which can be big packets, and UDP encapsulated packets might TK> also have problems bypassing the NATs dropping all fragments. So, the converse statement (for me) is that you think that we should specify a way to carry ESP over TCP. TK> For tunnel mode IPsec traffic, the gateway can fragment inner TK> packets before wrapping them to ESP, so the outer ESP packets TK> visible to nat box are not fragmented. >> which the gateway machine might not otherwise do. But, this can't >> be done for IPv6. (There isn't really any significant downside >> to doing this. If anything, this moves the memory expense of >> fragment reassembly from gateways to end nodes.) TK> On the other hand I am not sure NAT boxes do drop IPv6 TK> fragments... IPv6 and NAT are not used that often together. IPv6 packets inside ESP over IPv4-ESP-UDP. This gives your laptop ubiquitous IPv6, even when behind stupid networks. >> Yes. I think that the congestion window argument is probably not >> relevant. I don't think the congestion window will open much even >> if the first round trip goes through. TK> In most systems just opening the TCP session will reserve 32 kB TK> buffers for sending and receiving immediately when you open tcp TK> connection. Earlier that was one of the parameters you needed to TK> tune down for web servers if you wanted to support lots of TK> clients.=20=20 yeah, but the concern listed in the document is that the initial congestion window wouldn't be big enough to quickly send out the large IKE_AUTH payload. Having at least one RTT for the initial IKE_INIT exchange would allow TCP to double the window, and get an estimate for RTT. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQltflAAoJEKD0KQ7Gj3P2UxAIAKKQR1WvSEEI/EMM1GRH3RwV SCd+kccW3CUZBbztT8RlOl2r/DmnebC654hGZ2SHcYyDLzoA4Carnkbn5xvmBl2Y 051zOblZgAyHCrDVtbmtExC3199OATQ0Ho3niPF3eAVQNtteKUeAYnzPj2+frq1k 3ioGE62vsgm8JyvQgat6mW4Xt3Ne2kmeQvN6z5vEZKd5Xo1uQshlirRC2TnQ+uDG pyu3IEFjl8b+AL1varZEYrsI8+mP2+l+QEt/OHhjsjMxKsrSMdcoL261xniMOpUL LAtsGKCNIh8vhC1ZI0CzJTUd3T16SiaZh5Rb1mJh3mk7pmUhcr+N5gtl7oQ4tu0= =XYpz -----END PGP SIGNATURE----- --=-=-=-- From svanru@gmail.com Sun Nov 4 22:18:25 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D794B21F8670 for ; Sun, 4 Nov 2012 22:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSEJWmxxfwkX for ; Sun, 4 Nov 2012 22:18:25 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1B7D21F85D1 for ; Sun, 4 Nov 2012 22:18:24 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so4121347lam.31 for ; Sun, 04 Nov 2012 22:18:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=gBqUKCkkvWWG6ixGpr1fJr4M7+6Wo8Ogk92RIRPgvbs=; b=u8Ip7s9OWuT3koXM6yixRuRsl2FzIdu1gz7CRwxOgXExwp0aSqPgd4GbgQpMBUdYf8 sCN4YtbSMlcd9HTeCeD3zn+qF+rYECkLyBM50hd7jkjASpPEX49qFGVspeWoFQjHycSy bSQqz+HWREq8Zrww3SrN67QZtfUdQOI/HwO2PKyHQt+OV233rJxXQWL2cDb4dK6IVszF y307WY6pIXtC5cU6JBFhJA66/i0Ln3Ay3Sw21UjtQb0CqJKWZl5tuGYJr0nqBTa6AlY7 Om1sdcmcXPZ5SVZv8vbJX8MjlfrvGv0wUehxpUwtKbZK+/Nn+84NH6RuzP18Uz8W9OO4 mDGQ== Received: by 10.152.102.234 with SMTP id fr10mr8311936lab.28.1352096300058; Sun, 04 Nov 2012 22:18:20 -0800 (PST) Received: from chichi (ppp91-77-179-39.pppoe.mtu-net.ru. [91.77.179.39]) by mx.google.com with ESMTPS id hu6sm5233698lab.13.2012.11.04.22.18.18 (version=SSLv3 cipher=OTHER); Sun, 04 Nov 2012 22:18:18 -0800 (PST) Message-ID: <11D298162C3D469C94497F5AC58083AB@chichi> From: "Valery Smyslov" To: "Tero Kivinen" , References: <20629.54531.886356.890857@fireball.kivinen.iki.fi> Date: Mon, 5 Nov 2012 10:18:13 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [IPsec] Comments to thedraft-smyslov-ipsecme-ikev2-fragmentation-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 06:18:26 -0000 Hi Tero, thank you for your comments. >A general comment: I think we already decided in the WG that we will > go with the tcp approach, not with this fragmentation layer in the > IKEv2. Why do we have this document here? As others pointed out this draft is not a WG item. > Some other comments > > In section 2.5 the header contains "Total Framgments" field. This > means the initiator must decide the number of framents it is sending > out in the beginning, i.e. it cannot dynamically adjust this if it > sees that it is sending so long fragments that they get lost. It would > be better to use standard way of doing this, i.e. sending the offset > to the start of the fragment, and some kind of indication whether this > was last fragment or not. Sorry, I see no difference here. Currently draft doesn't allow fragment size to be adjusted dynamically, as it is easier to implement. But in general it is possible. When initiator suspects fragments are too big, it would refragment original packet using smaller value. That will effectively change fragments number field, that will give responder an indication, that this is other set of fragments, which will be reassembling in different fragments list. > Also it is not clear how retransmission is done here at all. I assume > we will send all fragments in case of the retransmission, but again we Exactly. > cannot adjust the fragment size to be smaller, even if we start to > suspect that there is something between which is eating our fragments. See above. > Only way to do that would be to delete the IKE SA and start over with > lower fragment size parameter (as it is possible that the responder > did got some of the fragments, for example last one, which was small > enough, and as we only have fragment number, not offset we cannot > know at which offset that packet belongs to). Even if responder knew offset, what would be the difference? Regards, Valery Smyslov. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From priikone@iki.fi Sun Nov 4 23:22:19 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2FD21F8B4E for ; Sun, 4 Nov 2012 23:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rx7IRCVLy1Wb for ; Sun, 4 Nov 2012 23:22:19 -0800 (PST) Received: from git.silcnet.org (git.silcnet.org [81.89.56.81]) by ietfa.amsl.com (Postfix) with ESMTP id BE56F21F86BC for ; Sun, 4 Nov 2012 23:22:18 -0800 (PST) Received: from git.silcnet.org (localhost [127.0.0.1]) by git.silcnet.org (8.14.4+Sun/8.14.4) with ESMTP id qA57MFOr010737; Mon, 5 Nov 2012 08:22:15 +0100 (CET) Received: from localhost (priikone@localhost) by git.silcnet.org (8.14.4+Sun/8.14.4/Submit) with ESMTP id qA57M9bQ010734; Mon, 5 Nov 2012 08:22:09 +0100 (CET) X-Authentication-Warning: git.silcnet.org: priikone owned process doing -bs Date: Mon, 5 Nov 2012 08:22:09 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@git.silcnet.org To: Paul Hoffman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: IPsecme WG Subject: Re: [IPsec] ECDSA for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 07:22:19 -0000 On Fri, 2 Nov 2012, Paul Hoffman wrote: : The design team decided it is best to add just one new authentication : method, that will support all kinds of signature methods. This : includes all ECDSA and other EC-based methods (ECGDSA) and can also : support other algorithms too (RSA-PSS or even ElGamal). : Good, that's better than having per-auth method ids. : The EC group is assumed to be known from the certificate or raw key, : and there is no need to explicitly negotiate or identify it. : It must be specified explicitly how this information can be retrieved from different certs. : This new method will be negotiated using the Notify Payloads in the : IKE_SA_INIT, and those same payloads can be used to indicate the : supported hash algoritms. : Why is the notify needed? Why can't the new method be like old methods? If remote doesn't support the new authentication method, authentication will fail. If it doesn't support the algorithm in the OID, authentication will fail. Why does the hash algorithm have to be negotiated? Why the extra complexity? And peer will indicate that it supports the new method simply by using that method in the Auth payload. What's the use case I'm missing here? Pekka From Johannes.Merkle@secunet.com Mon Nov 5 04:25:46 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE36B21F85BA for ; Mon, 5 Nov 2012 04:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEvKbMkctAAP for ; Mon, 5 Nov 2012 04:25:46 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id BB0D621F85B6 for ; Mon, 5 Nov 2012 04:25:45 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 651FB1A007A; Mon, 5 Nov 2012 13:25:42 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id C78011A007B; Mon, 5 Nov 2012 13:25:33 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Nov 2012 13:25:33 +0100 Message-ID: <5097B03D.5050004@secunet.com> Date: Mon, 05 Nov 2012 13:25:33 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Sean Turner References: <5096971D.5040909@ieca.com> In-Reply-To: <5096971D.5040909@ieca.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2012 12:25:33.0618 (UTC) FILETIME=[A6F0A920:01CDBB50] Cc: IPsecme WG Subject: Re: [IPsec] ECDSA for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 12:25:47 -0000 Sean, >> The EC group is assumed to be known from the certificate or raw key, >> and there is no need to explicitly negotiate or identify it. > > For the certificate case, I assume this means the draft will follow what's in the RFC 5480 wrt the SPKI > AlgorithmIdentifier - i.e., the curve is always named by the OID. Yes, although it would also work with specifiedCurve which is deprecated in RFC 5480. > > Aside: For RSA-PSS parameters don't always appear in the SPKI AlgorithmIdentifier field - see RFC 5756. > RSA-PSS has certainly not been in the focus of our design, but only a side-product. Thus, we have tried support it only as far as possible *without extending the mechanisms*. For this reason, only RSA-PSS SPKI AlgorithmIdentifiers with parameters specified (either explicit or by using the defaults) are supported. Adding a means to signal RSA-PSS parameters in IKEv2 would have introduced considerable complexity. > >> The old EC-DSA method should be deprecated, but only after the new >> methods are supported, meaning the document should say that if new >> method is supported by both ends it SHOULD/MUST be used. > > Make sure the draft indicates it updates RFC 5996. > > In the examples above, *WithRSAEncryption and dsa-with-* are listed so are we really talking about deprecating all of > the previous "signature" values from the IANA registry: > > V Alg Ref > -------------------------------------------------- > 1 RSA Digital Signature [RFC5996] > 3 DSS Digital Signature [RFC5996] > 9 ECDSA with SHA-256 on the P-256 curve [RFC4754] > 10 ECDSA with SHA-384 on the P-384 curve [RFC4754] > 11 ECDSA with SHA-512 on the P-521 curve [RFC4754] > The design team decided to deprecate DSS in case that the new method is supported. There was no decision (or even discussion) on whether to deprecate RSA Digital Signature. This is still to be discussed. >> Sending this notification tells that new "Digital Signature" >> authentication method is supported and that following hash functions >> are supported by sending peer. Both ends sends their list of supported >> hash-algorithms and when calculating signature a peer MUST pick one >> algorithm sent by the other peer. Note, that different algorithms can >> be used in different directions. The actual algoritm used when >> calculating the signature is sent inside the Authentication Data field >> of the Authentication Payload. > > Assuming here that this new notify is normally sent during the IKE_SA_INIT exchange from the responder to the initiator: > > a) The initiator actually figures out the signature algorithms supported by the responder based on the new Notify > message, Alg ID parameter, and the cert's key usage extension? The SPKI will include id-ecPublicKey not ecdsa-with-* > right so you can't rely on that. You can't rely on just the Alg ID parameter because the key usage extension can have > any combination of digitalSignature, nonRepudiation, and keyAgreement set. So don't you have to look at all three? > I am not sure I get your point regarding the key usage extension. As we talk about authentication through digital signatures, I guess that digitalSignature MUST be set in the KE extension anyway. You correctly point out a limitation of the negotiation mechanism (through the notify payload) to the hash algorithm. Negotiation of the signature algorithm was not considered as the focus was on the digital signature algorithms currently supported in IKEv2, i.e. ECDSA, DSA and RSA. EC-based signature schemes other than ECDSA are hardly used in practice and RFC 5480 does not list any. If someone desires to use Nyberg-Rueppel, EC-ElGamal or EC-Schnorr signatures, she can do so but without negotiation. Do you advocate a negotiation of the signature algorithm? Note: ECGDSA keys (which are actually used for IKE in Germany) are not specified by id-ecPublicKe but by a dedicated OID ecgPublicKey as the relation between private and public key differs from ECDSA keys. -- Johannes From Johannes.Merkle@secunet.com Mon Nov 5 04:44:20 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC3C21F859B for ; Mon, 5 Nov 2012 04:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USgUb0iok-C4 for ; Mon, 5 Nov 2012 04:44:19 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id BB4F421F853B for ; Mon, 5 Nov 2012 04:44:19 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id F02471A007B; Mon, 5 Nov 2012 13:44:16 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 73D911A007A; Mon, 5 Nov 2012 13:44:08 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Nov 2012 13:44:08 +0100 Message-ID: <5097B497.3010005@secunet.com> Date: Mon, 05 Nov 2012 13:44:07 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Pekka Riikonen References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2012 12:44:08.0265 (UTC) FILETIME=[3F524B90:01CDBB53] Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] ECDSA for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 12:44:20 -0000 Pekka, > > : This new method will be negotiated using the Notify Payloads in the > : IKE_SA_INIT, and those same payloads can be used to indicate the > : supported hash algoritms. > : > Why is the notify needed? Why can't the new method be like old methods? > If remote doesn't support the new authentication method, authentication > will fail. If it doesn't support the algorithm in the OID, authentication > will fail. Why does the hash algorithm have to be negotiated? Why the > extra complexity? And peer will indicate that it supports the new method > simply by using that method in the Auth payload. What's the use case I'm > missing here? I think we have to distinguish two aspects: negotiation of the general auth method (old or new) and negotiation of the hash algorithm. Regarding the negotiation of the hash algorithm: If there is no intersection between the sets of hash algorithms supported by the peers, failure is inevitable. But in case that there is an intersection, the negotiation allows to agree on it. -- Johannes From mglt.ietf@gmail.com Mon Nov 5 04:48:42 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB1B21F85FE; Mon, 5 Nov 2012 04:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScQhj6qxKXEb; Mon, 5 Nov 2012 04:48:42 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A03B821F8599; Mon, 5 Nov 2012 04:48:41 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so6521040vbb.31 for ; Mon, 05 Nov 2012 04:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=NDhxxm30H7c5sb/3SltOEGaiDTsZGWI9m90/8EqdN+c=; b=xyQetWM+gqi2bqOl2WtVFZwklEAuP1XuiLbl4jG8Ji7tnw1J9Jk9kIBcMdNu7ysraZ 7MyUvuT6hcgR4s4Nckz+omv8+p7soTX1+ZNtN6w1Q3j1U+IiDMcwvhq6nC+X7FCnihpF 8b1Fy8xHZd6/+AtUAJoZEDm02gr7hoXp/oAfHMHdlaj6NiMmbx7xhtpClkGELlBEJbS0 +2udqKpFITXNVI22afwio7rYjOXicApKoGsm263VSZLQH0WENnleR0edNrmzACLuQ8VQ OLubkm0oNwINojDKKIqvBy6VqBF6umd2FAyNfHi4KTchPnD7tDX3F7E8fOyPKD/ckaLU B8gA== MIME-Version: 1.0 Received: by 10.52.34.42 with SMTP id w10mr8281383vdi.10.1352119721103; Mon, 05 Nov 2012 04:48:41 -0800 (PST) Received: by 10.58.155.69 with HTTP; Mon, 5 Nov 2012 04:48:41 -0800 (PST) In-Reply-To: <20121105124656.1185.88759.idtracker@ietfa.amsl.com> References: <20121105124656.1185.88759.idtracker@ietfa.amsl.com> Date: Mon, 5 Nov 2012 07:48:41 -0500 Message-ID: From: Daniel Migault To: mif@ietf.org, ipsec@ietf.org Content-Type: multipart/alternative; boundary=20cf3079bb98ab8f2804cdbee72d Subject: [IPsec] Fwd: New Version Notification for draft-mglt-mif-security-requirements-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 12:48:43 -0000 --20cf3079bb98ab8f2804cdbee72d Content-Type: text/plain; charset=ISO-8859-1 Hi, Here is the new version of our draft on IPsec and multiple Interfaces. Best Regards, Daniel ---------- Forwarded message ---------- From: Date: Mon, Nov 5, 2012 at 7:46 AM Subject: New Version Notification for draft-mglt-mif-security-requirements-03.txt To: mglt.ietf@gmail.com Cc: carlw@mcsr-labs.org A new version of I-D, draft-mglt-mif-security-requirements-03.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Filename: draft-mglt-mif-security-requirements Revision: 03 Title: IPsec Multiple Interfaces Problem Statement Creation date: 2012-11-03 WG ID: Individual Submission Number of pages: 27 URL: http://www.ietf.org/internet-drafts/draft-mglt-mif-security-requirements-03.txt Status: http://datatracker.ietf.org/doc/draft-mglt-mif-security-requirements Htmlized: http://tools.ietf.org/html/draft-mglt-mif-security-requirements-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-mglt-mif-security-requirements-03 Abstract: IKEv2 is the protocol used to set up and negotiate Security Associations between nodes. IKEv2 has not been designed for nodes with multiple interfaces. This document is focused on IKEv2 ability to set up IPsec protected communications between nodes with multiple interfaces. This document states the problems and provides requirements for IKEv2 to ease IPsec for multiple interface communication. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --20cf3079bb98ab8f2804cdbee72d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=A0

Here is the new version of our draft on IPsec and= multiple Interfaces.

Best Regards,=A0
D= aniel

---------- Forwarded message ------= ----
From: <internet-drafts@ietf.org>
= Date: Mon, Nov 5, 2012 at 7:46 AM
Subject: New Version Notification for = draft-mglt-mif-security-requirements-03.txt
To: mglt.ietf@gmail.com
Cc: <= a href=3D"mailto:carlw@mcsr-labs.org">carlw@mcsr-labs.org


A new version of I-D, draft-mglt-mif-security-requirements-03.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mglt-mif-security-requirements
Revision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 IPsec Multiple Interfaces Problem Statement
Creation date: =A0 2012-11-03
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 27
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.= ietf.org/internet-drafts/draft-mglt-mif-security-requirements-03.txt Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.= org/doc/draft-mglt-mif-security-requirements
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/d= raft-mglt-mif-security-requirements-03
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.= org/rfcdiff?url2=3Ddraft-mglt-mif-security-requirements-03

Abstract:
=A0 =A0IKEv2 is the protocol used to set up and negotiate Security
=A0 =A0Associations between nodes. =A0IKEv2 has not been designed for nodes=
=A0 =A0with multiple interfaces.

=A0 =A0This document is focused on IKEv2 ability to set up IPsec protected<= br> =A0 =A0communications between nodes with multiple interfaces. =A0This docum= ent
=A0 =A0states the problems and provides requirements for IKEv2 to ease IPse= c
=A0 =A0for multiple interface communication.




The IETF Secretariat




--
Daniel Migault
Orange = Labs -- Security
+33 6 70 72 69 58
--20cf3079bb98ab8f2804cdbee72d-- From Johannes.Merkle@secunet.com Mon Nov 5 05:35:19 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59ED021F85A1 for ; Mon, 5 Nov 2012 05:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+4-dxjEJx9T for ; Mon, 5 Nov 2012 05:35:18 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id BE1D621F84C9 for ; Mon, 5 Nov 2012 05:35:18 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id E44441A007A; Mon, 5 Nov 2012 14:35:17 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id DD0641A007E; Mon, 5 Nov 2012 14:35:08 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Nov 2012 14:35:08 +0100 Message-ID: <5097C08B.9070206@secunet.com> Date: Mon, 05 Nov 2012 14:35:07 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: IPsecme WG X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2012 13:35:08.0683 (UTC) FILETIME=[5F7905B0:01CDBB5A] Cc: rfc-ise@rfc-editor.org Subject: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 13:35:19 -0000 We have submitted a new revision of the Internet Draft Using the ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ Last week, this draft has also been submitted to the Independent Submission Editor. The draft specifies 4 new code points for the IKEv2 transform ID registry (224, 256, 384 and 512 bit curve) and specifies the encoding of the KE payload with and without point compression. The test vectors are shared with Dan's draft on IKEv1 http://tools.ietf.org/html/draft-harkins-brainpool-ike-groups-01. I have removed the "twisted curves" and included a note how to use them internally (for efficient implementation) using input / output transformations. Any feedback is welcome. -- Johannes From mcgrew@cisco.com Mon Nov 5 07:35:56 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBD521F96C3 for ; Mon, 5 Nov 2012 07:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fD7TkBcyYPiZ for ; Mon, 5 Nov 2012 07:35:55 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4D121F8711 for ; Mon, 5 Nov 2012 07:34:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5340; q=dns/txt; s=iport; t=1352129681; x=1353339281; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=U0qkx3coEEWlpTEFJisMNhvd/OY+jZUIAyFEfNFgKjE=; b=E/Ae0WrQVWTs0AFQn38AiaqNu3SL7x9uZB50PGWv2OxmZ+SS/YPCJf0E 0TITracys3DkznRKogU5mD8C7NlnKTxxZjao3x3DrPfVGE7SnDWLTlwXt juGKUYfC6sOMG8PUZ3Xsiivi8ZlPAGXnWEd58ygYjl+EN0auRS4AdhhU0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFPbl1CtJXG9/2dsb2JhbABEwzqBCIIgAQQBAQEPASc0CxIBCCIUMQYLJQIEAQ0FCBqHVgMPC5pnlgkNiVSLGWqFWWEDkkmBXYJxiheDJoFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,715,1344211200"; d="scan'208";a="138920044" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 05 Nov 2012 15:34:39 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA5FYdpT006181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 15:34:39 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 09:34:39 -0600 From: "David McGrew (mcgrew)" To: Yaron Sheffer , Paul Hoffman , "Black, David" , Yoav Nir , "Scott Fluhrer (sfluhrer)" Thread-Topic: [IPsec] updating ESP and AH requirements Thread-Index: AQHNs8TYQ7I8iYBJX0Kl4cYdKFcTzJfbf1gA Date: Mon, 5 Nov 2012 15:34:38 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F5071AA@xmb-rcd-x04.cisco.com> In-Reply-To: <508B071C.1000609@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.82.224.12] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--35.297500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <14DB774EA459E4489887D8B52E5AB560@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , "wajdi.k.feghali@intel.com" Subject: Re: [IPsec] updating ESP and AH requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:35:56 -0000 Thanks Yaron, Paul, David, Yoav, and Scott for your input on the draft and the issues it addresses. The main concern so far has been the TDES-CBC encryption guidance. I was unable to find a reference that gives a good treatment of attacks on 64-bit block ciphers used at and beyond the birthday bound, so I wrote one up; it is online at . What is most relevant to TDES-CBC are Sections 2 and 4. Table 1 shows the expected number of bits leaked by TDES-CBC (the w=3D64 row) with that of AES-CBC (th= e w=3D128 row) for comparison. The security benefits of AES, and the risks o= f over-used TDES, clearly warrant some deprecation of TDES. Several folks have made the valid points that interoperability with pre-2003 implementations requires TDES-CBC encryption, and that TDES-CBC can provide security if it protects low-volume traffic. I propose putting TDES-CBC as a MAY- implement, and adding the following text to the Usage Guidance section: "IPsec implementations from before 2003 will not support AES-CBC encryption. New implementations that aim to interoperate with these earlier implementations will need Triple-DES CBC encryption. However, AES-GCM and AES-CBC provide significantly stronger confidentiality, and SHOULD be used instead of TDES-CBC whenever possible. AES-CCM and AES-CTR also provide stronger confidentiality than TDES. When TDES is used, it SHOULD NOT encrypt more than 50 Megabytes of data with a single key; otherwise, it may start to leak information about plaintexts to attackers [citation]." In my opinion "MAY-" is better than "MAY" because TDES is and should be on a clear path to retirement, and if history is any guide, the ESP requirements won't be updated again until 2019. But as this is intended to be a standards track document, I will defer to the opinion of the group. It may be useful to also add specific guidance that IKE proposals should put AES before TDES, since that policy achieves the goals of using AES when possible and TDES when it is the only option. This touches on the general issue of the evolution of crypto requirements, and it would make sense to define a category of "use only for backwards compatibility" algorithms and key sizes. What do you think, would this make things more or less clear to implementers and users of IPsec? Some people have commented that TDES-CBC is worth keeping around in order to provide algorithm diversity. I respectfully disagree, for several technical reasons. First, it is hard to conceive of a set of realistic circumstances in which TDES would provide better security than AES. The security degradation due to TDES being 64 bits wide, versus the 128 bit width of AES, is far more significant than the effects of block cipher cryptanalysis techniques such as differential, linear, integral, algebraic, and biclique cryptanalysis. For example: the biclique attack on AES-128 requires 2^88 chosen plaintexts/ciphertexts and takes O(2^126) operations, which is a million times as much plaintext than that needed for collision attack on AES-CBC, and 2^62 times as much computation. Also, the structure of TDES makes it open to attacks such as that of Stefan Lucks [1]. Second, supposing that in some bizarre alternate universe AES was believed to be less secure than TDES, the performance differences between TDES-CBC and AES are such that the former is not a viable replacement for the latter; this is especially true for AES-GCM, AES-CCM, and AES-CTR. Thus it does not make sense to consider retaining TDES for the sake of algorithm diversity. I do think that algorithm diversity is a valid goal, but one that deserves more deliberate consideration. Important goals for an alternative cipher would be AES compatibility, in the sense of draft-irtf-cfrg-cipher-catalog-01 Section 3.1, security, performance, no IPR issues, and ideally, diversity from the AES design methodology. I would also be interested in hearing input on the other algorithm changes. =20 Thanks again, and regards, David [1] S. Lucks, "Attacking Triple Encryption", Proceedings of the 5th International Workshop on Fast Software Encryption workshop, Springer-Verlag, 1998. On 10/26/12 5:56 PM, "Yaron Sheffer" wrote: >The need to interoperate with older implementations, as well as Yoav's >justification of having a widely implemented algorithm as a backup for >AES, both seem to argue for keeping 3DES as a MAY or MAY-. > >I suggest to include a concrete recommendation on rekeying. We could >argue the numbers forever, but I think a 1/1,000,000 probability for a >single collision is good enough. So we could RECOMMEND a rekey once >every 50 MB sent. > >Thanks, > Yaron > >-- > >It is not a question of implementing new: *all* new systems coming into >the VPNC lab have AES-CBC, and have for a few years. However, if those >implementations want to interoperate with older implementations, they >need to also have 3DES. Thus, a "MAY" for 3DES with a clear explanation >why it is inappropriate in high-volume implementations would be >valuable. --Paul Hoffman >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Mon Nov 5 10:30:56 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E08721F8848 for ; Mon, 5 Nov 2012 10:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cT+RSFocuKqZ for ; Mon, 5 Nov 2012 10:30:55 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A568221F88FB for ; Mon, 5 Nov 2012 10:30:54 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qA5IUS6h020153; Mon, 5 Nov 2012 20:30:28 +0200 X-CheckPoint: {50980322-11-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 5 Nov 2012 20:30:16 +0200 From: Yoav Nir To: "David McGrew (mcgrew)" Date: Mon, 5 Nov 2012 20:30:16 +0200 Thread-Topic: [IPsec] updating ESP and AH requirements Thread-Index: Ac27g5o7Iwo0bLQXS9W/PfJZ8eGaTA== Message-ID: References: <747787E65E3FBD4E93F0EB2F14DB556B0F5071AA@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F5071AA@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Black, David" , Paul Hoffman , IPsecme WG , "Scott Fluhrer \(sfluhrer\)" , "wajdi.k.feghali@intel.com" Subject: Re: [IPsec] updating ESP and AH requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:30:56 -0000 By the formula in that paper, if we rekey every 10 seconds, 3DES is good en= ough up to about 10 Gbps, which is pretty high end for most VPNs. The IKE i= mplementation that goes with a 10 Gbps IPsec implementation should have no = problem rekeying every 10 seconds. I don't think it matters much whether 3DES is SHOULD- or MAY, but I do thin= k we need to have algorithm diversity. IPsecME is not the venue for a compe= tition like those that NIST held, but perhaps we should go over the ciphers= specified in section 4 of the cipher catalog, and choose a backup cipher t= o become a SHOULD in the requirements draft. Yoav On Nov 5, 2012, at 10:34 AM, David McGrew (mcgrew) wrote: > Thanks Yaron, Paul, David, Yoav, and Scott for your input on the draft an= d > the issues it addresses. >=20 > The main concern so far has been the TDES-CBC encryption guidance. I was > unable to find a reference that gives a good treatment of attacks on > 64-bit block ciphers used at and beyond the birthday bound, so I wrote on= e > up; it is online at . What is most > relevant to TDES-CBC are Sections 2 and 4. Table 1 shows the expected > number of bits leaked by TDES-CBC (the w=3D64 row) with that of AES-CBC (= the > w=3D128 row) for comparison. The security benefits of AES, and the risks= of > over-used TDES, clearly warrant some deprecation of TDES. >=20 > Several folks have made the valid points that interoperability with > pre-2003 implementations requires TDES-CBC encryption, and that TDES-CBC > can provide security if it protects low-volume traffic. I propose > putting TDES-CBC as a MAY- implement, and adding the following text to th= e > Usage Guidance section: "IPsec implementations from before 2003 will not > support AES-CBC encryption. New implementations that aim to interoperate > with these earlier implementations will need Triple-DES CBC encryption. > However, AES-GCM and AES-CBC provide significantly stronger > confidentiality, and SHOULD be used instead of TDES-CBC whenever possible= . > AES-CCM and AES-CTR also provide stronger confidentiality than TDES. > When TDES is used, it SHOULD NOT encrypt more than 50 Megabytes of data > with a single key; otherwise, it may start to leak information about > plaintexts to attackers [citation]." In my opinion "MAY-" is better than > "MAY" because TDES is and should be on a clear path to retirement, and if > history is any guide, the ESP requirements won't be updated again until > 2019. But as this is intended to be a standards track document, I will > defer to the opinion of the group. >=20 > It may be useful to also add specific guidance that IKE proposals should > put AES before TDES, since that policy achieves the goals of using AES > when possible and TDES when it is the only option. This touches on the > general issue of the evolution of crypto requirements, and it would make > sense to define a category of "use only for backwards compatibility" > algorithms and key sizes. What do you think, would this make things more > or less clear to implementers and users of IPsec? >=20 > Some people have commented that TDES-CBC is worth keeping around in order > to provide algorithm diversity. I respectfully disagree, for several > technical reasons. First, it is hard to conceive of a set of realistic > circumstances in which TDES would provide better security than AES. The > security degradation due to TDES being 64 bits wide, versus the 128 bit > width of AES, is far more significant than the effects of block cipher > cryptanalysis techniques such as differential, linear, integral, > algebraic, and biclique cryptanalysis. For example: the biclique attack o= n > AES-128 requires 2^88 chosen plaintexts/ciphertexts and takes O(2^126) > operations, which is a million times as much plaintext than that needed > for collision attack on AES-CBC, and 2^62 times as much computation. > Also, the structure of TDES makes it open to attacks such as that of > Stefan Lucks [1]. Second, supposing that in some bizarre alternate > universe AES was believed to be less secure than TDES, the performance > differences between TDES-CBC and AES are such that the former is not a > viable replacement for the latter; this is especially true for AES-GCM, > AES-CCM, and AES-CTR. Thus it does not make sense to consider retaining > TDES for the sake of algorithm diversity. I do think that algorithm > diversity is a valid goal, but one that deserves more deliberate > consideration. Important goals for an alternative cipher would be AES > compatibility, in the sense of draft-irtf-cfrg-cipher-catalog-01 Section > 3.1, security, performance, no IPR issues, and ideally, diversity from th= e > AES design methodology. >=20 > I would also be interested in hearing input on the other algorithm > changes. =20 >=20 > Thanks again, and regards, >=20 > David >=20 > [1] S. Lucks, "Attacking Triple Encryption", Proceedings of the 5th > International Workshop on Fast Software Encryption workshop, > Springer-Verlag, 1998. >=20 > On 10/26/12 5:56 PM, "Yaron Sheffer" wrote: >=20 >> The need to interoperate with older implementations, as well as Yoav's >> justification of having a widely implemented algorithm as a backup for >> AES, both seem to argue for keeping 3DES as a MAY or MAY-. >>=20 >> I suggest to include a concrete recommendation on rekeying. We could >> argue the numbers forever, but I think a 1/1,000,000 probability for a >> single collision is good enough. So we could RECOMMEND a rekey once >> every 50 MB sent. >>=20 >> Thanks, >> Yaron >>=20 >> -- >>=20 >> It is not a question of implementing new: *all* new systems coming into >> the VPNC lab have AES-CBC, and have for a few years. However, if those >> implementations want to interoperate with older implementations, they >> need to also have 3DES. Thus, a "MAY" for 3DES with a clear explanation >> why it is inappropriate in high-volume implementations would be >> valuable. --Paul Hoffman From kivinen@iki.fi Mon Nov 5 11:02:29 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46AD21F879E for ; Mon, 5 Nov 2012 11:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6cpkP9vuPKG for ; Mon, 5 Nov 2012 11:02:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id E9ABC21F8A51 for ; Mon, 5 Nov 2012 11:02:28 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA5J2QLw007703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2012 21:02:26 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA5J2QDf001222; Mon, 5 Nov 2012 21:02:26 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20632.3394.4485.742169@fireball.kivinen.iki.fi> Date: Mon, 5 Nov 2012 21:02:26 +0200 From: Tero Kivinen To: Pekka Riikonen In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] ECDSA for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:02:29 -0000 Pekka Riikonen writes: > : The EC group is assumed to be known from the certificate or raw key, > : and there is no need to explicitly negotiate or identify it. > : > It must be specified explicitly how this information can be retrieved from > different certs. I would expect it to be completely obvious if you are already able to get the public key out from the certificate or from the raw key. I mean if you are able to find the public key, part of that public key does include the EC group to be used. I do not think we need to add very explicit instructions for this, but just say that as the CERT payload (either X.509 or raw key) contains the public key, and that public keys is required anyways to verify the AUTH payload, it is assumed that implemenations know how to parse that and get the EC group from there. > : This new method will be negotiated using the Notify Payloads in the > : IKE_SA_INIT, and those same payloads can be used to indicate the > : supported hash algoritms. > : > Why is the notify needed? Why can't the new method be like old > methods? If remote doesn't support the new authentication method, > authentication will fail. If it doesn't support the algorithm in the > OID, authentication will fail. Why does the hash algorithm have to > be negotiated? Why the extra complexity? And peer will indicate that > it supports the new method simply by using that method in the Auth > payload. What's the use case I'm missing here? I would be happy to just use notifications without hash algorithms, and assume that peer can properly guess which hash should work with the other end. This is how it is done in old methods, but other people considered as we are now getting more usable hash algoritms (sha-3), there might be more and more problems with this, and solving this problem now before it is really an issue is better. Currently if you want to make sure the hash is acceptable, you select SHA-1. If you do not want to use SHA-1 and want something stronger, you will then most likely use SHA-256 or similar. But if you want to prefer SHA-256, but still allow SHA-1 just in case the remote peer does not support it, this not something you can easily do now. You can make one IKE SA negotiation with SHA-256 and then when it fails, try again with SHA-1, but that is quite costly operation. -- kivinen@iki.fi From mcgrew@cisco.com Mon Nov 5 11:17:47 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A570C21F8540 for ; Mon, 5 Nov 2012 11:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-P0mesfasCV for ; Mon, 5 Nov 2012 11:17:47 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id F3E9821F8532 for ; Mon, 5 Nov 2012 11:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1986; q=dns/txt; s=iport; t=1352143067; x=1353352667; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=t7e185SbrQ659TH+Vo8oW62demUTCj2+MnzV2QiTJ18=; b=NSnTj0WLv+p09aE2XAZrbWWkr7JcJ/TqPx0q7YazhcQi2wR6YeS6KWbx VDVri2ilm0O1/JyNTuQwlu9AxeQwX2rZamCJgEkMbd8WSK4fbG6vK/rSv WsgkZSwoT4KpzhVRsuBteWQfxeavO+Y0PfVu7Fs1IwzY3+QGq6waAYTh3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABkQmFCtJV2Z/2dsb2JhbABEwzSBCIIgAQQBAQEPASc0CxIBCCIUNwslAgQBDQUIGodoC5pzoAmRXGEDkkmETo09gWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,716,1344211200"; d="scan'208";a="139001350" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 05 Nov 2012 19:17:43 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA5JHg81007505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 19:17:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 13:17:42 -0600 From: "David McGrew (mcgrew)" To: Johannes Merkle , IPsecme WG Thread-Topic: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Thread-Index: AQHNu1ps1FUub1JjY0W7Zvt4S+0awJfbrn+A Date: Mon, 5 Nov 2012 19:17:41 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F507509@xmb-rcd-x04.cisco.com> In-Reply-To: <5097C08B.9070206@secunet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.82.240.65] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--40.628100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rfc-ise@rfc-editor.org" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:17:47 -0000 Hi Johannes, Some quick comments: I strongly encourage you to remove the "Compressed" point format. Doing so will minimize the changes between RFC 5903 and make the draft easier to support, and improve the overall implementation by making it simpler. Also, it is not clear that there is any advantage to the "compressed" format. It saves at most 64 bytes in total for a complete IKEv2 key establishment, and since IKEv2 exchanges typically send a lot more data than that, it sounds like a false economy to add complexity in order to avoid a little bit of data. The paragraph starting "The corresponding twisted curves ..." is a distinct and self-contained topic. I suggest putting it into its own section. =20 In some places, the draft gives [SEC1] as a normative reference, where RFC6090 is also applicable (Sections 4.1 and 6 apply jn Section 2.2 of draft-merkle-ikev2-ke-brainpool, for instance). David On 11/5/12 8:35 AM, "Johannes Merkle" wrote: >We have submitted a new revision of the Internet Draft Using the ECC >Brainpool Curves (defined in RFC 5639) for IKEv2 >Key Exchange >https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ > >Last week, this draft has also been submitted to the Independent >Submission Editor. > >The draft specifies 4 new code points for the IKEv2 transform ID registry >(224, 256, 384 and 512 bit curve) and >specifies the encoding of the KE payload with and without point >compression. The test vectors are shared with Dan's >draft on IKEv1=20 >http://tools.ietf.org/html/draft-harkins-brainpool-ike-groups-01. I have >removed the "twisted curves" and >included a note how to use them internally (for efficient implementation) >using input / output transformations. > >Any feedback is welcome. > >--=20 >Johannes >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From mcgrew@cisco.com Mon Nov 5 12:03:48 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BC021F8480 for ; Mon, 5 Nov 2012 12:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeQgZYPrWntf for ; Mon, 5 Nov 2012 12:03:47 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD4821F8792 for ; Mon, 5 Nov 2012 12:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7410; q=dns/txt; s=iport; t=1352145823; x=1353355423; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=av5rXxsdnf+UzSXgD+mG4UjVj5ISrL3XT1QGet5yd1Q=; b=YaQoacoES57xV5y90zbzGS1ncOxVkWBzrFSmu0ob7xmhf+EwiRJ2AMC8 288Szm9hSVeezq+dhTHGisIHFGSb+1+sMFWsES1kHYN3mff1TmzrgQREy g/wd94fHxXocJVfWEH3wPmBSfP4xXXN7Vb/ByLQsMvC+ZtmaihJbb0Owc U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKoamFCtJV2d/2dsb2JhbABEwzSBCIIeAQEBBBIBJz8SAQgOCgoUMRElAgQOBQgah1YDD5p/lisNiVSLGWgChVlhA5JJgV2CcYoXgyaBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,716,1344211200"; d="scan'208";a="139019413" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 05 Nov 2012 20:03:42 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qA5K3gPd007962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Nov 2012 20:03:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 14:03:41 -0600 From: "David McGrew (mcgrew)" To: Yoav Nir Thread-Topic: [IPsec] updating ESP and AH requirements Thread-Index: AQHNs8TYQ7I8iYBJX0Kl4cYdKFcTzJfbf1gAgACE5wD//8ZDgA== Date: Mon, 5 Nov 2012 20:03:41 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F50757F@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.82.240.65] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--35.144700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Black, David" , Paul Hoffman , IPsecme WG , "Scott Fluhrer \(sfluhrer\)" , "wajdi.k.feghali@intel.com" Subject: Re: [IPsec] updating ESP and AH requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 20:03:48 -0000 Hi Yoav, On 11/5/12 1:30 PM, "Yoav Nir" wrote: >By the formula in that paper, if we rekey every 10 seconds, 3DES is good >enough up to about 10 Gbps, which is pretty high end for most VPNs. The >IKE implementation that goes with a 10 Gbps IPsec implementation should >have no problem rekeying every 10 seconds. At the data rate and key lifetime that you mention, the expected number of bits that an attacker can glean is about two bits every ten seconds, or 2 kilobytes per day, 15 kilobytes per week, 60 kilobytes per month, 788 kilobytes per year. This is not a set of parameter choices that we should be recommending. Another consideration is: what happens if the attacker interferes with the rekeying? I agree with the idea that there are some data rates low enough that TDES is a perfectly good algorithm, but not north of one gigabit :-) > >I don't think it matters much whether 3DES is SHOULD- or MAY, but I do >think we need to have algorithm diversity. IPsecME is not the venue for a >competition like those that NIST held, but perhaps we should go over the >ciphers specified in section 4 of the cipher catalog, and choose a backup >cipher to become a SHOULD in the requirements draft. I think it makes sense to look for cipher diversity, but I don't think this is a selection that should be made hastily. Also, it would be good to have the selection of an alternate cipher be something done at the IETF level, and not at the WG level. I hope that IPsec ME can move forward with updated algorithm guidance without waiting for the selection of an alternate, which could be a protracted process. Also I notice that for ESP we will need to recommend a mode of operation as well. Thanks, David > >Yoav > >On Nov 5, 2012, at 10:34 AM, David McGrew (mcgrew) wrote: > >> Thanks Yaron, Paul, David, Yoav, and Scott for your input on the draft >>and >> the issues it addresses. >>=20 >> The main concern so far has been the TDES-CBC encryption guidance. I >>was >> unable to find a reference that gives a good treatment of attacks on >> 64-bit block ciphers used at and beyond the birthday bound, so I wrote >>one >> up; it is online at . What is most >> relevant to TDES-CBC are Sections 2 and 4. Table 1 shows the expected >> number of bits leaked by TDES-CBC (the w=3D64 row) with that of AES-CBC >>(the >> w=3D128 row) for comparison. The security benefits of AES, and the risk= s >>of >> over-used TDES, clearly warrant some deprecation of TDES. >>=20 >> Several folks have made the valid points that interoperability with >> pre-2003 implementations requires TDES-CBC encryption, and that TDES-CBC >> can provide security if it protects low-volume traffic. I propose >> putting TDES-CBC as a MAY- implement, and adding the following text to >>the >> Usage Guidance section: "IPsec implementations from before 2003 will not >> support AES-CBC encryption. New implementations that aim to >>interoperate >> with these earlier implementations will need Triple-DES CBC encryption. >> However, AES-GCM and AES-CBC provide significantly stronger >> confidentiality, and SHOULD be used instead of TDES-CBC whenever >>possible. >> AES-CCM and AES-CTR also provide stronger confidentiality than TDES. >> When TDES is used, it SHOULD NOT encrypt more than 50 Megabytes of data >> with a single key; otherwise, it may start to leak information about >> plaintexts to attackers [citation]." In my opinion "MAY-" is better >>than >> "MAY" because TDES is and should be on a clear path to retirement, and >>if >> history is any guide, the ESP requirements won't be updated again until >> 2019. But as this is intended to be a standards track document, I will >> defer to the opinion of the group. >>=20 >> It may be useful to also add specific guidance that IKE proposals should >> put AES before TDES, since that policy achieves the goals of using AES >> when possible and TDES when it is the only option. This touches on the >> general issue of the evolution of crypto requirements, and it would make >> sense to define a category of "use only for backwards compatibility" >> algorithms and key sizes. What do you think, would this make things >>more >> or less clear to implementers and users of IPsec? >>=20 >> Some people have commented that TDES-CBC is worth keeping around in >>order >> to provide algorithm diversity. I respectfully disagree, for several >> technical reasons. First, it is hard to conceive of a set of realistic >> circumstances in which TDES would provide better security than AES. The >> security degradation due to TDES being 64 bits wide, versus the 128 bit >> width of AES, is far more significant than the effects of block cipher >> cryptanalysis techniques such as differential, linear, integral, >> algebraic, and biclique cryptanalysis. For example: the biclique attack >>on >> AES-128 requires 2^88 chosen plaintexts/ciphertexts and takes O(2^126) >> operations, which is a million times as much plaintext than that needed >> for collision attack on AES-CBC, and 2^62 times as much computation. >> Also, the structure of TDES makes it open to attacks such as that of >> Stefan Lucks [1]. Second, supposing that in some bizarre alternate >> universe AES was believed to be less secure than TDES, the performance >> differences between TDES-CBC and AES are such that the former is not a >> viable replacement for the latter; this is especially true for AES-GCM, >> AES-CCM, and AES-CTR. Thus it does not make sense to consider retaining >> TDES for the sake of algorithm diversity. I do think that algorithm >> diversity is a valid goal, but one that deserves more deliberate >> consideration. Important goals for an alternative cipher would be AES >> compatibility, in the sense of draft-irtf-cfrg-cipher-catalog-01 Section >> 3.1, security, performance, no IPR issues, and ideally, diversity from >>the >> AES design methodology. >>=20 >> I would also be interested in hearing input on the other algorithm >> changes. =20 >>=20 >> Thanks again, and regards, >>=20 >> David >>=20 >> [1] S. Lucks, "Attacking Triple Encryption", Proceedings of the 5th >> International Workshop on Fast Software Encryption workshop, >> Springer-Verlag, 1998. >>=20 >> On 10/26/12 5:56 PM, "Yaron Sheffer" wrote: >>=20 >>> The need to interoperate with older implementations, as well as Yoav's >>> justification of having a widely implemented algorithm as a backup for >>> AES, both seem to argue for keeping 3DES as a MAY or MAY-. >>>=20 >>> I suggest to include a concrete recommendation on rekeying. We could >>> argue the numbers forever, but I think a 1/1,000,000 probability for a >>> single collision is good enough. So we could RECOMMEND a rekey once >>> every 50 MB sent. >>>=20 >>> Thanks, >>> Yaron >>>=20 >>> -- >>>=20 >>> It is not a question of implementing new: *all* new systems coming into >>> the VPNC lab have AES-CBC, and have for a few years. However, if those >>> implementations want to interoperate with older implementations, they >>> need to also have 3DES. Thus, a "MAY" for 3DES with a clear explanation >>> why it is inappropriate in high-volume implementations would be >>> valuable. --Paul Hoffman > From mcgrew@cisco.com Mon Nov 5 16:16:09 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B3721F85CB for ; Mon, 5 Nov 2012 16:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRpHY5VVXNTE for ; Mon, 5 Nov 2012 16:16:08 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B20FF21F85C6 for ; Mon, 5 Nov 2012 16:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1950; q=dns/txt; s=iport; t=1352160968; x=1353370568; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=f7A/y0jK6CSNAC/kip3nvmWmGt3AdUOS4Ja4iRZRE/Y=; b=WFKKFVMjehAKoL+d1gN05sgUGdV1YeRMLjCPUHzmjK0Tq28ZXK3CkZ1x cF2odz0umGHg2QBzyOd50JDyqf4ASkH8YwdEvuT4xH3EYRPPQsoOYelNB okjER79LqL58s5ui7N+9sMMM1dgcZvS5hVjSPzcND02+yl3je1I2DdVTA s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAD5WmFCtJV2Y/2dsb2JhbABEwzOBCIIgAQQBAQEPASc0ARwBCA4UFDcLJQIEARIIGodoC5p9jyg8kDIEkXBhA6RUgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,718,1344211200"; d="scan'208";a="139093700" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 06 Nov 2012 00:16:08 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qA60G86r017237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Nov 2012 00:16:08 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Mon, 5 Nov 2012 18:16:07 -0600 From: "David McGrew (mcgrew)" To: Michael Richardson , IPsecme WG Thread-Topic: [IPsec] draft-mcgrew-ipsec-me-esp-ah-reqts Thread-Index: AQHNuskC+PxRzYyHCkWkjIgghRrHg5fcAwOA Date: Tue, 6 Nov 2012 00:16:07 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F507A5D@xmb-rcd-x04.cisco.com> In-Reply-To: <23426.1352043961@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.82.224.243] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19340.004 x-tm-as-result: No--54.973700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] draft-mcgrew-ipsec-me-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 00:16:09 -0000 Hi Michael, On 11/4/12 10:46 AM, "Michael Richardson" wrote: > >What in practice, for an implementer and/or his marketing manager, is >the difference between "MAY" for algorithm and not listing it at all? > >I would understand if we had "MAY+", but really, that is what "SHOULD" >means. > >Could there implications on UIs, such that things listed SHOULD/MUST >are listed in the first page, things listed MAY are on the "Advanced >options" page, and whatever country-specific vanity ciphers that might >get included are under some even more obscure button. > >Or is the intent of MAY to give a clue to cryptoanalysis people as to what >things to focus on? Or for people GREP'ing the RFC archives as a result >of an attack will come up with IPsec as a user/ For what it's worth, RFC 4835 has two MAYs, NULL authentication and HMAC-MD5-96. =20 My thinking was that it makes sense for the document to mention the algorithm options that had been defined at the time of writing, so the reader isn't left wondering. There are other ways that this could be dealt with other ways, though. For instance, we could remove the MAYs from the tables in Sections 2.2 and 2.3, and then add a new section that says something like "The following algorithms were considered and it was determined that there was no need for recommendation to implement, or not to implement." =20 Someone mentioned in the WG meeting that algorithms that were previously SHOULDs, but have been deprecated to MAYs, should be included in the tables going forward, so that the reader doesn't wonder where it went. This seems like a good point to me. AES-CTR is the one algorithm in that category in the draft so far. Thanks, David > >--=20 >Michael Richardson >-on the road- > > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From liushucheng@huawei.com Mon Nov 5 18:41:06 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331E411E80DE for ; Mon, 5 Nov 2012 18:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xluT9-6R0BjZ for ; Mon, 5 Nov 2012 18:41:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D40D811E80D5 for ; Mon, 5 Nov 2012 18:41:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALG22696; Tue, 06 Nov 2012 02:41:03 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 6 Nov 2012 02:40:21 +0000 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 6 Nov 2012 02:40:26 +0000 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Tue, 6 Nov 2012 10:40:23 +0800 From: "Will Liu (Shucheng)" To: "ipsec@ietf.org" Thread-Topic: Will it be a good idea if we join in meetecho? Thread-Index: Ac27st34YuL+AJ3vS+uF/hXmYQ5XFg== Date: Tue, 6 Nov 2012 02:40:22 +0000 Deferred-Delivery: Tue, 6 Nov 2012 01:00:00 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.105] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB2B9A4F60szxeml546mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [IPsec] Will it be a good idea if we join in meetecho? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 02:41:06 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB2B9A4F60szxeml546mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I see that several WGs are in here. http://ietf85.conf.meetecho.com/ Do you think it would be a good idea that we also join this? Will --_000_C9B5F12337F6F841B35C404CF0554ACB2B9A4F60szxeml546mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I see that several WGs are in h= ere. http://ietf85.conf.meetecho.com/

Do you think it would be a good= idea that we also join this?

 

Will

--_000_C9B5F12337F6F841B35C404CF0554ACB2B9A4F60szxeml546mbxchi_-- From ynir@checkpoint.com Mon Nov 5 20:09:54 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C5511E80BA for ; Mon, 5 Nov 2012 20:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABsjSBvbwcZy for ; Mon, 5 Nov 2012 20:09:54 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B061821F84A8 for ; Mon, 5 Nov 2012 20:09:53 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qA649juE021816; Tue, 6 Nov 2012 06:09:46 +0200 X-CheckPoint: {50988AE2-3-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 6 Nov 2012 06:09:44 +0200 From: Yoav Nir To: "Will Liu (Shucheng)" Date: Tue, 6 Nov 2012 06:09:44 +0200 Thread-Topic: [IPsec] Will it be a good idea if we join in meetecho? Thread-Index: Ac271I10adpV+p6VT9KXbxurLLPpSg== Message-ID: <2A09E170-7C8E-4243-8069-297A9FFBFB18@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_2A09E1707C8E42438069297A9FFBFB18checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Will it be a good idea if we join in meetecho? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 04:09:54 -0000 --_000_2A09E1707C8E42438069297A9FFBFB18checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Too late now that our meeting's over. On Nov 5, 2012, at 9:40 PM, Will Liu (Shucheng) wrote: Hi all, I see that several WGs are in here. http://ietf85.conf.meetecho.com/ Do you think it would be a good idea that we also join this? Will _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_2A09E1707C8E42438069297A9FFBFB18checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,<= /span>
 
I see that several WGs are i= n here. http://ietf85.conf.meetecho.com/
Do you think it would be a good idea that we = also join this?
 
W= ill
__________________________________________= _____
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --_000_2A09E1707C8E42438069297A9FFBFB18checkpointcom_-- From paul.hoffman@vpnc.org Tue Nov 6 06:20:42 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6830921F81FE for ; Tue, 6 Nov 2012 06:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvcQQ+J3WILD for ; Tue, 6 Nov 2012 06:20:41 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 27AD521F8685 for ; Tue, 6 Nov 2012 06:20:41 -0800 (PST) Received: from dhcp-6045.meeting.ietf.org (dhcp-6045.meeting.ietf.org [130.129.96.69]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qA6EKZ4H017397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 6 Nov 2012 07:20:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <2A09E170-7C8E-4243-8069-297A9FFBFB18@checkpoint.com> Date: Tue, 6 Nov 2012 09:20:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A09E170-7C8E-4243-8069-297A9FFBFB18@checkpoint.com> To: "Will Liu (Shucheng)" X-Mailer: Apple Mail (2.1499) Cc: IPsecme WG Subject: Re: [IPsec] Will it be a good idea if we join in meetecho? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 14:20:42 -0000 On Nov 5, 2012, at 11:09 PM, Yoav Nir wrote: > Too late now that our meeting's over. >=20 >=20 > On Nov 5, 2012, at 9:40 PM, Will Liu (Shucheng) wrote: >=20 >> Hi all, >> =20 >> I see that several WGs are in here. http://ietf85.conf.meetecho.com/ >> Do you think it would be a good idea that we also join this? I'm confused as well. What value would there be to join Meetecho after = the meeting? --Paul Hoffman From mcr@sandelman.ca Tue Nov 6 10:25:26 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B4A21F8ABF for ; Tue, 6 Nov 2012 10:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPRY1MOHyIHo for ; Tue, 6 Nov 2012 10:25:26 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id E450221F88DC for ; Tue, 6 Nov 2012 10:25:25 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 2A26981A9 for ; Tue, 6 Nov 2012 13:17:17 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5C921CA0BC for ; Tue, 6 Nov 2012 13:25:24 -0500 (EST) From: Michael Richardson To: IPsecme WG In-reply-to: <747787E65E3FBD4E93F0EB2F14DB556B0F507A5D@xmb-rcd-x04.cisco.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F507A5D@xmb-rcd-x04.cisco.com> Comments: In-reply-to "David McGrew (mcgrew)" message dated "Tue, 06 Nov 2012 00:16:07 +0000." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 06 Nov 2012 13:25:24 -0500 Message-ID: <1802.1352226324@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] draft-mcgrew-ipsec-me-esp-ah-reqts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:25:26 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable David McGrew (mcgrew) wrote: DM> My thinking was that it makes sense for the document to mention DM> the algorithm options that had been defined at the time of DM> writing, so the reader isn't left wondering. There are other Surely we have lots of vanity crypto which has code points which aren't in this document.? DM> Someone mentioned in the WG meeting that algorithms that were DM> previously SHOULDs, but have been deprecated to MAYs, should be DM> included in the tables going forward, so that the reader doesn't DM> wonder where it went. This seems like a good point to me. DM> AES-CTR is the one algorithm in that category in the draft so DM> far. I agree with this. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQmVYUAAoJEKD0KQ7Gj3P2q6oH/iKc4+BO1aKuOIOAcCFzH9du +BNMmTwQhCNJEpoNG4ALUs3gEq49kAcEbRsVywrYP+syEel0euRYv6ZhLdJGeZe1 A+ZOkhKXqLk2OeM85pGSlcpIf13EpiK2l98s/b4/+FAzus7gRyHcbsSFM4gVncEp dNq7vWRNWiAjiLKiXkFugmy3UyxZXmwBL7DY8IoXIOgrl1oRUe9fLfpKtMP1wpWw wKuL+0VpuEumYBnpN+mQHDpvkZ/4xI6ONGcxrKCwN6WUMUPIsdf1ZIYrpKgCg0wa gqYYU3NQxByRx4qG6PzufdCPYoBxQWHBhOFDHANF3qeWI9PDwd3U+P3iIl5BsA8= =M5hF -----END PGP SIGNATURE----- --=-=-=-- From kivinen@iki.fi Tue Nov 6 11:02:05 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9877821F8ADA for ; Tue, 6 Nov 2012 11:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsXBsuO5XyTQ for ; Tue, 6 Nov 2012 11:02:05 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8565C21F8AB9 for ; Tue, 6 Nov 2012 11:02:04 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA6J1xB1011011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Nov 2012 21:01:59 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA6J1x7L000162; Tue, 6 Nov 2012 21:01:59 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20633.24231.244628.939482@fireball.kivinen.iki.fi> Date: Tue, 6 Nov 2012 21:01:59 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 17 min Subject: [IPsec] Which option to pick on draft-kivinen-ipsecme-oob-pubkey-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 19:02:05 -0000 My draft draft-kivinen-ipsecme-oob-pubkey-02.txt defines new way to send any type of raw public keys inside IKEv2. RFC5996 only allows sending RSA raw public keys. This means after this we would have two ways to do send RSA raw public keys, old RFC5996 and new format define din my draft. In yesterdays IPsecME meeting I asked following question about what to do with the Raw RSA Public Key Type: 1) Make this new format completely optional Leave old RFC 5996 format as is, both this new format and the old format can be used. In that case this document can be informational, and it does not need to updated RFC5996. 2) Make this new format recommended, but keep old format Leave old RFC 5996 format as is, but make this new format as preferred format, i.e. add text which says SHOULD use this new format if it is supported, and SHOULD NOT for old format. Old format can be used for backward compatibility. In this case this document should be standard track, and update RFC5996. 3) Obsolete old format Make old RFC 5996 format as MUST NOT, and officially obsolete it. This means all implementations should switch to new format as soon as possible. This document must be standard track, and update RFC5996. In the discussion we did not found out that there would have been wide use for the old RFC 5996 defined RSA raw public key, so feeling was that it would be possible to obsolete the old format. It was considered a bad idea to keep two ways of doing same thing. So now I want to know if anybody have anything against if we do just that, i.e. pick the 3rd option and obsolete the old RSA raw public key format. The another question is whether this document needs to be WG document or not. As it seems to be that we are updating the RFC5996 and obsoleting stuff from it, there seemed to be some people who felt that this should be WG document. Send your comments about this too. Please send your comments here in the list during the next two weeks (I will be traveling during the next two weeks, and plan to make necessary changes (if any) to the draft after I get back to home). -- kivinen@iki.fi From liushucheng@huawei.com Tue Nov 6 11:28:40 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8961421F8CBF for ; Tue, 6 Nov 2012 11:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GImmjGLaLiSD for ; Tue, 6 Nov 2012 11:28:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7612B21F8B70 for ; Tue, 6 Nov 2012 11:28:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMM20379; Tue, 06 Nov 2012 19:28:37 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 6 Nov 2012 19:26:36 +0000 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 7 Nov 2012 03:26:44 +0800 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Wed, 7 Nov 2012 03:26:41 +0800 From: "Will Liu (Shucheng)" To: Paul Hoffman Thread-Topic: [IPsec] Will it be a good idea if we join in meetecho? Thread-Index: Ac27st34YuL+AJ3vS+uF/hXmYQ5XFv//vUIAgACqsQD//yUqIA== Date: Tue, 6 Nov 2012 19:26:40 +0000 Message-ID: References: <2A09E170-7C8E-4243-8069-297A9FFBFB18@checkpoint.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPsecme WG Subject: Re: [IPsec] Will it be a good idea if we join in meetecho? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 19:28:40 -0000 I mean next IETF, maybe we can put IPsec in meetecho? Cheers, Will -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Tuesday, November 06, 2012 9:21 AM To: Will Liu (Shucheng) Cc: IPsecme WG Subject: Re: [IPsec] Will it be a good idea if we join in meetecho? On Nov 5, 2012, at 11:09 PM, Yoav Nir wrote: > Too late now that our meeting's over. >=20 >=20 > On Nov 5, 2012, at 9:40 PM, Will Liu (Shucheng) wrote: >=20 >> Hi all, >> =20 >> I see that several WGs are in here. http://ietf85.conf.meetecho.com/=20 >> Do you think it would be a good idea that we also join this? I'm confused as well. What value would there be to join Meetecho after the = meeting? --Paul Hoffman From mcr@sandelman.ca Tue Nov 6 12:46:34 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640C721F8B0B for ; Tue, 6 Nov 2012 12:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPCoyA8p6FYj for ; Tue, 6 Nov 2012 12:46:33 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6256121F8AFA for ; Tue, 6 Nov 2012 12:46:31 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 7F66481A9 for ; Tue, 6 Nov 2012 15:38:19 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4964CCA0BC for ; Tue, 6 Nov 2012 15:46:27 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org In-reply-to: <20633.24231.244628.939482@fireball.kivinen.iki.fi> References: <20633.24231.244628.939482@fireball.kivinen.iki.fi> Comments: In-reply-to Tero Kivinen message dated "Tue, 06 Nov 2012 21:01:59 +0200." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 06 Nov 2012 15:46:27 -0500 Message-ID: <9913.1352234787@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] Which option to pick on draft-kivinen-ipsecme-oob-pubkey-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 20:46:35 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: TK> The another question is whether this document needs to be WG TK> document or not. As it seems to be that we are updating the TK> RFC5996 and obsoleting stuff from it, there seemed to be some TK> people who felt that this should be WG document. Send your TK> comments about this too. if it can fit into the charter, and/or our AD will let us, then yes. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQmXciAAoJEKD0KQ7Gj3P2HtAH/i+u2c3cr52hkLjxcPfIVlbM zWcWz37XvRciXXTTqalWMEV+Hl+ApFfkK+f8iZEPNRY5KmXg6+tS18m2R7VYcJls 0lFSUeGj0iATu+2N4fLKzJOR9FIVYZPW+TVTyHxU3QG3DO34FJr6Rft1kMGFUw89 fKnmXtvhuT4N1UAn+m0ot9XzfJdgSs4KNv/CSFuHnlYHE8ZJ9nC6TPTGbFKDnWyc bYnRs1VXhbv7ifLQ43FedXaCmKjAc37Aek8kEdzeLx6hgiSSU5a3Q5HQuXhmHN7N g5gsuS5IesprSYl0h2IxrI9HT7pUmAZfyGbEenKtXLU02m3SfSghQfrSPkXHmw4= =QrXC -----END PGP SIGNATURE----- --=-=-=-- From fgont@si6networks.com Tue Nov 6 14:55:15 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321A121F8B9D for ; Tue, 6 Nov 2012 14:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRdGXWrVDdPB for ; Tue, 6 Nov 2012 14:55:14 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7A59221F8B88 for ; Tue, 6 Nov 2012 14:55:14 -0800 (PST) Received: from [2001:df8:0:16:7c2c:3f3c:a1b6:8777] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TVs2R-0002AB-Ja; Tue, 06 Nov 2012 23:54:31 +0100 Message-ID: <50999526.7020405@si6networks.com> Date: Tue, 06 Nov 2012 17:54:30 -0500 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: ipsec@ietf.org X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [IPsec] Reminder: Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 22:55:15 -0000 Folks, This Friday (November 9th, 2012) I'll be presenting the I-D entitled "Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks" (draft-gont-opsec-vpn-leakages-00) at the opsec wg meeting. FWIW, I did a short presentation of this I-D ad the ipsecme g meeting yesterday (as a kind of "heads up")... but discussion is expected to happen at the opsec wg meeting. The agenda of the opsec wg is available here: Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From Johannes.Merkle@secunet.com Wed Nov 7 03:57:18 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEB021F8900 for ; Wed, 7 Nov 2012 03:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cpbfb362t7w8 for ; Wed, 7 Nov 2012 03:57:18 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id D4CB621F88D1 for ; Wed, 7 Nov 2012 03:57:17 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 29B631A0083; Wed, 7 Nov 2012 12:57:15 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 8A65E1A007B; Wed, 7 Nov 2012 12:57:06 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 12:57:05 +0100 Message-ID: <509A4C91.4030507@secunet.com> Date: Wed, 07 Nov 2012 12:57:05 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "David McGrew (mcgrew)" References: <747787E65E3FBD4E93F0EB2F14DB556B0F507509@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F507509@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2012 11:57:05.0907 (UTC) FILETIME=[01E42430:01CDBCDF] Cc: IPsecme WG , Manfred Lochter , "rfc-ise@rfc-editor.org" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 11:57:18 -0000 Hi David, > I strongly encourage you to remove the "Compressed" point format. Doing > so will minimize the changes between RFC 5903 and make the draft easier to > support, and improve the overall implementation by making it simpler. > Also, it is not clear that there is any advantage to the "compressed" > format. It saves at most 64 bytes in total for a complete IKEv2 key > establishment, and since IKEv2 exchanges typically send a lot more data > than that, it sounds like a false economy to add complexity in order to > avoid a little bit of data. I do not think that using point compression is complex. The rule, how to determine the representation of the KE payload (by bit length) is very simple and common crypto libraries like OpenSSL provide EC point expansion functions, so there is not much an implementation could do wrong. On the other hand, there may be environments where every byte savings counts. For instance, when using IPsec for communications between military radio equipment, bandwidth can be very limited. Another example could be implementation in embedded environments. For instance, I have talked with major car manufacturers who are really concerned about bandwidth limitations on their internal bus in the context of secure communication between control units. IKE is an option for such communications. Point compression is a quite common technique and supported by relevant ECC standards, i.e. ANSI X9.62/X9.63, IEEE P1363 and SEC, but also by many IETF standards like TLS, CMS, PKIX, SSH. IMHO, IKE should allow this option like TLS does. Actually for IKE, the bandwidth limitations may be more relevant than for TLS, where point compression is supported as well. > > The paragraph starting "The corresponding twisted curves ..." is a > distinct and self-contained topic. I suggest putting it into its own > section. > This is a good point, I will do this in the next revision. > > In some places, the draft gives [SEC1] as a normative reference, where > RFC6090 is also applicable (Sections 4.1 and 6 apply jn Section 2.2 of > draft-merkle-ikev2-ke-brainpool, for instance). > RFC 6090 does not define a FieldElement-to-OctetString conversion but only Integer-to-OctetString. In order to use a reference to RFC 6090, I would have to change the text to +++ ... by representing the field element as integer in the interval [0,p-1] and then using the Integer-to-OctetString conversion method specified in [RFC6090]... +++ This makes the whole sentence more difficult to comprehend. On the other hand, I do not see any advantage in pointing to RFC 6090 instead to SEC1. Johannes From mcgrew@cisco.com Wed Nov 7 06:48:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B1521F8BAD for ; Wed, 7 Nov 2012 06:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BIk6H61r2s6 for ; Wed, 7 Nov 2012 06:48:02 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7775421F8BA8 for ; Wed, 7 Nov 2012 06:48:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6508; q=dns/txt; s=iport; t=1352299682; x=1353509282; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=m5tkJnoaqj+rLnIg1EcZDYpz/YK2bfT95KJRpiJdOWg=; b=heSb9Ly3HsbAXyGH2kp2X1QMB7Y7zvH2PNzg8jZrgqDYkFPfAGuIlO4W czFqcbEIqQQe3xAwGhMXCPNAwjuO3hHTQxXxeCn464IcpAolbcV5Xq9pL AHIlRlcsgPL4zijRxdaZRt3kubOOqYPMCF30dXl+HoPs5jg/1VmPCrLH4 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALpzmlCtJXHA/2dsb2JhbABEw2qBCIIgAQQSASc/EgEIIhRCJQIEDgUIGodoC5t6oCyMIYVSYQOSSZILgWuCb4FbIB4 X-IronPort-AV: E=Sophos;i="4.80,730,1344211200"; d="scan'208";a="139795287" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 07 Nov 2012 14:48:01 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA7Em1Bc031273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 14:48:01 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 08:48:01 -0600 From: "David McGrew (mcgrew)" To: Johannes Merkle Thread-Topic: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Thread-Index: AQHNu1ps1FUub1JjY0W7Zvt4S+0awJfbrn+AgAL9ZID//9vsAA== Date: Wed, 7 Nov 2012 14:48:00 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F507F6B@xmb-rcd-x04.cisco.com> In-Reply-To: <509A4C91.4030507@secunet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--53.536300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <1079147A6AC9F245A04835DF915A41F0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Manfred Lochter , "rfc-ise@rfc-editor.org" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:48:04 -0000 Hi Johannes, On 11/7/12 6:57 AM, "Johannes Merkle" wrote: >Hi David, > >> I strongly encourage you to remove the "Compressed" point format. Doing >> so will minimize the changes between RFC 5903 and make the draft easier >>to >> support, and improve the overall implementation by making it simpler. >> Also, it is not clear that there is any advantage to the "compressed" >> format. It saves at most 64 bytes in total for a complete IKEv2 key >> establishment, and since IKEv2 exchanges typically send a lot more data >> than that, it sounds like a false economy to add complexity in order to >> avoid a little bit of data. > >I do not think that using point compression is complex. Sure, it is not a giant amount of complexity, but is any complexity warranted here? If the compressed format is omitted, then the formats for all five of the EC groups registered in Diffie-Hellman Group Transform IDs, and that of the brainpool curves, would be identical, so that an implementation of the brainpool curves could be handled as "same software operating on different group parameters". That is much preferable to having different group logic for different DH Group IDs. >The rule, how to determine the representation of the KE payload >(by bit length) is very simple and common crypto libraries like OpenSSL >provide EC point expansion functions, so there >is not much an implementation could do wrong. Well, there are some steps that could be done wrong: a receiver-side implementation could fail to check and handle lengths correctly, it could fail to compute the y-coordinate from the x-coordinate correctly, either of which could result in an exploitable vulnerability. This might seem like a minor point, but it is clear that crypto protocols should avoid complexity, especially in how they parse data (this brings to mind an interesting recent presentation on this is ). > >On the other hand, there may be environments where every byte savings >counts. For instance, when using IPsec for >communications between military radio equipment, bandwidth can be very >limited. Another example could be implementation >in embedded environments. For instance, I have talked with major car >manufacturers who are really concerned about >bandwidth limitations on their internal bus in the context of secure >communication between control units. IKE is an >option for such communications. I don't think the byte savings of any protocol option can be justified by considering only the number of bytes that it would eliminate from the communications. What matters is the relative savings, that is, the total number of bytes in the communications with and without that option. How many bytes will IKEv2 take, in an embedded context, say, with and without the compressed format? It should be possible to estimate a minimum based on draft-kivinen-ipsecme-ikev2-minimal-01. Looking at the table of payloads in Section 2, it appears that the total bytes exchanged is going to be considerably larger than that saved by the compressed format. > >Point compression is a quite common technique and supported by relevant >ECC standards, i.e. ANSI X9.62/X9.63, IEEE P1363 >and SEC, but also by many IETF standards like TLS, CMS, PKIX, SSH. IMHO, >IKE should allow this option like TLS does. A minor point: the use of ECC in TLS is not part of the standard, but is an informational extension. More importantly, the TLS ECC RFC allows the negotiation of supported point formats; only uncompressed format is a MUST-implement (see Section 5.1.2 of RFC4492). In contrast, draft-merkle-ikev2-ke-brainpool-00 requires all implementations to support compressed format. There is a clear preference in IETF to avoid having a compressed format as a MUST-implement, so I am concerned that keeping it in the draft will be an inhibitor. One way that you could change the draft to make the compressed format optional is to define a different DH Group ID for each of the existing groups and each of the formats, which would double the number of groups. This might be acceptable to the WG if the number of groups could be kept small. =20 >Actually for IKE, the bandwidth limitations may be more relevant than for >TLS, where point compression is supported as well. > >>=20 >> The paragraph starting "The corresponding twisted curves ..." is a >> distinct and self-contained topic. I suggest putting it into its own >> section. =20 >>=20 >This is a good point, I will do this in the next revision. > >>=20 >> In some places, the draft gives [SEC1] as a normative reference, where >> RFC6090 is also applicable (Sections 4.1 and 6 apply jn Section 2.2 of >> draft-merkle-ikev2-ke-brainpool, for instance). >>=20 > >RFC 6090 does not define a FieldElement-to-OctetString conversion but >only Integer-to-OctetString. In order to use a >reference to RFC 6090, I would have to change the text to >+++ >... by representing the field element as integer in the interval [0,p-1] >and then using the Integer-to-OctetString >conversion method specified in [RFC6090]... >+++ >This makes the whole sentence more difficult to comprehend. On the other >hand, I do not see any advantage in pointing to >RFC 6090 instead to SEC1. I didn't mean to suggest eliminating the reference to SEC1, sorry if I was unclear on that. What I was meant to suggest is text like "The compressed format is equivalent to the compact representation of Section 4.2 of RFC6090, using the conversion between integers and octet strings of Section 6 of the same reference." Let me take a step back here and explain some of my motivations. Here is the big picture as I see it: it is good for IKE to embrace ECC, and it is reasonable thing to have some diversity of ECC parameters, to provide a fallback in case of unanticipated future results in cryptanalysis. So I would like to see the brainpool IKE groups be something that IPsec implementers are comfortable with implementing (and I'm making suggestions that I hope will move the draft in that direction). Additionally, if in the future we do end up having additional ECC parameters that get contributed to IKE, it would be a good thing for the WG to have established a precedent favoring a consistency across ECP groups. Thanks and regards, David > >Johannes > From Johannes.Merkle@secunet.com Wed Nov 7 10:22:00 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926FD21F8C99 for ; Wed, 7 Nov 2012 10:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQtKJg4CqKxT for ; Wed, 7 Nov 2012 10:21:59 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8656621F8C95 for ; Wed, 7 Nov 2012 10:21:57 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 136491A0080; Wed, 7 Nov 2012 19:21:55 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 65D481A006C; Wed, 7 Nov 2012 19:21:46 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 19:21:45 +0100 Message-ID: <509AA6B9.9040309@secunet.com> Date: Wed, 07 Nov 2012 19:21:45 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "David McGrew (mcgrew)" References: <747787E65E3FBD4E93F0EB2F14DB556B0F507F6B@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F507F6B@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2012 18:21:46.0015 (UTC) FILETIME=[BEB522F0:01CDBD14] Cc: IPsecme WG , Manfred Lochter , "rfc-ise@rfc-editor.org" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:22:00 -0000 Hi David, >> I do not think that using point compression is complex. > > Sure, it is not a giant amount of complexity, but is any complexity > warranted here? If the compressed format is omitted, then the formats > for all five of the EC groups registered in Diffie-Hellman Group Transform > IDs, and that of the brainpool curves, would be identical, so that an > implementation of the brainpool curves could be handled as "same software > operating on different group parameters". That is much preferable to > having different group logic for different DH Group IDs. I see your point, but I am not sure, if it is good to maintain a limitation of the previous RFCs for the new curves as well. At least not, if we agree that point compression is a reasonable feature (which is still discussed below). > Well, there are some steps that could be done wrong: a receiver-side > implementation could fail to check and handle lengths correctly, it could > fail to compute the y-coordinate from the x-coordinate correctly, either > of which could result in an exploitable vulnerability. This might seem Point compression is simply the ommission of the x-value, and for point expansion, functions are included in OpenSSL and other crypto libraries. Thus, such mistakes should only occur if someone decides to implement the arithmetic by itself but is incapable of doing it correctly (and does not perform sufficient testing). This seems to me a quite a case of carelessness and I don't think, that an RFC should be so fool-proof to prevent that. There are certainly much more complex aspects in IKE than point compression. > > I don't think the byte savings of any protocol option can be justified by > considering only the number of bytes that it would eliminate from the > communications. What matters is the relative savings, that is, the total > number of bytes in the communications with and without that option. How > many bytes will IKEv2 take, in an embedded context, say, with and without > the compressed format? It should be possible to estimate a minimum based > on draft-kivinen-ipsecme-ikev2-minimal-01. Looking at the table of > payloads in Section 2, it appears that the total bytes exchanged is going > to be considerably larger than that saved by the compressed format. > If using certificate-based authentication, probably the largest payload is the CERT. It contains a public key and a signature, which, when using the same curve as for KE, are (together) 3-4 times larger than a compressed KE payload. In addition, some smaller data fields as the DNs, algorithm identifiers, validity, serial, and some ASN.1 overhead. But according to RFC 5480 one can use point compression for the public key contained in the certificate as well, which means that the implementation must be able to handle this anyway. I agree with you that the saving is small, but from what I have heard about constrained environment, even a saving below 10% can be desirable. >> >> Point compression is a quite common technique and supported by relevant >> ECC standards, i.e. ANSI X9.62/X9.63, IEEE P1363 >> and SEC, but also by many IETF standards like TLS, CMS, PKIX, SSH. IMHO, >> IKE should allow this option like TLS does. > > A minor point: the use of ECC in TLS is not part of the standard, but is > an informational extension. This is also true for ECC in IKEv2. Furthermore, the TLS RFCs are WG document, as the IANA registry for elliptic curves requires IETF consensus. (I know that by heart, as I am currently also working on the standardization of the Brainpool curves for TLS.) > More importantly, the TLS ECC RFC allows the > negotiation of supported point formats; only uncompressed format is a > MUST-implement (see Section 5.1.2 of RFC4492). That is a good point, but unfortunately in IKE, KE methods are not negotiated at all. This is not only an special issue for ECC or point compression. If the other peer does not understand the curve you are using or ECC at all, that you end up in INVALID_KE_PAYLOAD notification and have to re-try. Yes, introducing point compression doubles the number of new possibilities to choose from: 8 instead of 4 in the case of the 4 groups defined in the draft. But this number is still moderate. > In contrast, > draft-merkle-ikev2-ke-brainpool-00 requires all implementations to support > compressed format. There is a clear preference in IETF to avoid having a > compressed format as a MUST-implement, so I am concerned that keeping it > in the draft will be an inhibitor. > An interesting idea. However, I am not sure if making one encoding optional would not increase interoperability problems due to the lack of negotiation for KE group or point representation. But I would make point compression optional, if you and the other folks on the list think that is enhances interoperability. > One way that you could change the draft to make the compressed format > optional is to define a different DH Group ID for each of the existing > groups and each of the formats, which would double the number of groups. > This might be acceptable to the WG if the number of groups could be kept > small. First, the number is already small compared to the name space. As to the definition of separate transform IDs, I don't understand, why only this should allow point compression to be optional. The transform Id serves for identifying the group. The encoding (compressed or uncompressed) can be determined from the length of the KE payload and the group. > > I didn't mean to suggest eliminating the reference to SEC1, sorry if I was > unclear on that. What I was meant to suggest is text like "The > compressed format is equivalent to the compact representation of Section > 4.2 of RFC6090, using the conversion between integers and octet strings of > Section 6 of the same reference." > I can do this, but adding this text does not make RFC 6090 a normative reference, right? Or do you mean to replace the explicit description how to encode in compressed format with this reference? > Let me take a step back here and explain some of my motivations. Here is > the big picture as I see it: it is good for IKE to embrace ECC, and it is > reasonable thing to have some diversity of ECC parameters, to provide a > fallback in case of unanticipated future results in cryptanalysis. So I > would like to see the brainpool IKE groups be something that IPsec > implementers are comfortable with implementing (and I'm making suggestions > that I hope will move the draft in that direction). Additionally, if in > the future we do end up having additional ECC parameters that get > contributed to IKE, it would be a good thing for the WG to have > established a precedent favoring a consistency across ECP groups. > I understand and please be ensured that I take your critics as constructive and fruitful. regards, Johannes From kivinen@iki.fi Wed Nov 7 11:13:15 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDF821F8BE1 for ; Wed, 7 Nov 2012 11:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPvasEcuLUYg for ; Wed, 7 Nov 2012 11:13:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 300F121F8A0C for ; Wed, 7 Nov 2012 11:13:13 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA7JCmoK000414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Nov 2012 21:12:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA7JCmZA012948; Wed, 7 Nov 2012 21:12:48 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20634.45743.909055.939291@fireball.kivinen.iki.fi> Date: Wed, 7 Nov 2012 21:12:47 +0200 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <509AA6B9.9040309@secunet.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F507F6B@xmb-rcd-x04.cisco.com> <509AA6B9.9040309@secunet.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 10 min Cc: IPsecme WG , Manfred Lochter , "David McGrew \(mcgrew\)" , "rfc-ise@rfc-editor.org" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 19:13:15 -0000 Johannes Merkle writes: > I see your point, but I am not sure, if it is good to maintain a > limitation of the previous RFCs for the new curves as > well. At least not, if we agree that point compression is a > reasonable feature (which is still discussed below). Every single option adds complexity, so I do not think we should add more optional things. > If using certificate-based authentication, probably the largest > payload is the CERT. It contains a public key and a signature, > which, when using the same curve as for KE, are (together) 3-4 times > larger than a compressed KE payload. In addition, some smaller data > fields as the DNs, algorithm identifiers, validity, serial, and some > ASN.1 overhead. But according to RFC 5480 one can use point > compression for the public key contained in the certificate as well, > which means that the implementation must be able to handle this > anyway. You can replace X.509 cert in CERT payload with hash and url, which will make the payload to be around 60 bytes or so depending on the length of the url used (5 bytes for header + 20 bytes for hash, and 29 bytes for url in format of "http://123.123.123.123:1234/"). Bit more if the URL has IPv6 address. > I agree with you that the saving is small, but from what I have > heard about constrained environment, even a saving below 10% can be > desirable. Not sending the CERT, but replacing it with hash and url offers much bigger savings, and people are not even doing that. > > More importantly, the TLS ECC RFC allows the > > negotiation of supported point formats; only uncompressed format is a > > MUST-implement (see Section 5.1.2 of RFC4492). > > That is a good point, but unfortunately in IKE, KE methods are not > negotiated at all. This is not only an special issue for ECC or > point compression. If the other peer does not understand the curve > you are using or ECC at all, that you end up in INVALID_KE_PAYLOAD > notification and have to re-try. Note, that negotiating the use of point compression without retry or not would waste more bytes then the point compression saves... The KE payload is in the first packet, which means that to be able to negotiate it beforehand would require one extra roundtrip. The IKEv2 headers + notify payloads etc would be 2 * (28 + 8 bytes) = 72 bytes which is already quite big EC key Y part... > Yes, introducing point compression doubles the number of new > possibilities to choose from: 8 instead of 4 in the case of the 4 > groups defined in the draft. But this number is still moderate. I would prefer not to do that. > As to the definition of separate transform IDs, I don't understand, > why only this should allow point compression to be optional. The > transform Id serves for identifying the group. The encoding > (compressed or uncompressed) can be determined from the length of > the KE payload and the group. If I remember right the reason IKEv2 does not use point compression for the current groups was that there was some IPR. Is that issue already been cleared? -- kivinen@iki.fi From svanru@gmail.com Wed Nov 7 22:18:41 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E3E21F8740 for ; Wed, 7 Nov 2012 22:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tAH422ruGZc for ; Wed, 7 Nov 2012 22:18:40 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01A0B21F8738 for ; Wed, 7 Nov 2012 22:18:39 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id k13so2056105lbo.31 for ; Wed, 07 Nov 2012 22:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=By1wzEwpSsebpiERhgon3nrw0LSwOw9OYKNL0axqi7A=; b=EcDH6YYRsZEWIoL2ceDS0jTol24xoCH8hjF35BJd34nA6r8TM3rg+g3VV4xumJuPDL 16MhkHEaQK73FQD6Jt+9DQUuo0Q9TZatYwDQq0s+F2iEey0yULSZfXKESb7fSAhRkfCu i85L6lsl1bAt1HOqAgMr8J5Tn2JPMGOrfLej6nd2zuRC9DlAG6JbEMFq4kAaDk4mP268 qNfZ3eS3zHgDCswmWcNxbYb/fVU58EfJETIELL1bgD3r/ooQu6q1Fb5K5xt3SPXGnOKN k88ueQlGbbyhO0r+spxLzV8pGsBEBH2HS9ePyTLTJ7/C2tlm2ij5qruE5Fky99ab+1w4 z6KA== Received: by 10.112.43.71 with SMTP id u7mr2720593lbl.52.1352355518972; Wed, 07 Nov 2012 22:18:38 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id e4sm8784279lby.12.2012.11.07.22.18.36 (version=SSLv3 cipher=OTHER); Wed, 07 Nov 2012 22:18:37 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Dan Harkins" References: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> Date: Thu, 8 Nov 2012 10:18:48 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: ipsec@ietf.org Subject: Re: [IPsec] New I-D on IKEv3 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 06:18:42 -0000 Hi Dan, I suspect the IKEv3 in its current form is susceptible to very simple DoS attack. Suppose we have Alice, Bob and Malory. Alice wants to communicate with Bob, Malory wants to not allow her to do it. For this Malory sends INIT packet to Bob pretending to be Alice (this packet may have fake or real Alice's source IP). Bob's state machine transfers to Reception state and Bob replies back to what he thinks is Alice. This reply packet either goes to nowhere (if IP is fake) or get dropped by Alice according to 6.1.1.2 first bullet. Now Malory has achived his goal - untill TM event happens and Bob's state machine returns back to Nothing state, Bob will discard any INIT packet from real Alice according to 6.1.1.2 second bullet. What Malory needs to do - infrequently send such INIT packets and Alice will have almost no chance to communicate with Bob. I think the root of this susceptibility is in the draft's intention to have only one instance of IKEv3 protocol running between two peers, even before peer is authenticated or, at least, confirmed her ability to participate in IKEv3 (for example by COOKIE exchange). Another thing (among others that have been already mentioned by other people) that I think decreases protocol usability - the lack of error notifications. If something goes wrong (due to misconfiguration, etc.) peers never report the problem to each other, so protocol will try to retransmit for quite a long time before some recovery actions could be done (for example switch to another peer). Regards, Valery Smyslov. From Johannes.Merkle@secunet.com Thu Nov 8 00:27:00 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4758521F86C1 for ; Thu, 8 Nov 2012 00:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzsHHjh39Z+N for ; Thu, 8 Nov 2012 00:26:59 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4733121F84DC for ; Thu, 8 Nov 2012 00:26:58 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id EC83D1A007E; Thu, 8 Nov 2012 09:26:56 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 185051A0066; Thu, 8 Nov 2012 09:26:52 +0100 (CET) Received: from [172.16.48.110] ([172.16.48.110]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Nov 2012 09:26:51 +0100 Message-ID: <509B6CC5.90407@secunet.com> Date: Thu, 08 Nov 2012 09:26:45 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tero Kivinen References: <747787E65E3FBD4E93F0EB2F14DB556B0F507F6B@xmb-rcd-x04.cisco.com> <509AA6B9.9040309@secunet.com> <20634.45743.909055.939291@fireball.kivinen.iki.fi> In-Reply-To: <20634.45743.909055.939291@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2012 08:26:51.0941 (UTC) FILETIME=[CDCB6D50:01CDBD8A] Cc: IPsecme WG , Manfred Lochter , "David McGrew \(mcgrew\)" , "rfc-ise@rfc-editor.org" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 08:27:00 -0000 Hi Tero, > Every single option adds complexity, so I do not think we should add > more optional things. Point compression is not the focus of our draft. Given the opposition it is facing here, I suggest to wait for further replies and if point compression turns out to be objected by the majority on this list, I will not insist on this feature. BTW: In an earlier thread Dan Haskins has already indicated his preference to leave point compression out. > > Not sending the CERT, but replacing it with hash and url offers much > bigger savings, and people are not even doing that. You can not be sure that this option isn't used is some constrained environments. Just a note: the relative saving of point compression is larger when sending hash + URL instead of the CERT. > > Note, that negotiating the use of point compression without retry or > not would waste more bytes then the point compression saves... The KE > payload is in the first packet, which means that to be able to > negotiate it beforehand would require one extra roundtrip. The IKEv2 > headers + notify payloads etc would be 2 * (28 + 8 bytes) = 72 bytes > which is already quite big EC key Y part... What I had in mind are constraint environments where using bandwidth saving techniques like point compression can be assumed to be the default. > If I remember right the reason IKEv2 does not use point compression > for the current groups was that there was some IPR. Is that issue > already been cleared? The the patent expires in 2014. http://cr.yp.to/patents/us/6141420.html -- Johannes From derek@ihtfp.com Wed Nov 7 10:27:36 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F2721F8B75 for ; Wed, 7 Nov 2012 10:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH4OTgBymMFe for ; Wed, 7 Nov 2012 10:27:35 -0800 (PST) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8F721F8B74 for ; Wed, 7 Nov 2012 10:27:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 7C322260298; Wed, 7 Nov 2012 13:27:33 -0500 (EST) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 22856-04; Wed, 7 Nov 2012 13:27:32 -0500 (EST) Received: by mail2.ihtfp.org (Postfix, from userid 48) id 3BC4326023C; Wed, 7 Nov 2012 13:27:32 -0500 (EST) Received: from 2001:df8:0:80:224:d7ff:fee7:8924 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Wed, 7 Nov 2012 13:27:32 -0500 Message-ID: In-Reply-To: <509AA6B9.9040309@secunet.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F507F6B@xmb-rcd-x04.cisco.com> <509AA6B9.9040309@secunet.com> Date: Wed, 7 Nov 2012 13:27:32 -0500 From: "Derek Atkins" To: "Johannes Merkle" User-Agent: SquirrelMail/1.4.22-2.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.2a X-Mailman-Approved-At: Thu, 08 Nov 2012 08:01:46 -0800 Cc: IPsecme WG , Manfred Lochter , "David McGrew \(mcgrew\)" , "rfc-ise@rfc-editor.org" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:27:36 -0000 Hi, On Wed, November 7, 2012 1:21 pm, Johannes Merkle wrote: > Hi David, > > Point compression is simply the ommission of the x-value, and for point > expansion, functions are included in OpenSSL and > other crypto libraries. Thus, such mistakes should only occur if someone > decides to implement the arithmetic by itself > but is incapable of doing it correctly (and does not perform sufficient > testing). This seems to me a quite a case of > carelessness and I don't think, that an RFC should be so fool-proof to > prevent that. There are certainly much more > complex aspects in IKE than point compression. You're making the assumption that an implementor is using OpenSSL or has already implemented point compression. IMHO that is not a reasonable assumption. Many implementations use their own crypto libraries and therefore would have to implement these compression and expansion functions, including all the potential errors thereto. So saying "it's easy, it's in OpenSSL" is not, IMHO, a reassuring statement or argument. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From dharkins@lounge.org Thu Nov 8 10:57:36 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB0E921F85BB for ; Thu, 8 Nov 2012 10:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ahs-lO-ofdkD for ; Thu, 8 Nov 2012 10:57:36 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 819CF21F85B1 for ; Thu, 8 Nov 2012 10:57:36 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C6B301022400A; Thu, 8 Nov 2012 10:57:35 -0800 (PST) Received: from 130.129.17.156 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 8 Nov 2012 10:57:36 -0800 (PST) Message-ID: In-Reply-To: References: <747787E65E3FBD4E93F0EB2F14DB556B0F507F6B@xmb-rcd-x04.cisco.com> <509AA6B9.9040309@secunet.com> Date: Thu, 8 Nov 2012 10:57:36 -0800 (PST) From: "Dan Harkins" To: "Derek Atkins" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Johannes Merkle , "David McGrew " , "@trepanning.net, Manfred Lochter , IPsecme WG , " "@trepanning.net, rfc-ise@rfc-editor.org Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 18:57:37 -0000 Hi Derek, On Wed, November 7, 2012 10:27 am, Derek Atkins wrote: > Hi, > > On Wed, November 7, 2012 1:21 pm, Johannes Merkle wrote: >> Hi David, >> >> Point compression is simply the ommission of the x-value, and for point >> expansion, functions are included in OpenSSL and >> other crypto libraries. Thus, such mistakes should only occur if someone >> decides to implement the arithmetic by itself >> but is incapable of doing it correctly (and does not perform sufficient >> testing). This seems to me a quite a case of >> carelessness and I don't think, that an RFC should be so fool-proof to >> prevent that. There are certainly much more >> complex aspects in IKE than point compression. > > You're making the assumption that an implementor is using OpenSSL or has > already implemented point compression. IMHO that is not a reasonable > assumption. Many implementations use their own crypto libraries and > therefore would have to implement these compression and expansion > functions, including all the potential errors thereto. So saying "it's > easy, it's in OpenSSL" is not, IMHO, a reassuring statement or argument. Decompression is just a square root and a discriminator to say whether the result is y or -y. All the brainpool curves are of the form p mod 4 = 3, where p is the prime defining the curve. For such curves the square root of n would be n^((p+1)/4) mod p. This is straightforward to implement with any big number library. regards, Dan. From dharkins@lounge.org Thu Nov 8 11:48:16 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F4221F8808 for ; Thu, 8 Nov 2012 11:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhMVZIciYlhg for ; Thu, 8 Nov 2012 11:48:16 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAE221F88B4 for ; Thu, 8 Nov 2012 11:48:16 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6771510224052; Thu, 8 Nov 2012 11:48:07 -0800 (PST) Received: from 130.129.17.156 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 8 Nov 2012 11:48:07 -0800 (PST) Message-ID: <453f42808bfd8886e24f71c7f9c38c04.squirrel@www.trepanning.net> In-Reply-To: References: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> Date: Thu, 8 Nov 2012 11:48:07 -0800 (PST) From: "Dan Harkins" To: "Valery Smyslov" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, Dan Harkins Subject: Re: [IPsec] New I-D on IKEv3 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:48:17 -0000 Hi Valery, On Wed, November 7, 2012 10:18 pm, Valery Smyslov wrote: > Hi Dan, > > I suspect the IKEv3 in its current form is susceptible to very simple DoS > attack. > Suppose we have Alice, Bob and Malory. Alice wants to communicate with > Bob, > Malory wants to not allow her to do it. For this Malory sends INIT packet > to > Bob > pretending to be Alice (this packet may have fake or real Alice's source > IP). > Bob's state machine transfers to Reception state and Bob replies back > to what he thinks is Alice. This reply packet either goes to nowhere > (if IP is fake) or get dropped by Alice according to 6.1.1.2 first bullet. > Now Malory has achived his goal - untill TM event happens and > Bob's state machine returns back to Nothing state, Bob will > discard any INIT packet from real Alice according to 6.1.1.2 second > bullet. > What Malory needs to do - infrequently send such INIT packets and > Alice will have almost no chance to communicate with Bob. That is a very good point. It makes me want to do away with the SPI since it really serves no purpose in IKEv3. > I think the root of this susceptibility is in the draft's intention to > have > only one > instance of IKEv3 protocol running between two peers, even before > peer is authenticated or, at least, confirmed her ability to > participate in IKEv3 (for example by COOKIE exchange). Once the peer is authenticated the SA goes away so there is really only 1 nascent SA between 2 peers, once it's done it's job it goes away. > Another thing (among others that have been already mentioned by other > people) > that I think decreases protocol usability - the lack of error > notifications. > If something goes wrong (due to misconfiguration, etc.) peers never > report the problem to each other, so protocol will try to retransmit for > quite > a long time before some recovery actions could be done > (for example switch to another peer). What errors would you like to receive? If you don't like my attribute assertion do you want to tell me why? I'm sure that can be handled by sending an error message and going away. What if you fail to authenticate me? Do you feel compelled to tell me that I failed? What else would you like to see? Thanks for looking at IKEv3 and I hope you will take a look at the -01 version. regards, Dan. From mcgrew@cisco.com Thu Nov 8 13:24:35 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB8E21F8685 for ; Thu, 8 Nov 2012 13:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZVcT3bfX1iH for ; Thu, 8 Nov 2012 13:24:34 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 814EF21F84DF for ; Thu, 8 Nov 2012 13:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2029; q=dns/txt; s=iport; t=1352409874; x=1353619474; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YmLKNutcAwmbotQQjVH3CvWZ4zGzSanUAHCP6TjUd0g=; b=hoyTd5CIwLkotAkGPUPrRcVtsWdXcI1blqGX4lPhSKxqUnP5QAIrfXAi ZDYLE7/55HihoRYlwfOTkrlbtFvN8sSSjJxdF05RaEzRJkaCGt+ZHjFXi Sj2T4/mCH5NOnJs+Imwesf2CP0xqmpLqhKh3TUi54dG5JPhd1t9sexpDv g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKcinFCtJV2a/2dsb2JhbABEw0GBCIIgAQQSASc/EgEIIhRCJQIEAQ0FCBqHaAucCaApkXhhA6RTgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,740,1344211200"; d="scan'208";a="140344092" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 08 Nov 2012 21:24:34 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA8LOXYi024358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Nov 2012 21:24:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 15:24:33 -0600 From: "David McGrew (mcgrew)" To: Johannes Merkle , Tero Kivinen Thread-Topic: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Thread-Index: AQHNvYrXR2AIfdFogUKJcY2TkLUT3ZfghIcA Date: Thu, 8 Nov 2012 21:24:32 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F509D58@xmb-rcd-x04.cisco.com> In-Reply-To: <509B6CC5.90407@secunet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--32.676100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Manfred Lochter , "rfc-ise@rfc-editor.org" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:24:35 -0000 On 11/8/12 3:26 AM, "Johannes Merkle" wrote: >Hi Tero, > >> Every single option adds complexity, so I do not think we should add >> more optional things. > >Point compression is not the focus of our draft. Given the opposition it >is facing here, I suggest to wait for further >replies and if point compression turns out to be objected by the majority >on this list, I will not insist on this feature. >BTW: In an earlier thread Dan Haskins has already indicated his >preference to leave point compression out. > >>=20 >> Not sending the CERT, but replacing it with hash and url offers much >> bigger savings, and people are not even doing that. >You can not be sure that this option isn't used is some constrained >environments. > >Just a note: the relative saving of point compression is larger when >sending hash + URL instead of the CERT. What's the scenario here? If hash + URL is sent, the certificate still has to be retrieved. It might not be part of the IKE exchange, but moving it to HTTP doesn't mean that it doesn't contribute to bytes on the wire (or over the air, in the case of wireless). David > >>=20 >> Note, that negotiating the use of point compression without retry or >> not would waste more bytes then the point compression saves... The KE >> payload is in the first packet, which means that to be able to >> negotiate it beforehand would require one extra roundtrip. The IKEv2 >> headers + notify payloads etc would be 2 * (28 + 8 bytes) =3D 72 bytes >> which is already quite big EC key Y part... > >What I had in mind are constraint environments where using bandwidth >saving techniques like point compression can be >assumed to be the default. > > >> If I remember right the reason IKEv2 does not use point compression >> for the current groups was that there was some IPR. Is that issue >> already been cleared? > >The the patent expires in 2014. >http://cr.yp.to/patents/us/6141420.html > >--=20 >Johannes From ynir@checkpoint.com Thu Nov 8 13:44:34 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FD621F855E for ; Thu, 8 Nov 2012 13:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojmPm+UT+xSf for ; Thu, 8 Nov 2012 13:44:34 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1777921F85E3 for ; Thu, 8 Nov 2012 13:44:32 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qA8LiPaA027122; Thu, 8 Nov 2012 23:44:25 +0200 X-CheckPoint: {509C24F3-4-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 8 Nov 2012 23:44:25 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 8 Nov 2012 23:44:25 +0200 From: Yoav Nir To: "David McGrew (mcgrew)" Date: Thu, 8 Nov 2012 23:44:23 +0200 Thread-Topic: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Thread-Index: Ac29+jhQAvMTELTvTxy8NgA++UttVQ== Message-ID: <3E61AE58-F8E5-4213-8C36-189238CD8E9C@checkpoint.com> References: <747787E65E3FBD4E93F0EB2F14DB556B0F509D58@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F509D58@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IPsecme WG , Manfred Lochter , Johannes Merkle , "rfc-ise@rfc-editor.org" , Tero Kivinen Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:44:34 -0000 On Nov 8, 2012, at 4:24 PM, David McGrew (mcgrew) wrote: >=20 >=20 > On 11/8/12 3:26 AM, "Johannes Merkle" wrote= : >=20 >> Hi Tero, >>=20 >>> Every single option adds complexity, so I do not think we should add >>> more optional things. >>=20 >> Point compression is not the focus of our draft. Given the opposition it >> is facing here, I suggest to wait for further >> replies and if point compression turns out to be objected by the majorit= y >> on this list, I will not insist on this feature. >> BTW: In an earlier thread Dan Haskins has already indicated his >> preference to leave point compression out. >>=20 >>>=20 >>> Not sending the CERT, but replacing it with hash and url offers much >>> bigger savings, and people are not even doing that. >> You can not be sure that this option isn't used is some constrained >> environments. >>=20 >> Just a note: the relative saving of point compression is larger when >> sending hash + URL instead of the CERT. >=20 > What's the scenario here? If hash + URL is sent, the certificate still > has to be retrieved. It might not be part of the IKE exchange, but movin= g > it to HTTP doesn't mean that it doesn't contribute to bytes on the wire > (or over the air, in the case of wireless). >=20 Since we tend to meet the same people all the time (or communicate with the= same parties), usually the hash+URL would lead to retrieving the certifica= te from a cache, rather than from a remote web server. Of course, if my implementation is running on a "thing", it doesn't have a = cache and this argument doesn't apply. Yoav From kivinen@iki.fi Thu Nov 8 13:53:18 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCB021F89E5 for ; Thu, 8 Nov 2012 13:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+yNZEpXyiM9 for ; Thu, 8 Nov 2012 13:53:18 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id D054F21F89A1 for ; Thu, 8 Nov 2012 13:53:17 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qA8Lr7a6027125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 23:53:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qA8Lr69U001244; Thu, 8 Nov 2012 23:53:06 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20636.10690.164885.596670@fireball.kivinen.iki.fi> Date: Thu, 8 Nov 2012 23:53:06 +0200 From: Tero Kivinen To: "David McGrew (mcgrew)" In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F509D58@xmb-rcd-x04.cisco.com> References: <509B6CC5.90407@secunet.com> <747787E65E3FBD4E93F0EB2F14DB556B0F509D58@xmb-rcd-x04.cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: IPsecme WG , Manfred Lochter , Johannes Merkle , "rfc-ise@rfc-editor.org" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 21:53:18 -0000 David McGrew (mcgrew) writes: > >Just a note: the relative saving of point compression is larger when > >sending hash + URL instead of the CERT. > > What's the scenario here? If hash + URL is sent, the certificate still > has to be retrieved. Usually not, as it is already cached in the client. I.e. it only needs to fetched first time unknown hash is seen. After fetching it first time, and validating the cert the recipient of the hash + URL does not need to fetch it again when the same peer connects later. In most cases the devices talking to each other using IPsec is quite small set of devices, so caching their certificates does not take too much resources (especially if you just store the public key, hash and end of validity time (i.e. when you need to do something next time, either fetch CRL, or revalidate the cert because it expired etc). > It might not be part of the IKE exchange, but moving it to HTTP > doesn't mean that it doesn't contribute to bytes on the wire (or > over the air, in the case of wireless). The another reason for this feature in IKEv2 is to make the IKE_AUTH packet smaller, so it does not need to be fragmented. IKE_AUTH packet is UDP and there are some problems in some environments if it gets too big and starts to get fragmented. This option moves big parts of the IKE_AUTH packet away from UDP packet to separete TCP session. -- kivinen@iki.fi From paul.hoffman@vpnc.org Mon Nov 12 18:39:52 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBB121F883B for ; Mon, 12 Nov 2012 18:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ac2QRvkbdYV for ; Mon, 12 Nov 2012 18:39:51 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7144B21F8830 for ; Mon, 12 Nov 2012 18:39:51 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAD2dnZJ046127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 12 Nov 2012 19:39:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 12 Nov 2012 18:39:49 -0800 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPsec] Minutes from Atlanta meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 02:39:52 -0000 Carl Wallace did a fine job of taking minutes. I cleaned them up just a = tad; they are at = . Please send corrections *only* for things that are wrong in the minutes. = If you want to discuss a topic from the minutes, please start a new = thread. Thanks in advance! --Paul Hoffman= From lberger@labn.net Thu Nov 15 14:44:38 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF97821F8527 for ; Thu, 15 Nov 2012 14:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.347 X-Spam-Level: X-Spam-Status: No, score=-100.347 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, J_CHICKENPOX_14=0.6, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGfgI7nh36U6 for ; Thu, 15 Nov 2012 14:44:38 -0800 (PST) Received: from oproxy12-pub.bluehost.com (50-87-16-10.unifiedlayer.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 2B9CA21F8467 for ; Thu, 15 Nov 2012 14:44:38 -0800 (PST) Received: (qmail 6776 invoked by uid 0); 15 Nov 2012 22:44:16 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 15 Nov 2012 22:44:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=NUD/8ZS+nfUKgau2AYdv3hUTHftIYNAOiabS1NE9xm4=; b=f9VVkpqPVBr2tZFuF2F6WLJau6uWoTEcIidF/TtshTwmjoYLiRJCN+x9Mq2RQdthCkbcFtXkbon/l4vdWwxSJH4nrHGZfNFDcwP9U0RhMpzJ4ESxrLGmeqz3X2hq09kd; Received: from box313.bluehost.com ([69.89.31.113]:37617 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TZ8AS-0001kh-6w; Thu, 15 Nov 2012 15:44:16 -0700 Message-ID: <50A5703F.4070305@labn.net> Date: Thu, 15 Nov 2012 17:44:15 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: draft-ietf-ipsecme-ad-vpn-problem@tools.ietf.org X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ipsec@ietf.org Subject: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:44:38 -0000 Authors, As I mentioned in last week's meeting, I have some comments on this document from the routing perspective. I don't think these are major, but I still think they should be addressed. In section 1.1, you define the term gateway. I'm assuming that you are using the term in the normal IPsec context, and that it includes IPsec enabled routers. Is this correct? If not, the text should make this clear, and you can ignore the rest of my mail! Assuming such routers are within scope, there are some complicating issues with IPsec enabled routers that I think should be called out. I don't think much text is needed to cover this case. I'm not sure the best way to address these, but I have some suggestions to get the conversation started (and yes, I expect that you'll edit the text): - In section 2.2, I think mentioning something about the routing implications is worthwhile. How about at the end of the section adding something along the lines of : Additionally, the routing implications of gateway-to-gateway communication must be addressed. In the simple case, selectors provide sufficient information for a gateway to forward traffic appropriately. In other cases, additional tunneling (e.g., GRE) and routing (e.g., OSPF) protocols are run over IPsec tunnels, and the configuration impact on those protocols must be considered. There is also the case when L3VPNs operate over IPsec Tunnels. - In section 4.2, how about: (replacement text) 3. Gateways MUST allow for the operation of tunneling and routing protocols operating over spoke-to-spoke IPsec Tunnels with minimal, or no, configuration impact. and (new text) X. The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364]. If you want, you can make the "SHOULD" a "MUST", and "support" could be "be compatible with". I also have a few more minor comments: - In section 2.1, you introduce the term "NAT gateway" and then later use just "gateway" when I suspect you mean "NAT gateway". I suggest using the term "NAT" and thereby not introduce possible confusion between the gateway term defined in section 1.1 and "NAT gateways". - In section 2.2, s/occupies/requires - In sections 2.2, and Section 3.2 you say dynamic addresses makes static configuration impossible. This doesn't reflect the use of dynamic dns to handle this issues (and is currently supported by some vendors.) Let me know what you think, Lou From vishwas.ietf@gmail.com Thu Nov 15 16:14:12 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C241321F8623 for ; Thu, 15 Nov 2012 16:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1XnbnueJDBl for ; Thu, 15 Nov 2012 16:14:10 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B204221F84B6 for ; Thu, 15 Nov 2012 16:14:09 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1795434lah.31 for ; Thu, 15 Nov 2012 16:14:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NWCa6c2gfmpjkK3FS+O02aQbal4Sl+3FkWmT+6lzpkU=; b=Y76Nm66LKduDCUuJ01NWltEXpPFKb4F6EKX2bD4jx8rMpkKPTVMJNY7y2mUc2ESas9 m3IYyPxbk6HrXqTGkGI8qPvDAQk3NHecRbG25ebhTK4YG7uKzL/OyScfrruBrp2s1BDw lqnSj2nRisD9i400GDtoFRVV2oQPOetWxwOB6MO951sJtrgBqMUJl/mANTH1Qx7PellJ RDBAI53Iy/o1SEOg6GY6lkhAPzJvKFBTMxZ7vOnQYY8J5yXvJlA8QqbqvFmK2hGqcjMJ CorIWUKjGyCP4YAuxA8S41bpcbqXZMnEC5RnvSNAUJq9uBBdjJMGkXvvdy9Onl6nATbm L1jQ== MIME-Version: 1.0 Received: by 10.112.49.133 with SMTP id u5mr1226437lbn.105.1353024848405; Thu, 15 Nov 2012 16:14:08 -0800 (PST) Received: by 10.114.75.110 with HTTP; Thu, 15 Nov 2012 16:14:08 -0800 (PST) In-Reply-To: <50A5703F.4070305@labn.net> References: <50A5703F.4070305@labn.net> Date: Thu, 15 Nov 2012 16:14:08 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/alternative; boundary=bcaec553fdde76256804ce91a501 Cc: ipsec@ietf.org Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 00:14:12 -0000 --bcaec553fdde76256804ce91a501 Content-Type: text/plain; charset=ISO-8859-1 Hi Lou, Thanks a lot for your detailed comments. I have just started to change the document today, based on feedback I got on the list, so your comments come at a good time. My answers are inline: In section 1.1, you define the term gateway. I'm assuming that you are > using the term in the normal IPsec context, and that it includes IPsec > enabled routers. Is this correct? If not, the text should make this > clear, and you can ignore the rest of my mail! > Yes, the idea is an IPsec gateway will have Routing functionality too. Now whether its a tunnel gateway with routing embedded or the otehr way around is debatable. I also agree Routing is a big part of the functionality to be optimized, though I would consider it a different sub-part of the solution. > > Assuming such routers are within scope, there are some complicating > issues with IPsec enabled routers that I think should be called out. I > don't think much text is needed to cover this case. I'm not sure the > best way to address these, but I have some suggestions to get the > conversation started (and yes, I expect that you'll edit the text): > > - In section 2.2, I think mentioning something about the routing > implications is worthwhile. How about at the end of the section adding > something along the lines of : > > Additionally, the routing implications of gateway-to-gateway > communication must be addressed. In the simple case, > selectors provide sufficient information for a gateway to > forward traffic appropriately. In other cases, additional > tunneling (e.g., GRE) and routing (e.g., OSPF) protocols are > run over IPsec tunnels, and the configuration impact on those > protocols must be considered. There is also the case when > L3VPNs operate over IPsec Tunnels. > > We can add something in the lines of additional protocols are run over the IPsec tunnels and the solution should make an effort to allow for additional protocols like OSPF to be run optimally without too many changes in configuration. Infact we have a requirement to the effect in section 4.1 Gateways MUST allow tunnel binding, such that applications like Routing using the tunnels can work seamlessly without any updates to the higher level application configuration i.e. OSPF configuration. > - In section 4.2, how about: > (replacement text) > 3. Gateways MUST allow for the operation of tunneling and > routing protocols operating over spoke-to-spoke IPsec Tunnels > with minimal, or no, configuration impact. > > and (new text) > > I cannot find Section 4.2 in the document http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-00 is there more context you can provide for the same. > X. The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364]. > > If you want, you can make the "SHOULD" a "MUST", and "support" could be > "be compatible with". > I do not want to go ahead into details of what other routing solutions it should support. With that said I am not sure what you mean by having BGP MPLS VPN in an ADVPN scenario. BGP MPLS VPN is a provider provisioned VPN solution, this is a customer provisioned one. I see the 2 working in different layers, and interacting only in edge gateways where both solutions have an edge. > I also have a few more minor comments: > I am ok with the minor suggestions you have. Thanks, Vishwas > > - In section 2.1, you introduce the term "NAT gateway" and then later > use just "gateway" when I suspect you mean "NAT gateway". I suggest > using the term "NAT" and thereby not introduce possible confusion > between the gateway term defined in section 1.1 and "NAT gateways". > > - In section 2.2, s/occupies/requires > > - In sections 2.2, and Section 3.2 you say dynamic addresses makes > static configuration impossible. This doesn't reflect the use of > dynamic dns to handle this issues (and is currently supported by some > vendors.) > > Let me know what you think, > Lou > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --bcaec553fdde76256804ce91a501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lou,

Thanks a lot for your detailed comments. I have just started= to change the document today, based on feedback I got on the list, so your= comments come at a good time. My answers are inline:

In section 1.1, you define the term gateway.= =A0I'm assuming that you are
using the term in the normal IPsec context, and that it includes IPsec
enabled routers. =A0Is this correct? =A0If not, the text should make this clear, and you can ignore the rest of my mail!
Yes, th= e idea is an IPsec gateway will have Routing functionality too. Now whether= its a tunnel gateway with routing embedded or the otehr way around is deba= table. I also agree Routing is a big part of the functionality to be optimi= zed, though I would consider it a different sub-part of the solution.

Assuming such routers are within scope, there are some complicating
issues with IPsec enabled routers that I think should be called out. =A0I don't think much text is needed to cover this case. I'm not sure th= e
best way to address these, but I have some suggestions to get the
conversation started (and yes, I expect that you'll edit the text):

- In section 2.2, I think mentioning something about the routing
implications is worthwhile. How about at the end of the section adding
something along the lines of :

=A0 =A0 Additionally, the routing implications of gateway-to-gateway
=A0 =A0 communication must be addressed. =A0In the simple case,
=A0 =A0 selectors provide sufficient information for a gateway to
=A0 =A0 forward traffic appropriately. =A0In other cases, additional
=A0 =A0 tunneling (e.g., GRE) and routing (e.g., OSPF) protocols are
=A0 =A0 run over IPsec tunnels, and the configuration impact on those
=A0 =A0 protocols must be considered. =A0There is also the case when
=A0 =A0 L3VPNs operate over IPsec Tunnels.

We can add something in the lines of additional proto= cols are run over the IPsec tunnels and the solution should make an effort = to allow for additional protocols like OSPF to be run optimally without too= many changes in configuration.

Infact we have a requirement to the effect in section 4.1

    Gateways MUST allow tunnel binding, such that applications like
   Routing using the tunnels can work seamlessly without any updates to
   the higher level application configuration i.e.  OSPF configuration.


=A0
- In section 4.2, how about:
=A0 =A0(replacement text)
=A0 =A03. =A0Gateways MUST allow for the operation of tunneling and
=A0 =A0routing protocols operating over spoke-to-spoke IPsec Tunnels
=A0 =A0with minimal, or no, configuration impact.

and (new text)

I cannot find Section 4.2 in the document=A0 http:/= /tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-00 is there more= context you can provide for the same.
=A0
=A0 =A0X. =A0The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364].
If you want, you can make the "SHOULD" a "MUST", and &q= uot;support" could be
"be compatible with".
I do not want to go ah= ead into details of what other routing solutions it should support.
With that said I am not sure what you mean by having BGP MPLS VPN in an AD= VPN scenario. BGP MPLS VPN is a provider provisioned VPN solution, this is = a customer provisioned one. I see the 2 working in different layers, and in= teracting only in edge gateways where both solutions have an edge.


I also have a few more minor comments:
I am ok with th= e minor suggestions you have.

Thanks,
Vishwas
=A0

- In section 2.1, you introduce the term "NAT gateway" and then l= ater
use just "gateway" when I suspect you mean "NAT gateway"= ;. =A0I suggest
using the term "NAT" and thereby not introduce possible confusion=
between the gateway term defined in section 1.1 and "NAT gateways"= ;.

- In section 2.2, s/occupies/requires

- In sections 2.2, and Section 3.2 you say dynamic addresses makes
static configuration impossible. =A0This doesn't reflect the use of
dynamic dns to handle this issues (and is currently supported by some
vendors.)

Let me know what you think,
Lou
_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec


--bcaec553fdde76256804ce91a501-- From lberger@labn.net Thu Nov 15 16:46:44 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A051F0C6A for ; Thu, 15 Nov 2012 16:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.051 X-Spam-Level: X-Spam-Status: No, score=-101.051 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENkfs1InfTZF for ; Thu, 15 Nov 2012 16:46:43 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id 54FE91F041A for ; Thu, 15 Nov 2012 16:46:42 -0800 (PST) Received: (qmail 13182 invoked by uid 0); 16 Nov 2012 00:46:20 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 16 Nov 2012 00:46:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=J+N2NA/l+oASQsz5n9mSg9HURUy7/FZIO5cH/m0KVLc=; b=swNxGkLKso158GwWS6Cj7Us20pujfEIzs8gkBwpIXIMg01/gQ4e3LYlRxFGokSREeO+cVfECmBoGMDZkKxs7D30zN/Xk4awqGM2D9Nil+6E+NV95yj56/p5sZn+V7R3d; Received: from box313.bluehost.com ([69.89.31.113]:50159 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TZA4a-00010Z-Bi; Thu, 15 Nov 2012 17:46:20 -0700 Message-ID: <50A58CDB.30402@labn.net> Date: Thu, 15 Nov 2012 19:46:19 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Vishwas Manral References: <50A5703F.4070305@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ipsec@ietf.org Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 00:46:44 -0000 Vishwas, Thanks for the quick response. Please see below. On 11/15/2012 7:14 PM, Vishwas Manral wrote: > Hi Lou, > > Thanks a lot for your detailed comments. I have just started to change > the document today, based on feedback I got on the list, so your > comments come at a good time. My answers are inline: > > In section 1.1, you define the term gateway. I'm assuming that you are > using the term in the normal IPsec context, and that it includes IPsec > enabled routers. Is this correct? If not, the text should make this > clear, and you can ignore the rest of my mail! > > Yes, the idea is an IPsec gateway will have Routing functionality too. > Now whether its a tunnel gateway with routing embedded or the otehr way > around is debatable. I also agree Routing is a big part of the > functionality to be optimized, though I would consider it a different > sub-part of the solution. > > > Assuming such routers are within scope, there are some complicating > issues with IPsec enabled routers that I think should be called out. I > don't think much text is needed to cover this case. I'm not sure the > best way to address these, but I have some suggestions to get the > conversation started (and yes, I expect that you'll edit the text): > > - In section 2.2, I think mentioning something about the routing > implications is worthwhile. How about at the end of the section adding > something along the lines of : > > Additionally, the routing implications of gateway-to-gateway > communication must be addressed. In the simple case, > selectors provide sufficient information for a gateway to > forward traffic appropriately. In other cases, additional > tunneling (e.g., GRE) and routing (e.g., OSPF) protocols are > run over IPsec tunnels, and the configuration impact on those > protocols must be considered. There is also the case when > L3VPNs operate over IPsec Tunnels. > > We can add something in the lines of additional protocols are run over > the IPsec tunnels and the solution should make an effort to allow for > additional protocols like OSPF to be run optimally without too many > changes in configuration. > > Infact we have a requirement to the effect in section 4.1 yes, this is what I referred to as 4.2 below, and suggested some replacement text... > > Gateways MUST allow tunnel binding, such that applications like > Routing using the tunnels can work seamlessly without any updates to > the higher level application configuration i.e. OSPF configuration. > > > > > > - In section 4.2, how about: > (replacement text) > 3. Gateways MUST allow for the operation of tunneling and > routing protocols operating over spoke-to-spoke IPsec Tunnels > with minimal, or no, configuration impact. > > and (new text) > > I cannot find Section 4.2 in the document > http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-00 is there > more context you can provide for the same. 4.2 = 4.1 > > > X. The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364]. > > If you want, you can make the "SHOULD" a "MUST", and "support" could be > "be compatible with". > > I do not want to go ahead into details of what other routing solutions > it should support. > > With that said I am not sure what you mean by having BGP MPLS VPN in an > ADVPN scenario. BGP MPLS VPN is a provider provisioned VPN solution, > this is a customer provisioned one. Ahh, interesting point. When I read the document I was looking to see if it was scoped purely to CE/customer based solutions. Reading section 2 (intro) and 2.2, I saw no such restriction. So I think section 2.2 should be explicit on this point either way. Which is why I proposed the text "There is also the case when L3VPNs operate over IPsec Tunnels." (To explicitly include this case.) If the WG wants this case excluded, that's fine too. > I see the 2 working in different > layers, and interacting only in edge gateways where both solutions have > an edge. Sure, but the problem exists for both. Thanks, Lou > > > I also have a few more minor comments: > > I am ok with the minor suggestions you have. > > Thanks, > Vishwas > > > > - In section 2.1, you introduce the term "NAT gateway" and then later > use just "gateway" when I suspect you mean "NAT gateway". I suggest > using the term "NAT" and thereby not introduce possible confusion > between the gateway term defined in section 1.1 and "NAT gateways". > > - In section 2.2, s/occupies/requires > > - In sections 2.2, and Section 3.2 you say dynamic addresses makes > static configuration impossible. This doesn't reflect the use of > dynamic dns to handle this issues (and is currently supported by some > vendors.) > > Let me know what you think, > Lou > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > From vishwas.ietf@gmail.com Fri Nov 16 09:49:38 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C77E21F8AA9 for ; Fri, 16 Nov 2012 09:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x4CBV7LTT9h for ; Fri, 16 Nov 2012 09:49:37 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8D121F8A86 for ; Fri, 16 Nov 2012 09:49:37 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2453849lah.31 for ; Fri, 16 Nov 2012 09:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/BdogOw24FAx1yns6dO2Bn5BJtgvaKWBN4mS41GpeGU=; b=xquucEjpwxBlJLNc3ztPCR8xDn0B7KNjBTgM5t+MJedHsLMGI1Kj3OPVvBSVQlgCw6 XNW6r500qk7AdrxGFvm7ej61LbZrr02UtTTmHBzVm4jSWUWXD2doSoOWckuihDquwKzk glb856p84vM1buwuKCN/4iWAtEeyKgA8hbuvTZg9gzgR1j/GBtD2SfusUO8BpUIIYgmz 7v2J5UD8dXc41GxDyUwWblGQQvbl3e2Pc757G71eNkw+4XtPhPtPTgzK+U6TZnWEwlvy mjE9ynWr/8cLnNTI/SZ7Ni4ty4vUOT9WUcZFG26IygqO2jEu60bLf4Iw5Vop/Ic7uZAg j7ew== MIME-Version: 1.0 Received: by 10.152.133.140 with SMTP id pc12mr4870937lab.53.1353088176094; Fri, 16 Nov 2012 09:49:36 -0800 (PST) Received: by 10.114.75.110 with HTTP; Fri, 16 Nov 2012 09:49:36 -0800 (PST) In-Reply-To: <50A58CDB.30402@labn.net> References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> Date: Fri, 16 Nov 2012 09:49:36 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/alternative; boundary=f46d042dfe9915fe5204cea0644e Cc: ipsec@ietf.org Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 17:49:38 -0000 --f46d042dfe9915fe5204cea0644e Content-Type: text/plain; charset=ISO-8859-1 Hi Lou, Thanks for the quick reply. Just a few comments prefixed with a "VM>": > > > We can add something in the lines of additional protocols are run over > > the IPsec tunnels and the solution should make an effort to allow for > > additional protocols like OSPF to be run optimally without too many > > changes in configuration. > > > > Infact we have a requirement to the effect in section 4.1 > > yes, this is what I referred to as 4.2 below, and suggested some > replacement text... > > OK got it. > > > > Gateways MUST allow tunnel binding, such that applications like > > Routing using the tunnels can work seamlessly without any updates to > > the higher level application configuration i.e. OSPF configuration. > > > > - In section 4.2, how about: > > (replacement text) > > 3. Gateways MUST allow for the operation of tunneling and > > routing protocols operating over spoke-to-spoke IPsec Tunnels > > with minimal, or no, configuration impact. > VM> Ok will specifically specify tunnels and routing protocols. > > > > > > X. The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364]. > > > > If you want, you can make the "SHOULD" a "MUST", and "support" could > be > > "be compatible with". > > > > I do not want to go ahead into details of what other routing solutions > > it should support. > > > > With that said I am not sure what you mean by having BGP MPLS VPN in an > > ADVPN scenario. BGP MPLS VPN is a provider provisioned VPN solution, > > this is a customer provisioned one. > > Ahh, interesting point. When I read the document I was looking to see > if it was scoped purely to CE/customer based solutions. Reading section > 2 (intro) and 2.2, I saw no such restriction. So I think section 2.2 > should be explicit on this point either way. Which is why I proposed the > text "There is also the case when L3VPNs operate over IPsec Tunnels." > (To explicitly include this case.) If the WG wants this case excluded, > that's fine too. > VM> It is not scoped purely as a CE device scenario, and after seeing your comment I see no reason to leave that out of scope (though if I understand your concern better I may feel otherwise). L3VPN can work over GRE tunnels/ L2TP tunnels, which can themselves use IPsec. Again in my view the L3VPN and the IPsec VPN are 2 different layers in the stack if they run on the same device. Do you see a reason to explicitly mention L3VPN in this case? Thanks, Vishwas > > > I see the 2 working in different > > layers, and interacting only in edge gateways where both solutions have > > an edge. > > Sure, but the problem exists for both. > > Thanks, > Lou > > > > > > I also have a few more minor comments: > > > > I am ok with the minor suggestions you have. > > > > Thanks, > > Vishwas > > > > > > > > - In section 2.1, you introduce the term "NAT gateway" and then later > > use just "gateway" when I suspect you mean "NAT gateway". I suggest > > using the term "NAT" and thereby not introduce possible confusion > > between the gateway term defined in section 1.1 and "NAT gateways". > > > > - In section 2.2, s/occupies/requires > > > > - In sections 2.2, and Section 3.2 you say dynamic addresses makes > > static configuration impossible. This doesn't reflect the use of > > dynamic dns to handle this issues (and is currently supported by some > > vendors.) > > > > Let me know what you think, > > Lou > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > --f46d042dfe9915fe5204cea0644e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lou,

Thanks for the quick reply. Just a few comments prefixed wit= h a "VM>":

>
> We can add something in the lines of additional protocols are run over=
> the IPsec tunnels and the solution should make an effort to allow for<= br> > additional protocols like OSPF to be run optimally without too many > changes in configuration.
>
> Infact we have a requirement to the effect in section 4.1

yes, this is what I referred to as 4.2 below, and suggested som= e
replacement text...

OK got it.=A0
>
> =A0 =A0 Gateways MUST allow tunnel binding, such that applications lik= e
> =A0 =A0Routing using the tunnels can work seamlessly without any updat= es to
> =A0 =A0the higher level application configuration i.e. =A0OSPF configu= ration.
>
> =A0 =A0 - In section 4.2, how about:
> =A0 =A0 =A0 =A0(replacement text)
> =A0 =A0 =A0 =A03. =A0Gateways MUST allow for the operation of tunnelin= g and
> =A0 =A0 =A0 =A0routing protocols operating over spoke-to-spoke IPsec T= unnels
> =A0 =A0 =A0 =A0with minimal, or no, configuration impact.
VM> Ok will specifically specify tunnels and routing prot= ocols.
=A0
>
>
> =A0 =A0 =A0 =A0X. =A0The solution SHOULD support BGP/MPLS IP VPNs, see= [RFC4364].
>
> =A0 =A0 If you want, you can make the "SHOULD" a "MUST&= quot;, and "support" could be
> =A0 =A0 "be compatible with".
>
> I do not want to go ahead into details of what other routing solutions=
> it should support.
>
> With that said I am not sure what you mean by having BGP MPLS VPN in a= n
> ADVPN scenario. BGP MPLS VPN is a provider provisioned VPN solution, > this is a customer provisioned one.

Ahh, interesting point. =A0When I read the document I was looking to = see
if it was scoped purely to CE/customer based solutions. =A0Reading section<= br> 2 (intro) and 2.2, I saw no such restriction. =A0So I think section 2.2
should be explicit on this point either way. Which is why I proposed the text "There is also the case when L3VPNs operate over IPsec Tunnels.&q= uot;
(To explicitly include this case.) =A0If the WG wants this case excluded, that's fine too.
VM> It is not scoped purely as= a CE device scenario, and after seeing your comment I see no reason to lea= ve that out of scope (though if I understand your concern better I may feel= otherwise). L3VPN can work over GRE tunnels/ L2TP tunnels, which can thems= elves use IPsec. Again in my view the L3VPN and the IPsec VPN are 2 differe= nt layers in the stack if they run on the same device. Do you see a reason = to explicitly mention L3VPN in this case?

Thanks,
Vishwas
=A0

> I see the 2 working in different
> layers, and interacting only in edge gateways where both solutions hav= e
> an edge.

Sure, but the problem exists for both.

Thanks,
Lou
>
>
> =A0 =A0 I also have a few more minor comments:
>
> I am ok with the minor suggestions you have.
>
> Thanks,
> Vishwas
>
>
>
> =A0 =A0 - In section 2.1, you introduce the term "NAT gateway&quo= t; and then later
> =A0 =A0 use just "gateway" when I suspect you mean "NAT= gateway". =A0I suggest
> =A0 =A0 using the term "NAT" and thereby not introduce possi= ble confusion
> =A0 =A0 between the gateway term defined in section 1.1 and "NAT = gateways".
>
> =A0 =A0 - In section 2.2, s/occupies/requires
>
> =A0 =A0 - In sections 2.2, and Section 3.2 you say dynamic addresses m= akes
> =A0 =A0 static configuration impossible. =A0This doesn't reflect t= he use of
> =A0 =A0 dynamic dns to handle this issues (and is currently supported = by some
> =A0 =A0 vendors.)
>
> =A0 =A0 Let me know what you think,
> =A0 =A0 Lou
> =A0 =A0 _______________________________________________
> =A0 =A0 IPsec mailing list
> =A0 =A0 IPsec@ietf.org <= ;mailto:IPsec@ietf.org>
> =A0 =A0 https://www.ietf.org/mailman/listinfo/ipsec
>
>
>

--f46d042dfe9915fe5204cea0644e-- From lberger@labn.net Fri Nov 16 10:17:07 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2469D21F88C3 for ; Fri, 16 Nov 2012 10:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.83 X-Spam-Level: X-Spam-Status: No, score=-100.83 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZc-toLYBgfz for ; Fri, 16 Nov 2012 10:17:02 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 7972621F8858 for ; Fri, 16 Nov 2012 10:17:01 -0800 (PST) Received: (qmail 29434 invoked by uid 0); 16 Nov 2012 18:16:40 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 16 Nov 2012 18:16:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=I2hXn9+RV9ha3W1c7wmHo+ONTRXcU1EkJT5t4ZJx0/g=; b=Oy3yNKfFm9rY/bjnfCQ16kORnMQAa5h1B31lLShc7EDB5Co1BpbF/UxkFTJ3GKGiokwwUBe10/KIAhwZyiGuCsmkQZP4AWyjzKJ98aRW/UeJcrKQANOrHxPyRKCodEUQ; Received: from box313.bluehost.com ([69.89.31.113]:55401 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TZQT0-00020A-V1; Fri, 16 Nov 2012 11:16:39 -0700 Message-ID: <50A682F8.9080907@labn.net> Date: Fri, 16 Nov 2012 13:16:24 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Vishwas Manral References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ipsec@ietf.org Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:17:07 -0000 Vishwas, Please see below. On 11/16/2012 12:49 PM, Vishwas Manral wrote: > Hi Lou, > > Thanks for the quick reply. Just a few comments prefixed with a "VM>": > > > > > We can add something in the lines of additional protocols are run over > > the IPsec tunnels and the solution should make an effort to allow for > > additional protocols like OSPF to be run optimally without too many > > changes in configuration. > > > > Infact we have a requirement to the effect in section 4.1 > > yes, this is what I referred to as 4.2 below, and suggested some > replacement text... > > OK got it. > > > > > Gateways MUST allow tunnel binding, such that applications like > > Routing using the tunnels can work seamlessly without any > updates to > > the higher level application configuration i.e. OSPF > configuration. > > > > - In section 4.2, how about: > > (replacement text) > > 3. Gateways MUST allow for the operation of tunneling and > > routing protocols operating over spoke-to-spoke IPsec Tunnels > > with minimal, or no, configuration impact. > > VM> Ok will specifically specify tunnels and routing protocols. > Great. > > > > > > > X. The solution SHOULD support BGP/MPLS IP VPNs, see > [RFC4364]. > > > > If you want, you can make the "SHOULD" a "MUST", and "support" > could be > > "be compatible with". > > > > I do not want to go ahead into details of what other routing solutions > > it should support. > > > > With that said I am not sure what you mean by having BGP MPLS VPN > in an > > ADVPN scenario. BGP MPLS VPN is a provider provisioned VPN solution, > > this is a customer provisioned one. > > Ahh, interesting point. When I read the document I was looking to see > if it was scoped purely to CE/customer based solutions. Reading section > 2 (intro) and 2.2, I saw no such restriction. So I think section 2.2 > should be explicit on this point either way. Which is why I proposed the > text "There is also the case when L3VPNs operate over IPsec Tunnels." > (To explicitly include this case.) If the WG wants this case excluded, > that's fine too. > > VM> It is not scoped purely as a CE device scenario, and after seeing > your comment I see no reason to leave that out of scope (though if I > understand your concern better I may feel otherwise). L3VPN can work > over GRE tunnels/ L2TP tunnels, which can themselves use IPsec. Again in > my view the L3VPN and the IPsec VPN are 2 different layers in the stack > if they run on the same device. I'm not sure I agree with this statement. Let's say you have a BGP VPN that uses IPsec tunnels between the PEs (which was described in a couple of expired drafts and can be supported using RFC5566), and then wants to be able to use dynamic PE to PE IPsec tunnels. Does this fit your "2 different layer" perspective? Either way, I think such usage should be explicitly in scope as it is a very different model / use case from CE-based IPsec VPNs. > Do you see a reason to explicitly > mention L3VPN in this case? I'm open to different ways to cover the above. Much thanks, Lou > > Thanks, > Vishwas > > > > > I see the 2 working in different > > layers, and interacting only in edge gateways where both solutions > have > > an edge. > > Sure, but the problem exists for both. > > Thanks, > Lou > > > > > > I also have a few more minor comments: > > > > I am ok with the minor suggestions you have. > > > > Thanks, > > Vishwas > > > > > > > > - In section 2.1, you introduce the term "NAT gateway" and > then later > > use just "gateway" when I suspect you mean "NAT gateway". I > suggest > > using the term "NAT" and thereby not introduce possible confusion > > between the gateway term defined in section 1.1 and "NAT > gateways". > > > > - In section 2.2, s/occupies/requires > > > > - In sections 2.2, and Section 3.2 you say dynamic addresses makes > > static configuration impossible. This doesn't reflect the use of > > dynamic dns to handle this issues (and is currently supported > by some > > vendors.) > > > > Let me know what you think, > > Lou > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > From vishwas.ietf@gmail.com Fri Nov 16 10:34:03 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CA521F8772 for ; Fri, 16 Nov 2012 10:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TP8lXuLIwH89 for ; Fri, 16 Nov 2012 10:34:02 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E319B21F86AB for ; Fri, 16 Nov 2012 10:34:01 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2561758lbk.31 for ; Fri, 16 Nov 2012 10:34:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LVr2hyBHX7Ot+FTEFuB6LGSjn7H8pM6sOCZszv8J9As=; b=EY79MAlfuUj0qkz4qCKyN2TM4flBCsS4+gH1DZrtn/XgmLh1HBxGYOMsNEX3rUNmzA j7e3PjJ0haU8PSU+DOHEoZlrojgIjYSTRknlB1TvQSsn0FZ/+Euqx8RZRCtNs+uBHKb0 G+JQBmeWJGM5rvXSUI/150j/ERNM0mL9xyLprZey3FFmQxFq0QUci+d7K2aeXHgn3RUo bAfVBO8NqH56UwfbR+9JCvzfmpfLaitzR1fpd772xEHcMyR2AS6hE4xiPZYisYTULIKw XNFU8cOLkYy4GiRZScPAsIJuXiCqm9mv09ABUfRKqZBiEdKqSVLbMv25PUr0PhnvFvRz fgDA== MIME-Version: 1.0 Received: by 10.152.133.140 with SMTP id pc12mr4976157lab.53.1353090840705; Fri, 16 Nov 2012 10:34:00 -0800 (PST) Received: by 10.114.75.110 with HTTP; Fri, 16 Nov 2012 10:34:00 -0800 (PST) In-Reply-To: <50A682F8.9080907@labn.net> References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> Date: Fri, 16 Nov 2012 10:34:00 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/alternative; boundary=f46d042dfe99e8ba3404cea10294 Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:34:03 -0000 --f46d042dfe99e8ba3404cea10294 Content-Type: text/plain; charset=ISO-8859-1 Hi Lou, > I'm not sure I agree with this statement. Let's say you have > a BGP VPN that uses IPsec tunnels between the PEs (which > was described in a couple of expired drafts and can be supported > using RFC5566), and then wants to be able to use dynamic PE > to PE IPsec tunnels. Does this fit your "2 different layer" > perspective? IPsec with ADVPN secures the tunnel and creates the mesh underlay on need basis/ or automatically. L3VPN creates the overlay, identifies the tenant/ customer a packet belongs to and passes the packet on. Where do we see the need for tighter integration here? Is it allowing the ability to create groups of ADVPN instances? Thanks, Vishwas On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger wrote: > Vishwas, > > Please see below. > > On 11/16/2012 12:49 PM, Vishwas Manral wrote: > > Hi Lou, > > > > Thanks for the quick reply. Just a few comments prefixed with a "VM>": > > > > > > > > We can add something in the lines of additional protocols are run > over > > > the IPsec tunnels and the solution should make an effort to allow > for > > > additional protocols like OSPF to be run optimally without too many > > > changes in configuration. > > > > > > Infact we have a requirement to the effect in section 4.1 > > > > yes, this is what I referred to as 4.2 below, and suggested some > > replacement text... > > > > OK got it. > > > > > > > > Gateways MUST allow tunnel binding, such that applications like > > > Routing using the tunnels can work seamlessly without any > > updates to > > > the higher level application configuration i.e. OSPF > > configuration. > > > > > > - In section 4.2, how about: > > > (replacement text) > > > 3. Gateways MUST allow for the operation of tunneling and > > > routing protocols operating over spoke-to-spoke IPsec > Tunnels > > > with minimal, or no, configuration impact. > > > > VM> Ok will specifically specify tunnels and routing protocols. > > > > Great. > > > > > > > > > > > > X. The solution SHOULD support BGP/MPLS IP VPNs, see > > [RFC4364]. > > > > > > If you want, you can make the "SHOULD" a "MUST", and "support" > > could be > > > "be compatible with". > > > > > > I do not want to go ahead into details of what other routing > solutions > > > it should support. > > > > > > With that said I am not sure what you mean by having BGP MPLS VPN > > in an > > > ADVPN scenario. BGP MPLS VPN is a provider provisioned VPN > solution, > > > this is a customer provisioned one. > > > > Ahh, interesting point. When I read the document I was looking to > see > > if it was scoped purely to CE/customer based solutions. Reading > section > > 2 (intro) and 2.2, I saw no such restriction. So I think section 2.2 > > should be explicit on this point either way. Which is why I proposed > the > > text "There is also the case when L3VPNs operate over IPsec Tunnels." > > (To explicitly include this case.) If the WG wants this case > excluded, > > that's fine too. > > > > VM> It is not scoped purely as a CE device scenario, and after seeing > > your comment I see no reason to leave that out of scope (though if I > > understand your concern better I may feel otherwise). L3VPN can work > > over GRE tunnels/ L2TP tunnels, which can themselves use IPsec. Again in > > my view the L3VPN and the IPsec VPN are 2 different layers in the stack > > if they run on the same device. > > I'm not sure I agree with this statement. Let's say you have a BGP VPN > that uses IPsec tunnels between the PEs (which was described in a couple > of expired drafts and can be supported using RFC5566), and then wants to > be able to use dynamic PE to PE IPsec tunnels. Does this fit your "2 > different layer" perspective? > > Either way, I think such usage should be explicitly in scope as it is a > very different model / use case from CE-based IPsec VPNs. > > > Do you see a reason to explicitly > > mention L3VPN in this case? > > I'm open to different ways to cover the above. > > Much thanks, > Lou > > > > Thanks, > > Vishwas > > > > > > > > > I see the 2 working in different > > > layers, and interacting only in edge gateways where both solutions > > have > > > an edge. > > > > Sure, but the problem exists for both. > > > > Thanks, > > Lou > > > > > > > > > I also have a few more minor comments: > > > > > > I am ok with the minor suggestions you have. > > > > > > Thanks, > > > Vishwas > > > > > > > > > > > > - In section 2.1, you introduce the term "NAT gateway" and > > then later > > > use just "gateway" when I suspect you mean "NAT gateway". I > > suggest > > > using the term "NAT" and thereby not introduce possible > confusion > > > between the gateway term defined in section 1.1 and "NAT > > gateways". > > > > > > - In section 2.2, s/occupies/requires > > > > > > - In sections 2.2, and Section 3.2 you say dynamic addresses > makes > > > static configuration impossible. This doesn't reflect the use > of > > > dynamic dns to handle this issues (and is currently supported > > by some > > > vendors.) > > > > > > Let me know what you think, > > > Lou > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > > > > > --f46d042dfe99e8ba3404cea10294 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lou,

> I'm not sure I agree with this statement. =A0Let= 9;s say you have
> a BGP VPN that uses IPsec tunnels between the PEs (which
> was described in a c= ouple of expired drafts and can be supported
> using RFC5566), and then wan= ts to be able to use dynamic PE
> to PE IPsec tunnels. =A0Does this fit you= r "2 different layer"
> perspective?
IPsec with ADVPN secures the= tunnel and creates the mesh underlay on need basis/ or automatically. L3VP= N creates the overlay, identifies the tenant/ customer a packet belongs to = and passes the packet on.

Where do we see the need for tighter integration here? Is it allowing t= he ability to create groups of ADVPN instances?

Thanks,
Vishwas
On Fri, Nov 16, 2012 at 10:16 AM, Lou Berg= er <lberger@labn.net> wrote:
Vishwas,

Please see below.

On 11/16/2012 12:49 PM, Vishwas Manral wrote:
> Hi Lou,
>
> Thanks for the quick reply. Just a few comments prefixed with a "= VM>":
>
> =A0 =A0 >
> =A0 =A0 > We can add something in the lines of additional protocols= are run over
> =A0 =A0 > the IPsec tunnels and the solution should make an effort = to allow for
> =A0 =A0 > additional protocols like OSPF to be run optimally withou= t too many
> =A0 =A0 > changes in configuration.
> =A0 =A0 >
> =A0 =A0 > Infact we have a requirement to the effect in section 4.1=
>
> =A0 =A0 yes, this is what I referred to as 4.2 below, and suggested so= me
> =A0 =A0 replacement text...
>
> OK got it.
>
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Gateways MUST allow tunnel binding, such that app= lications like
> =A0 =A0 > =A0 =A0Routing using the tunnels can work seamlessly with= out any
> =A0 =A0 updates to
> =A0 =A0 > =A0 =A0the higher level application configuration i.e. = =A0OSPF
> =A0 =A0 configuration.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 - In section 4.2, how about:
> =A0 =A0 > =A0 =A0 =A0 =A0(replacement text)
> =A0 =A0 > =A0 =A0 =A0 =A03. =A0Gateways MUST allow for the operatio= n of tunneling and
> =A0 =A0 > =A0 =A0 =A0 =A0routing protocols operating over spoke-to-= spoke IPsec Tunnels
> =A0 =A0 > =A0 =A0 =A0 =A0with minimal, or no, configuration impact.=
>
> VM> Ok will specifically specify tunnels and routing protocols.
>

Great.

>
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 =A0 =A0X. =A0The solution SHOULD support BGP/MPLS= IP VPNs, see
> =A0 =A0 [RFC4364].
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 If you want, you can make the "SHOULD" = a "MUST", and "support"
> =A0 =A0 could be
> =A0 =A0 > =A0 =A0 "be compatible with".
> =A0 =A0 >
> =A0 =A0 > I do not want to go ahead into details of what other rout= ing solutions
> =A0 =A0 > it should support.
> =A0 =A0 >
> =A0 =A0 > With that said I am not sure what you mean by having BGP = MPLS VPN
> =A0 =A0 in an
> =A0 =A0 > ADVPN scenario. BGP MPLS VPN is a provider provisioned VP= N solution,
> =A0 =A0 > this is a customer provisioned one.
>
> =A0 =A0 Ahh, interesting point. =A0When I read the document I was look= ing to see
> =A0 =A0 if it was scoped purely to CE/customer based solutions. =A0Rea= ding section
> =A0 =A0 2 (intro) and 2.2, I saw no such restriction. =A0So I think se= ction 2.2
> =A0 =A0 should be explicit on this point either way. Which is why I pr= oposed the
> =A0 =A0 text "There is also the case when L3VPNs operate over IPs= ec Tunnels."
> =A0 =A0 (To explicitly include this case.) =A0If the WG wants this cas= e excluded,
> =A0 =A0 that's fine too.
>
> VM> It is not scoped purely as a CE device scenario, and after seei= ng
> your comment I see no reason to leave that out of scope (though if I > understand your concern better I may feel otherwise). L3VPN can work > over GRE tunnels/ L2TP tunnels, which can themselves use IPsec. Again = in
> my view the L3VPN and the IPsec VPN are 2 different layers in the stac= k
> if they run on the same device.

I'm not sure I agree with this statement. =A0Let's say you ha= ve a BGP VPN
that uses IPsec tunnels between the PEs (which was described in a couple of expired drafts and can be supported using RFC5566), and then wants to be able to use dynamic PE to PE IPsec tunnels. =A0Does this fit your "= 2
different layer" perspective?

Either way, I think such usage should be explicitly in scope as it is a
very different model / use case from CE-based IPsec VPNs.

> Do you see a reason to explicitly
> mention L3VPN in this case?

I'm open to different ways to cover the above.

Much thanks,
Lou
>
> Thanks,
> Vishwas
>
>
>
> =A0 =A0 > I see the 2 working in different
> =A0 =A0 > layers, and interacting only in edge gateways where both = solutions
> =A0 =A0 have
> =A0 =A0 > an edge.
>
> =A0 =A0 Sure, but the problem exists for both.
>
> =A0 =A0 Thanks,
> =A0 =A0 Lou
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 I also have a few more minor comments:
> =A0 =A0 >
> =A0 =A0 > I am ok with the minor suggestions you have.
> =A0 =A0 >
> =A0 =A0 > Thanks,
> =A0 =A0 > Vishwas
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 - In section 2.1, you introduce the term "NA= T gateway" and
> =A0 =A0 then later
> =A0 =A0 > =A0 =A0 use just "gateway" when I suspect you m= ean "NAT gateway". =A0I
> =A0 =A0 suggest
> =A0 =A0 > =A0 =A0 using the term "NAT" and thereby not in= troduce possible confusion
> =A0 =A0 > =A0 =A0 between the gateway term defined in section 1.1 a= nd "NAT
> =A0 =A0 gateways".
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 - In section 2.2, s/occupies/requires
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 - In sections 2.2, and Section 3.2 you say dynami= c addresses makes
> =A0 =A0 > =A0 =A0 static configuration impossible. =A0This doesn= 9;t reflect the use of
> =A0 =A0 > =A0 =A0 dynamic dns to handle this issues (and is current= ly supported
> =A0 =A0 by some
> =A0 =A0 > =A0 =A0 vendors.)
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Let me know what you think,
> =A0 =A0 > =A0 =A0 Lou
> =A0 =A0 > =A0 =A0 _______________________________________________ > =A0 =A0 > =A0 =A0 IPsec mailing list
> =A0 =A0 > =A0 =A0 IPs= ec@ietf.org <mailto:IPsec@ietf.org= > <mailto:IPsec@ietf.org > =A0 =A0 <mailto:IPsec@ietf.org>>
> =A0 =A0 > =A0 =A0 https://www.ietf.org/mailman/listinfo/ipsec > =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 >
>
>

--f46d042dfe99e8ba3404cea10294-- From lberger@labn.net Fri Nov 16 10:45:43 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5ED221F8A67 for ; Fri, 16 Nov 2012 10:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.131 X-Spam-Level: X-Spam-Status: No, score=-100.131 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-n90zADsyQ9 for ; Fri, 16 Nov 2012 10:45:43 -0800 (PST) Received: from oproxy12-pub.bluehost.com (50-87-16-10.unifiedlayer.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id D70B521F8A65 for ; Fri, 16 Nov 2012 10:45:42 -0800 (PST) Received: (qmail 20258 invoked by uid 0); 16 Nov 2012 18:45:21 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 16 Nov 2012 18:45:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=5QM68Q94uIthH10MzjB4MH2u5I/eczguYbrcTdIwoxE=; b=ObPPp0gQZRPs7+0obq/HtHltPM3tUSqkeRGSAgdEmxjYVzn2NKuMKjGBpJ9gtfcFTqHm2LP4h0wBUJTyxmRqI3nK9eMTGSrVQ3O6hpG5T0myl8W59o7Kd1lZ4vBiomu6; Received: from box313.bluehost.com ([69.89.31.113]:58385 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TZQuk-0000at-B5; Fri, 16 Nov 2012 11:45:21 -0700 Message-ID: <50A689A9.1090803@labn.net> Date: Fri, 16 Nov 2012 13:44:57 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Vishwas Manral References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:45:43 -0000 Vishwas, Sure, but it's the BGP information that indicates what IPsec tunnels are needed / when the SAs get established... Again, I just asking for language that points to this use case, not implementation details. Thanks, Lou On 11/16/2012 1:34 PM, Vishwas Manral wrote: > Hi Lou, > >> I'm not sure I agree with this statement. Let's say you have >> a BGP VPN that uses IPsec tunnels between the PEs (which >> was described in a couple of expired drafts and can be supported >> using RFC5566), and then wants to be able to use dynamic PE >> to PE IPsec tunnels. Does this fit your "2 different layer" >> perspective? > IPsec with ADVPN secures the tunnel and creates the mesh underlay on > need basis/ or automatically. L3VPN creates the overlay, identifies the > tenant/ customer a packet belongs to and passes the packet on. > > Where do we see the need for tighter integration here? Is it allowing > the ability to create groups of ADVPN instances? > > Thanks, > Vishwas > > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger > wrote: > > Vishwas, > > Please see below. > > On 11/16/2012 12:49 PM, Vishwas Manral wrote: > > Hi Lou, > > > > Thanks for the quick reply. Just a few comments prefixed with a "VM>": > > > > > > > > We can add something in the lines of additional protocols > are run over > > > the IPsec tunnels and the solution should make an effort to > allow for > > > additional protocols like OSPF to be run optimally without > too many > > > changes in configuration. > > > > > > Infact we have a requirement to the effect in section 4.1 > > > > yes, this is what I referred to as 4.2 below, and suggested some > > replacement text... > > > > OK got it. > > > > > > > > Gateways MUST allow tunnel binding, such that > applications like > > > Routing using the tunnels can work seamlessly without any > > updates to > > > the higher level application configuration i.e. OSPF > > configuration. > > > > > > - In section 4.2, how about: > > > (replacement text) > > > 3. Gateways MUST allow for the operation of > tunneling and > > > routing protocols operating over spoke-to-spoke IPsec > Tunnels > > > with minimal, or no, configuration impact. > > > > VM> Ok will specifically specify tunnels and routing protocols. > > > > Great. > > > > > > > > > > > > X. The solution SHOULD support BGP/MPLS IP VPNs, see > > [RFC4364]. > > > > > > If you want, you can make the "SHOULD" a "MUST", and > "support" > > could be > > > "be compatible with". > > > > > > I do not want to go ahead into details of what other routing > solutions > > > it should support. > > > > > > With that said I am not sure what you mean by having BGP > MPLS VPN > > in an > > > ADVPN scenario. BGP MPLS VPN is a provider provisioned VPN > solution, > > > this is a customer provisioned one. > > > > Ahh, interesting point. When I read the document I was > looking to see > > if it was scoped purely to CE/customer based solutions. > Reading section > > 2 (intro) and 2.2, I saw no such restriction. So I think > section 2.2 > > should be explicit on this point either way. Which is why I > proposed the > > text "There is also the case when L3VPNs operate over IPsec > Tunnels." > > (To explicitly include this case.) If the WG wants this case > excluded, > > that's fine too. > > > > VM> It is not scoped purely as a CE device scenario, and after seeing > > your comment I see no reason to leave that out of scope (though if I > > understand your concern better I may feel otherwise). L3VPN can work > > over GRE tunnels/ L2TP tunnels, which can themselves use IPsec. > Again in > > my view the L3VPN and the IPsec VPN are 2 different layers in the > stack > > if they run on the same device. > > I'm not sure I agree with this statement. Let's say you have a BGP VPN > that uses IPsec tunnels between the PEs (which was described in a couple > of expired drafts and can be supported using RFC5566), and then wants to > be able to use dynamic PE to PE IPsec tunnels. Does this fit your "2 > different layer" perspective? > > Either way, I think such usage should be explicitly in scope as it is a > very different model / use case from CE-based IPsec VPNs. > > > Do you see a reason to explicitly > > mention L3VPN in this case? > > I'm open to different ways to cover the above. > > Much thanks, > Lou > > > > Thanks, > > Vishwas > > > > > > > > > I see the 2 working in different > > > layers, and interacting only in edge gateways where both > solutions > > have > > > an edge. > > > > Sure, but the problem exists for both. > > > > Thanks, > > Lou > > > > > > > > > I also have a few more minor comments: > > > > > > I am ok with the minor suggestions you have. > > > > > > Thanks, > > > Vishwas > > > > > > > > > > > > - In section 2.1, you introduce the term "NAT gateway" and > > then later > > > use just "gateway" when I suspect you mean "NAT gateway". I > > suggest > > > using the term "NAT" and thereby not introduce possible > confusion > > > between the gateway term defined in section 1.1 and "NAT > > gateways". > > > > > > - In section 2.2, s/occupies/requires > > > > > > - In sections 2.2, and Section 3.2 you say dynamic > addresses makes > > > static configuration impossible. This doesn't reflect > the use of > > > dynamic dns to handle this issues (and is currently > supported > > by some > > > vendors.) > > > > > > Let me know what you think, > > > Lou > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > > > >> > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > > > > > > From vishwas.ietf@gmail.com Fri Nov 16 10:48:44 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9901321F8AD9 for ; Fri, 16 Nov 2012 10:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYkZRfqFQ9X3 for ; Fri, 16 Nov 2012 10:48:43 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C830321F8AD5 for ; Fri, 16 Nov 2012 10:48:42 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2495222lah.31 for ; Fri, 16 Nov 2012 10:48:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7Tk8AGkyXGfixddHe+Ynw07JYyH2OfXlgubiIXch/6o=; b=AKCCqgbMIbfORrqEZTd351oueaBCmitPHMV6I+btRBhA82Ai++HZnoXrI34pMQUr8l /0zCGmnYgdx8h+/46lITsmPDhb6x1M2cr6q/gjm+bP3+V4wsycnrhX661TTmAG2XkbZ9 LLJCpu15FIGWYWD0aOdtYSC696mo3om5rJmXZm4msZLGNExC6zFdyLoGTTkDhNue6Hi3 HuISS7o/QqH4/bKoVZW1clz8sl5fc9fWIMsvNxJXp9Dc+H7ykhG06xFtJRT8E5XVIbWN h0NTJxfELcz50nkMdtq5AtTh7S98DDKoOOY5rAa4afm8RKC9G+6Ib9fhhNyHHy2az/+E 46zg== MIME-Version: 1.0 Received: by 10.152.133.140 with SMTP id pc12mr5010793lab.53.1353091721492; Fri, 16 Nov 2012 10:48:41 -0800 (PST) Received: by 10.114.75.110 with HTTP; Fri, 16 Nov 2012 10:48:41 -0800 (PST) In-Reply-To: <50A689A9.1090803@labn.net> References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> Date: Fri, 16 Nov 2012 10:48:41 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/alternative; boundary=f46d042dfe99687a1404cea1375a Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:48:44 -0000 --f46d042dfe99687a1404cea1375a Content-Type: text/plain; charset=ISO-8859-1 Hi Lou, Got it. Can you suggest some text for this? I will try to incorporate the same into the document. Thanks, Vishwas On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger wrote: > Vishwas, > Sure, but it's the BGP information that indicates what IPsec > tunnels > are needed / when the SAs get established... > > Again, I just asking for language that points to this use case, not > implementation details. > > Thanks, > Lou > > On 11/16/2012 1:34 PM, Vishwas Manral wrote: > > Hi Lou, > > > >> I'm not sure I agree with this statement. Let's say you have > >> a BGP VPN that uses IPsec tunnels between the PEs (which > >> was described in a couple of expired drafts and can be supported > >> using RFC5566), and then wants to be able to use dynamic PE > >> to PE IPsec tunnels. Does this fit your "2 different layer" > >> perspective? > > IPsec with ADVPN secures the tunnel and creates the mesh underlay on > > need basis/ or automatically. L3VPN creates the overlay, identifies the > > tenant/ customer a packet belongs to and passes the packet on. > > > > Where do we see the need for tighter integration here? Is it allowing > > the ability to create groups of ADVPN instances? > > > > Thanks, > > Vishwas > > > > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger > > wrote: > > > > Vishwas, > > > > Please see below. > > > > On 11/16/2012 12:49 PM, Vishwas Manral wrote: > > > Hi Lou, > > > > > > Thanks for the quick reply. Just a few comments prefixed with a > "VM>": > > > > > > > > > > > We can add something in the lines of additional protocols > > are run over > > > > the IPsec tunnels and the solution should make an effort to > > allow for > > > > additional protocols like OSPF to be run optimally without > > too many > > > > changes in configuration. > > > > > > > > Infact we have a requirement to the effect in section 4.1 > > > > > > yes, this is what I referred to as 4.2 below, and suggested > some > > > replacement text... > > > > > > OK got it. > > > > > > > > > > > Gateways MUST allow tunnel binding, such that > > applications like > > > > Routing using the tunnels can work seamlessly without any > > > updates to > > > > the higher level application configuration i.e. OSPF > > > configuration. > > > > > > > > - In section 4.2, how about: > > > > (replacement text) > > > > 3. Gateways MUST allow for the operation of > > tunneling and > > > > routing protocols operating over spoke-to-spoke IPsec > > Tunnels > > > > with minimal, or no, configuration impact. > > > > > > VM> Ok will specifically specify tunnels and routing protocols. > > > > > > > Great. > > > > > > > > > > > > > > > > > X. The solution SHOULD support BGP/MPLS IP VPNs, see > > > [RFC4364]. > > > > > > > > If you want, you can make the "SHOULD" a "MUST", and > > "support" > > > could be > > > > "be compatible with". > > > > > > > > I do not want to go ahead into details of what other routing > > solutions > > > > it should support. > > > > > > > > With that said I am not sure what you mean by having BGP > > MPLS VPN > > > in an > > > > ADVPN scenario. BGP MPLS VPN is a provider provisioned VPN > > solution, > > > > this is a customer provisioned one. > > > > > > Ahh, interesting point. When I read the document I was > > looking to see > > > if it was scoped purely to CE/customer based solutions. > > Reading section > > > 2 (intro) and 2.2, I saw no such restriction. So I think > > section 2.2 > > > should be explicit on this point either way. Which is why I > > proposed the > > > text "There is also the case when L3VPNs operate over IPsec > > Tunnels." > > > (To explicitly include this case.) If the WG wants this case > > excluded, > > > that's fine too. > > > > > > VM> It is not scoped purely as a CE device scenario, and after > seeing > > > your comment I see no reason to leave that out of scope (though if > I > > > understand your concern better I may feel otherwise). L3VPN can > work > > > over GRE tunnels/ L2TP tunnels, which can themselves use IPsec. > > Again in > > > my view the L3VPN and the IPsec VPN are 2 different layers in the > > stack > > > if they run on the same device. > > > > I'm not sure I agree with this statement. Let's say you have a BGP > VPN > > that uses IPsec tunnels between the PEs (which was described in a > couple > > of expired drafts and can be supported using RFC5566), and then > wants to > > be able to use dynamic PE to PE IPsec tunnels. Does this fit your "2 > > different layer" perspective? > > > > Either way, I think such usage should be explicitly in scope as it > is a > > very different model / use case from CE-based IPsec VPNs. > > > > > Do you see a reason to explicitly > > > mention L3VPN in this case? > > > > I'm open to different ways to cover the above. > > > > Much thanks, > > Lou > > > > > > Thanks, > > > Vishwas > > > > > > > > > > > > > I see the 2 working in different > > > > layers, and interacting only in edge gateways where both > > solutions > > > have > > > > an edge. > > > > > > Sure, but the problem exists for both. > > > > > > Thanks, > > > Lou > > > > > > > > > > > > I also have a few more minor comments: > > > > > > > > I am ok with the minor suggestions you have. > > > > > > > > Thanks, > > > > Vishwas > > > > > > > > > > > > > > > > - In section 2.1, you introduce the term "NAT gateway" > and > > > then later > > > > use just "gateway" when I suspect you mean "NAT > gateway". I > > > suggest > > > > using the term "NAT" and thereby not introduce possible > > confusion > > > > between the gateway term defined in section 1.1 and "NAT > > > gateways". > > > > > > > > - In section 2.2, s/occupies/requires > > > > > > > > - In sections 2.2, and Section 3.2 you say dynamic > > addresses makes > > > > static configuration impossible. This doesn't reflect > > the use of > > > > dynamic dns to handle this issues (and is currently > > supported > > > by some > > > > vendors.) > > > > > > > > Let me know what you think, > > > > Lou > > > > _______________________________________________ > > > > IPsec mailing list > > > > IPsec@ietf.org > > > > > > > > >> > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > > > > > > > > > > > > > > --f46d042dfe99687a1404cea1375a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Lou,

Got it. Can you suggest some text for this? I will try to in= corporate the same into the document.

Thanks,
Vishwas

On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger <lberge= r@labn.net> wrote:
Vishwas,
=A0 =A0 =A0 =A0 Sure, but it's the BGP information that indicates what = IPsec tunnels
are needed / when the SAs get established...

Again, I just asking for language that points to this use case, not
implementation details.

Thanks,
Lou

On 11/16/2012 1:34 PM, Vishwas Manral wrote:
> Hi Lou,
>
>> I'm not sure I agree with this stateme= nt. =A0Let's say you have
>> a BGP VPN that uses IPsec tunnels between the PEs (which
>> was described in a couple of expired drafts and can be supported >> using RFC5566), and then wants to be able to use dynamic PE
>> to PE IPsec tunnels. =A0Does this fit your "2 different layer= "
>> perspective?
> IPsec with ADVPN secures the tunnel and creates the mesh underlay on > need basis/ or automatically. L3VPN creates the overlay, identifies th= e
> tenant/ customer a packet belongs to and passes the packet on.
>
> Where do we see the need for tighter integration here? Is it allowing<= br> > the ability to create groups of ADVPN instances?
>
> Thanks,
> Vishwas
>
> On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>> wrote:
>
> =A0 =A0 Vishwas,
>
> =A0 =A0 Please see below.
>
> =A0 =A0 On 11/16/2012 12:49 PM, Vishwas Manral wrote:
> =A0 =A0 > Hi Lou,
> =A0 =A0 >
> =A0 =A0 > Thanks for the quick reply. Just a few comments prefixed = with a "VM>":
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > We can add something in the lines of additio= nal protocols
> =A0 =A0 are run over
> =A0 =A0 > =A0 =A0 > the IPsec tunnels and the solution should ma= ke an effort to
> =A0 =A0 allow for
> =A0 =A0 > =A0 =A0 > additional protocols like OSPF to be run opt= imally without
> =A0 =A0 too many
> =A0 =A0 > =A0 =A0 > changes in configuration.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > Infact we have a requirement to the effect i= n section 4.1
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 yes, this is what I referred to as 4.2 below, and= suggested some
> =A0 =A0 > =A0 =A0 replacement text...
> =A0 =A0 >
> =A0 =A0 > OK got it.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 Gateways MUST allow tunnel binding, = such that
> =A0 =A0 applications like
> =A0 =A0 > =A0 =A0 > =A0 =A0Routing using the tunnels can work se= amlessly without any
> =A0 =A0 > =A0 =A0 updates to
> =A0 =A0 > =A0 =A0 > =A0 =A0the higher level application configur= ation i.e. =A0OSPF
> =A0 =A0 > =A0 =A0 configuration.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 - In section 4.2, how about:
> =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A0(replacement text)
> =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A03. =A0Gateways MUST allow for= the operation of
> =A0 =A0 tunneling and
> =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A0routing protocols operating o= ver spoke-to-spoke IPsec
> =A0 =A0 Tunnels
> =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A0with minimal, or no, configur= ation impact.
> =A0 =A0 >
> =A0 =A0 > VM> Ok will specifically specify tunnels and routing p= rotocols.
> =A0 =A0 >
>
> =A0 =A0 Great.
>
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A0X. =A0The solution SHOULD sup= port BGP/MPLS IP VPNs, see
> =A0 =A0 > =A0 =A0 [RFC4364].
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 If you want, you can make the "= SHOULD" a "MUST", and
> =A0 =A0 "support"
> =A0 =A0 > =A0 =A0 could be
> =A0 =A0 > =A0 =A0 > =A0 =A0 "be compatible with".
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > I do not want to go ahead into details of wh= at other routing
> =A0 =A0 solutions
> =A0 =A0 > =A0 =A0 > it should support.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > With that said I am not sure what you mean b= y having BGP
> =A0 =A0 MPLS VPN
> =A0 =A0 > =A0 =A0 in an
> =A0 =A0 > =A0 =A0 > ADVPN scenario. BGP MPLS VPN is a provider p= rovisioned VPN
> =A0 =A0 solution,
> =A0 =A0 > =A0 =A0 > this is a customer provisioned one.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Ahh, interesting point. =A0When I read the docume= nt I was
> =A0 =A0 looking to see
> =A0 =A0 > =A0 =A0 if it was scoped purely to CE/customer based solu= tions.
> =A0 =A0 =A0Reading section
> =A0 =A0 > =A0 =A0 2 (intro) and 2.2, I saw no such restriction. =A0= So I think
> =A0 =A0 section 2.2
> =A0 =A0 > =A0 =A0 should be explicit on this point either way. Whic= h is why I
> =A0 =A0 proposed the
> =A0 =A0 > =A0 =A0 text "There is also the case when L3VPNs ope= rate over IPsec
> =A0 =A0 Tunnels."
> =A0 =A0 > =A0 =A0 (To explicitly include this case.) =A0If the WG w= ants this case
> =A0 =A0 excluded,
> =A0 =A0 > =A0 =A0 that's fine too.
> =A0 =A0 >
> =A0 =A0 > VM> It is not scoped purely as a CE device scenario, a= nd after seeing
> =A0 =A0 > your comment I see no reason to leave that out of scope (= though if I
> =A0 =A0 > understand your concern better I may feel otherwise). L3V= PN can work
> =A0 =A0 > over GRE tunnels/ L2TP tunnels, which can themselves use = IPsec.
> =A0 =A0 Again in
> =A0 =A0 > my view the L3VPN and the IPsec VPN are 2 different layer= s in the
> =A0 =A0 stack
> =A0 =A0 > if they run on the same device.
>
> =A0 =A0 I'm not sure I agree with this statement. =A0Let's say= you have a BGP VPN
> =A0 =A0 that uses IPsec tunnels between the PEs (which was described i= n a couple
> =A0 =A0 of expired drafts and can be supported using RFC5566), and the= n wants to
> =A0 =A0 be able to use dynamic PE to PE IPsec tunnels. =A0Does this fi= t your "2
> =A0 =A0 different layer" perspective?
>
> =A0 =A0 Either way, I think such usage should be explicitly in scope a= s it is a
> =A0 =A0 very different model / use case from CE-based IPsec VPNs.
>
> =A0 =A0 > Do you see a reason to explicitly
> =A0 =A0 > mention L3VPN in this case?
>
> =A0 =A0 I'm open to different ways to cover the above.
>
> =A0 =A0 Much thanks,
> =A0 =A0 Lou
> =A0 =A0 >
> =A0 =A0 > Thanks,
> =A0 =A0 > Vishwas
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 > I see the 2 working in different
> =A0 =A0 > =A0 =A0 > layers, and interacting only in edge gateway= s where both
> =A0 =A0 solutions
> =A0 =A0 > =A0 =A0 have
> =A0 =A0 > =A0 =A0 > an edge.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Sure, but the problem exists for both.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Thanks,
> =A0 =A0 > =A0 =A0 Lou
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 I also have a few more minor comment= s:
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > I am ok with the minor suggestions you have.=
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > Thanks,
> =A0 =A0 > =A0 =A0 > Vishwas
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 - In section 2.1, you introduce the = term "NAT gateway" and
> =A0 =A0 > =A0 =A0 then later
> =A0 =A0 > =A0 =A0 > =A0 =A0 use just "gateway" when I = suspect you mean "NAT gateway". =A0I
> =A0 =A0 > =A0 =A0 suggest
> =A0 =A0 > =A0 =A0 > =A0 =A0 using the term "NAT" and t= hereby not introduce possible
> =A0 =A0 confusion
> =A0 =A0 > =A0 =A0 > =A0 =A0 between the gateway term defined in = section 1.1 and "NAT
> =A0 =A0 > =A0 =A0 gateways".
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 - In section 2.2, s/occupies/require= s
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 - In sections 2.2, and Section 3.2 y= ou say dynamic
> =A0 =A0 addresses makes
> =A0 =A0 > =A0 =A0 > =A0 =A0 static configuration impossible. =A0= This doesn't reflect
> =A0 =A0 the use of
> =A0 =A0 > =A0 =A0 > =A0 =A0 dynamic dns to handle this issues (a= nd is currently
> =A0 =A0 supported
> =A0 =A0 > =A0 =A0 by some
> =A0 =A0 > =A0 =A0 > =A0 =A0 vendors.)
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 Let me know what you think,
> =A0 =A0 > =A0 =A0 > =A0 =A0 Lou
> =A0 =A0 > =A0 =A0 > =A0 =A0 ____________________________________= ___________
> =A0 =A0 > =A0 =A0 > =A0 =A0 IPsec mailing list
> =A0 =A0 > =A0 =A0 > =A0 =A0 IP= sec@ietf.org <mailto:IPsec@ietf.or= g>
> =A0 =A0 <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>> > =A0 =A0 <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>
> =A0 =A0 > =A0 =A0 <mailto:IPsec@ietf.org <mailto:IPs= ec@ietf.org>>>
> =A0 =A0 > =A0 =A0 > =A0 =A0 https://www.ietf.org/mailman/listinfo= /ipsec
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 >
>
>

--f46d042dfe99687a1404cea1375a-- From lberger@labn.net Fri Nov 16 11:01:16 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0297C21F8872 for ; Fri, 16 Nov 2012 11:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.82 X-Spam-Level: X-Spam-Status: No, score=-100.82 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pe-lXjzW+PU for ; Fri, 16 Nov 2012 11:01:15 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8-pub.bluehost.com [69.89.22.20]) by ietfa.amsl.com (Postfix) with SMTP id E5F1B21F87E1 for ; Fri, 16 Nov 2012 11:01:14 -0800 (PST) Received: (qmail 8700 invoked by uid 0); 16 Nov 2012 19:00:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 16 Nov 2012 19:00:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=/nU9LYriv8BhjuaXDKyNif40CUyfZlIbcftQCPJclYw=; b=af2zO6H5D06qtZIbopJQcBX1dgQtPSGLlSCBFKWRtyk0B3kIxWJUA0+2ZL/DzmBl8NQ92fnsNGdXZTSsLemDIViHbSVoXPdAvnWtJPf8VQmgkQI4gnxj85g8pFev+Eow; Received: from box313.bluehost.com ([69.89.31.113]:60155 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TZR9e-0000g3-KB; Fri, 16 Nov 2012 12:00:48 -0700 Message-ID: <50A68D30.2040203@labn.net> Date: Fri, 16 Nov 2012 14:00:00 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Vishwas Manral References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 19:01:16 -0000 Vishwas, On 11/16/2012 1:48 PM, Vishwas Manral wrote: > Hi Lou, > > Got it. Can you suggest some text for this? I will try to incorporate > the same into the document. Assuming you don't like my prior attempt: X. The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364]. How about something like: X. The solution MUST support Provider Edge (PE) based VPNs. Note that this phrasing doesn't indicate a specific solutions which is why I now suggest "MUST" vs "SHOULD". Lou > > Thanks, > Vishwas > > On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger > wrote: > > Vishwas, > Sure, but it's the BGP information that indicates what IPsec > tunnels > are needed / when the SAs get established... > > Again, I just asking for language that points to this use case, not > implementation details. > > Thanks, > Lou > > On 11/16/2012 1:34 PM, Vishwas Manral wrote: > > Hi Lou, > > > >> I'm not sure I agree with this statement. Let's say you have > >> a BGP VPN that uses IPsec tunnels between the PEs (which > >> was described in a couple of expired drafts and can be supported > >> using RFC5566), and then wants to be able to use dynamic PE > >> to PE IPsec tunnels. Does this fit your "2 different layer" > >> perspective? > > IPsec with ADVPN secures the tunnel and creates the mesh underlay on > > need basis/ or automatically. L3VPN creates the overlay, > identifies the > > tenant/ customer a packet belongs to and passes the packet on. > > > > Where do we see the need for tighter integration here? Is it allowing > > the ability to create groups of ADVPN instances? > > > > Thanks, > > Vishwas > > > > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger > > >> wrote: > > > > Vishwas, > > > > Please see below. > > > > On 11/16/2012 12:49 PM, Vishwas Manral wrote: > > > Hi Lou, > > > > > > Thanks for the quick reply. Just a few comments prefixed > with a "VM>": > > > > > > > > > > > We can add something in the lines of additional protocols > > are run over > > > > the IPsec tunnels and the solution should make an > effort to > > allow for > > > > additional protocols like OSPF to be run optimally without > > too many > > > > changes in configuration. > > > > > > > > Infact we have a requirement to the effect in section 4.1 > > > > > > yes, this is what I referred to as 4.2 below, and > suggested some > > > replacement text... > > > > > > OK got it. > > > > > > > > > > > Gateways MUST allow tunnel binding, such that > > applications like > > > > Routing using the tunnels can work seamlessly > without any > > > updates to > > > > the higher level application configuration i.e. OSPF > > > configuration. > > > > > > > > - In section 4.2, how about: > > > > (replacement text) > > > > 3. Gateways MUST allow for the operation of > > tunneling and > > > > routing protocols operating over spoke-to-spoke > IPsec > > Tunnels > > > > with minimal, or no, configuration impact. > > > > > > VM> Ok will specifically specify tunnels and routing protocols. > > > > > > > Great. > > > > > > > > > > > > > > > > > X. The solution SHOULD support BGP/MPLS IP > VPNs, see > > > [RFC4364]. > > > > > > > > If you want, you can make the "SHOULD" a "MUST", and > > "support" > > > could be > > > > "be compatible with". > > > > > > > > I do not want to go ahead into details of what other > routing > > solutions > > > > it should support. > > > > > > > > With that said I am not sure what you mean by having BGP > > MPLS VPN > > > in an > > > > ADVPN scenario. BGP MPLS VPN is a provider provisioned VPN > > solution, > > > > this is a customer provisioned one. > > > > > > Ahh, interesting point. When I read the document I was > > looking to see > > > if it was scoped purely to CE/customer based solutions. > > Reading section > > > 2 (intro) and 2.2, I saw no such restriction. So I think > > section 2.2 > > > should be explicit on this point either way. Which is why I > > proposed the > > > text "There is also the case when L3VPNs operate over IPsec > > Tunnels." > > > (To explicitly include this case.) If the WG wants this > case > > excluded, > > > that's fine too. > > > > > > VM> It is not scoped purely as a CE device scenario, and > after seeing > > > your comment I see no reason to leave that out of scope > (though if I > > > understand your concern better I may feel otherwise). L3VPN > can work > > > over GRE tunnels/ L2TP tunnels, which can themselves use IPsec. > > Again in > > > my view the L3VPN and the IPsec VPN are 2 different layers > in the > > stack > > > if they run on the same device. > > > > I'm not sure I agree with this statement. Let's say you have > a BGP VPN > > that uses IPsec tunnels between the PEs (which was described > in a couple > > of expired drafts and can be supported using RFC5566), and > then wants to > > be able to use dynamic PE to PE IPsec tunnels. Does this fit > your "2 > > different layer" perspective? > > > > Either way, I think such usage should be explicitly in scope > as it is a > > very different model / use case from CE-based IPsec VPNs. > > > > > Do you see a reason to explicitly > > > mention L3VPN in this case? > > > > I'm open to different ways to cover the above. > > > > Much thanks, > > Lou > > > > > > Thanks, > > > Vishwas > > > > > > > > > > > > > I see the 2 working in different > > > > layers, and interacting only in edge gateways where both > > solutions > > > have > > > > an edge. > > > > > > Sure, but the problem exists for both. > > > > > > Thanks, > > > Lou > > > > > > > > > > > > I also have a few more minor comments: > > > > > > > > I am ok with the minor suggestions you have. > > > > > > > > Thanks, > > > > Vishwas > > > > > > > > > > > > > > > > - In section 2.1, you introduce the term "NAT > gateway" and > > > then later > > > > use just "gateway" when I suspect you mean "NAT > gateway". I > > > suggest > > > > using the term "NAT" and thereby not introduce > possible > > confusion > > > > between the gateway term defined in section 1.1 > and "NAT > > > gateways". > > > > > > > > - In section 2.2, s/occupies/requires > > > > > > > > - In sections 2.2, and Section 3.2 you say dynamic > > addresses makes > > > > static configuration impossible. This doesn't reflect > > the use of > > > > dynamic dns to handle this issues (and is currently > > supported > > > by some > > > > vendors.) > > > > > > > > Let me know what you think, > > > > Lou > > > > _______________________________________________ > > > > IPsec mailing list > > > > IPsec@ietf.org > > > > > >> > > > > > > > > >>> > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > > > > > > > > > > > > > > > From vishwas.ietf@gmail.com Fri Nov 16 11:10:57 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A04921F8A67 for ; Fri, 16 Nov 2012 11:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PReBDlbHMaxZ for ; Fri, 16 Nov 2012 11:10:56 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47F9521F85FC for ; Fri, 16 Nov 2012 11:10:55 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so2587737lbk.31 for ; Fri, 16 Nov 2012 11:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x7kOKukCFAMtsT7FxvPZh7XQb7jmT5f1oZUL+Paj4SY=; b=stvlz3wwQllKWwWmnppgcWCt6u380TMn9K4bXdB9QueCEazLPpXwupJ5RLD/sl8cq6 7IizZQnOa+SAQboffnDBSPfyCpysTG6Ywl1rroyN7nffp2TUz25PBQg1+nP7//6F6zK1 /p/ukGrP0/gcJqhs0KtX5ved52ha5BlhhLMmUPMTrD11oyfn5UqN47DIGfXPFedhRngM AoIiuA1GlZkN3RA0PPjIYPx8rSHCFYh/wr7HWov5Awb1aT9GjLWLckqXI4MALWoxsTrq d84TTOV5/SfVdphojmnzM9pMqZjBPMiyBKarO12FE8Ouj7acookqgXNigPy5DS3ggpBn SSEQ== MIME-Version: 1.0 Received: by 10.152.104.240 with SMTP id gh16mr5168863lab.56.1353093054080; Fri, 16 Nov 2012 11:10:54 -0800 (PST) Received: by 10.114.75.110 with HTTP; Fri, 16 Nov 2012 11:10:54 -0800 (PST) In-Reply-To: <50A68D30.2040203@labn.net> References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> Date: Fri, 16 Nov 2012 11:10:54 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/alternative; boundary=f46d04088e11d6272604cea186a5 Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 19:10:57 -0000 --f46d04088e11d6272604cea186a5 Content-Type: text/plain; charset=ISO-8859-1 Thanks Lou, Let me heard back from the WG on this, if they have any opinion. If not we can go ahead with your suggestion. -Vishwas On Fri, Nov 16, 2012 at 11:00 AM, Lou Berger wrote: > Vishwas, > > On 11/16/2012 1:48 PM, Vishwas Manral wrote: > > Hi Lou, > > > > Got it. Can you suggest some text for this? I will try to incorporate > > the same into the document. > > Assuming you don't like my prior attempt: > X. The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364]. > > How about something like: > X. The solution MUST support Provider Edge (PE) based VPNs. > > Note that this phrasing doesn't indicate a specific solutions which is > why I now suggest "MUST" vs "SHOULD". > > Lou > > > > > Thanks, > > Vishwas > > > > On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger > > wrote: > > > > Vishwas, > > Sure, but it's the BGP information that indicates what IPsec > > tunnels > > are needed / when the SAs get established... > > > > Again, I just asking for language that points to this use case, not > > implementation details. > > > > Thanks, > > Lou > > > > On 11/16/2012 1:34 PM, Vishwas Manral wrote: > > > Hi Lou, > > > > > >> I'm not sure I agree with this statement. Let's say you have > > >> a BGP VPN that uses IPsec tunnels between the PEs (which > > >> was described in a couple of expired drafts and can be supported > > >> using RFC5566), and then wants to be able to use dynamic PE > > >> to PE IPsec tunnels. Does this fit your "2 different layer" > > >> perspective? > > > IPsec with ADVPN secures the tunnel and creates the mesh underlay > on > > > need basis/ or automatically. L3VPN creates the overlay, > > identifies the > > > tenant/ customer a packet belongs to and passes the packet on. > > > > > > Where do we see the need for tighter integration here? Is it > allowing > > > the ability to create groups of ADVPN instances? > > > > > > Thanks, > > > Vishwas > > > > > > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger > > > > >> wrote: > > > > > > Vishwas, > > > > > > Please see below. > > > > > > On 11/16/2012 12:49 PM, Vishwas Manral wrote: > > > > Hi Lou, > > > > > > > > Thanks for the quick reply. Just a few comments prefixed > > with a "VM>": > > > > > > > > > > > > > > We can add something in the lines of additional > protocols > > > are run over > > > > > the IPsec tunnels and the solution should make an > > effort to > > > allow for > > > > > additional protocols like OSPF to be run optimally > without > > > too many > > > > > changes in configuration. > > > > > > > > > > Infact we have a requirement to the effect in section > 4.1 > > > > > > > > yes, this is what I referred to as 4.2 below, and > > suggested some > > > > replacement text... > > > > > > > > OK got it. > > > > > > > > > > > > > > Gateways MUST allow tunnel binding, such that > > > applications like > > > > > Routing using the tunnels can work seamlessly > > without any > > > > updates to > > > > > the higher level application configuration i.e. > OSPF > > > > configuration. > > > > > > > > > > - In section 4.2, how about: > > > > > (replacement text) > > > > > 3. Gateways MUST allow for the operation of > > > tunneling and > > > > > routing protocols operating over spoke-to-spoke > > IPsec > > > Tunnels > > > > > with minimal, or no, configuration impact. > > > > > > > > VM> Ok will specifically specify tunnels and routing > protocols. > > > > > > > > > > Great. > > > > > > > > > > > > > > > > > > > > > > X. The solution SHOULD support BGP/MPLS IP > > VPNs, see > > > > [RFC4364]. > > > > > > > > > > If you want, you can make the "SHOULD" a "MUST", > and > > > "support" > > > > could be > > > > > "be compatible with". > > > > > > > > > > I do not want to go ahead into details of what other > > routing > > > solutions > > > > > it should support. > > > > > > > > > > With that said I am not sure what you mean by having > BGP > > > MPLS VPN > > > > in an > > > > > ADVPN scenario. BGP MPLS VPN is a provider provisioned > VPN > > > solution, > > > > > this is a customer provisioned one. > > > > > > > > Ahh, interesting point. When I read the document I was > > > looking to see > > > > if it was scoped purely to CE/customer based solutions. > > > Reading section > > > > 2 (intro) and 2.2, I saw no such restriction. So I think > > > section 2.2 > > > > should be explicit on this point either way. Which is > why I > > > proposed the > > > > text "There is also the case when L3VPNs operate over > IPsec > > > Tunnels." > > > > (To explicitly include this case.) If the WG wants this > > case > > > excluded, > > > > that's fine too. > > > > > > > > VM> It is not scoped purely as a CE device scenario, and > > after seeing > > > > your comment I see no reason to leave that out of scope > > (though if I > > > > understand your concern better I may feel otherwise). L3VPN > > can work > > > > over GRE tunnels/ L2TP tunnels, which can themselves use > IPsec. > > > Again in > > > > my view the L3VPN and the IPsec VPN are 2 different layers > > in the > > > stack > > > > if they run on the same device. > > > > > > I'm not sure I agree with this statement. Let's say you have > > a BGP VPN > > > that uses IPsec tunnels between the PEs (which was described > > in a couple > > > of expired drafts and can be supported using RFC5566), and > > then wants to > > > be able to use dynamic PE to PE IPsec tunnels. Does this fit > > your "2 > > > different layer" perspective? > > > > > > Either way, I think such usage should be explicitly in scope > > as it is a > > > very different model / use case from CE-based IPsec VPNs. > > > > > > > Do you see a reason to explicitly > > > > mention L3VPN in this case? > > > > > > I'm open to different ways to cover the above. > > > > > > Much thanks, > > > Lou > > > > > > > > Thanks, > > > > Vishwas > > > > > > > > > > > > > > > > > I see the 2 working in different > > > > > layers, and interacting only in edge gateways where > both > > > solutions > > > > have > > > > > an edge. > > > > > > > > Sure, but the problem exists for both. > > > > > > > > Thanks, > > > > Lou > > > > > > > > > > > > > > > I also have a few more minor comments: > > > > > > > > > > I am ok with the minor suggestions you have. > > > > > > > > > > Thanks, > > > > > Vishwas > > > > > > > > > > > > > > > > > > > > - In section 2.1, you introduce the term "NAT > > gateway" and > > > > then later > > > > > use just "gateway" when I suspect you mean "NAT > > gateway". I > > > > suggest > > > > > using the term "NAT" and thereby not introduce > > possible > > > confusion > > > > > between the gateway term defined in section 1.1 > > and "NAT > > > > gateways". > > > > > > > > > > - In section 2.2, s/occupies/requires > > > > > > > > > > - In sections 2.2, and Section 3.2 you say dynamic > > > addresses makes > > > > > static configuration impossible. This doesn't > reflect > > > the use of > > > > > dynamic dns to handle this issues (and is currently > > > supported > > > > by some > > > > > vendors.) > > > > > > > > > > Let me know what you think, > > > > > Lou > > > > > _______________________________________________ > > > > > IPsec mailing list > > > > > IPsec@ietf.org > > > > > > > > >> > > > > > > > > > > > > >>> > > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --f46d04088e11d6272604cea186a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Lou,

Let me heard back from the WG on this, if they have any = opinion. If not we can go ahead with your suggestion.

-Vishwas
On Fri, Nov 16, 2012 at 11:00 AM, Lou Berger <= span dir=3D"ltr"><= lberger@labn.net> wrote:
Vishwas,

On 11/16/2012 1:48 PM, Vishwas Manral wrote:
> Hi Lou,
>
> Got it. Can you suggest some text for this? I = will try to incorporate
> the same into the document.

Assuming you don't like my prior attempt:
X. =A0The solution SHOULD support BGP/MPLS IP VPNs, see [= RFC4364].

How about something like:
X. The solution MUST support Provider Edge (PE) based VPNs.

Note that this phrasing doesn't indicate a specific solutions which is<= br> why I now suggest "MUST" vs "SHOULD".

Lou

>
> Thanks,
> Vishwas
>
> On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>> wrote:
>
> =A0 =A0 Vishwas,
> =A0 =A0 =A0 =A0 =A0 =A0 Sure, but it's the BGP information that in= dicates what IPsec
> =A0 =A0 tunnels
> =A0 =A0 are needed / when the SAs get established...
>
> =A0 =A0 Again, I just asking for language that points to this use case= , not
> =A0 =A0 implementation details.
>
> =A0 =A0 Thanks,
> =A0 =A0 Lou
>
> =A0 =A0 On 11/16/2012 1:34 PM, Vishwas Manral wrote:
> =A0 =A0 > Hi Lou,
> =A0 =A0 >
> =A0 =A0 >> I'm not sure I agree with this statement. =A0Let&= #39;s say you have
> =A0 =A0 >> a BGP VPN that uses IPsec tunnels between the PEs (wh= ich
> =A0 =A0 >> was described in a couple of expired drafts and can b= e supported
> =A0 =A0 >> using RFC5566), and then wants to be able to use dyna= mic PE
> =A0 =A0 >> to PE IPsec tunnels. =A0Does this fit your "2 di= fferent layer"
> =A0 =A0 >> perspective?
> =A0 =A0 > IPsec with ADVPN secures the tunnel and creates the mesh = underlay on
> =A0 =A0 > need basis/ or automatically. L3VPN creates the overlay,<= br> > =A0 =A0 identifies the
> =A0 =A0 > tenant/ customer a packet belongs to and passes the packe= t on.
> =A0 =A0 >
> =A0 =A0 > Where do we see the need for tighter integration here? Is= it allowing
> =A0 =A0 > the ability to create groups of ADVPN instances?
> =A0 =A0 >
> =A0 =A0 > Thanks,
> =A0 =A0 > Vishwas
> =A0 =A0 >
> =A0 =A0 > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger <lberger@labn.net
> =A0 =A0 <mailto:lberger@labn.ne= t>
> =A0 =A0 > <mailto:lberger@labn.net <mailto:lberger@labn.net>>> wrote:
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Vishwas,
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Please see below.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 On 11/16/2012 12:49 PM, Vishwas Manral wrote:
> =A0 =A0 > =A0 =A0 > Hi Lou,
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > Thanks for the quick reply. Just a few comme= nts prefixed
> =A0 =A0 with a "VM>":
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > We can add something in the lin= es of additional protocols
> =A0 =A0 > =A0 =A0 are run over
> =A0 =A0 > =A0 =A0 > =A0 =A0 > the IPsec tunnels and the solut= ion should make an
> =A0 =A0 effort to
> =A0 =A0 > =A0 =A0 allow for
> =A0 =A0 > =A0 =A0 > =A0 =A0 > additional protocols like OSPF = to be run optimally without
> =A0 =A0 > =A0 =A0 too many
> =A0 =A0 > =A0 =A0 > =A0 =A0 > changes in configuration.
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > Infact we have a requirement to= the effect in section 4.1
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 yes, this is what I referred to as 4= .2 below, and
> =A0 =A0 suggested some
> =A0 =A0 > =A0 =A0 > =A0 =A0 replacement text...
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > OK got it.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 Gateways MUST allow tun= nel binding, such that
> =A0 =A0 > =A0 =A0 applications like
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0Routing using the tunnel= s can work seamlessly
> =A0 =A0 without any
> =A0 =A0 > =A0 =A0 > =A0 =A0 updates to
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0the higher level applica= tion configuration i.e. =A0OSPF
> =A0 =A0 > =A0 =A0 > =A0 =A0 configuration.
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 - In section 4.2, how a= bout:
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A0(replacement tex= t)
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A03. =A0Gateways M= UST allow for the operation of
> =A0 =A0 > =A0 =A0 tunneling and
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A0routing protocol= s operating over spoke-to-spoke
> =A0 =A0 IPsec
> =A0 =A0 > =A0 =A0 Tunnels
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A0with minimal, or= no, configuration impact.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > VM> Ok will specifically specify tunnels = and routing protocols.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Great.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A0X. =A0The soluti= on SHOULD support BGP/MPLS IP
> =A0 =A0 VPNs, see
> =A0 =A0 > =A0 =A0 > =A0 =A0 [RFC4364].
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 If you want, you can ma= ke the "SHOULD" a "MUST", and
> =A0 =A0 > =A0 =A0 "support"
> =A0 =A0 > =A0 =A0 > =A0 =A0 could be
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 "be compatible wit= h".
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > I do not want to go ahead into = details of what other
> =A0 =A0 routing
> =A0 =A0 > =A0 =A0 solutions
> =A0 =A0 > =A0 =A0 > =A0 =A0 > it should support.
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > With that said I am not sure wh= at you mean by having BGP
> =A0 =A0 > =A0 =A0 MPLS VPN
> =A0 =A0 > =A0 =A0 > =A0 =A0 in an
> =A0 =A0 > =A0 =A0 > =A0 =A0 > ADVPN scenario. BGP MPLS VPN is= a provider provisioned VPN
> =A0 =A0 > =A0 =A0 solution,
> =A0 =A0 > =A0 =A0 > =A0 =A0 > this is a customer provisioned = one.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 Ahh, interesting point. =A0When I re= ad the document I was
> =A0 =A0 > =A0 =A0 looking to see
> =A0 =A0 > =A0 =A0 > =A0 =A0 if it was scoped purely to CE/custom= er based solutions.
> =A0 =A0 > =A0 =A0 =A0Reading section
> =A0 =A0 > =A0 =A0 > =A0 =A0 2 (intro) and 2.2, I saw no such res= triction. =A0So I think
> =A0 =A0 > =A0 =A0 section 2.2
> =A0 =A0 > =A0 =A0 > =A0 =A0 should be explicit on this point eit= her way. Which is why I
> =A0 =A0 > =A0 =A0 proposed the
> =A0 =A0 > =A0 =A0 > =A0 =A0 text "There is also the case wh= en L3VPNs operate over IPsec
> =A0 =A0 > =A0 =A0 Tunnels."
> =A0 =A0 > =A0 =A0 > =A0 =A0 (To explicitly include this case.) = =A0If the WG wants this
> =A0 =A0 case
> =A0 =A0 > =A0 =A0 excluded,
> =A0 =A0 > =A0 =A0 > =A0 =A0 that's fine too.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > VM> It is not scoped purely as a CE devic= e scenario, and
> =A0 =A0 after seeing
> =A0 =A0 > =A0 =A0 > your comment I see no reason to leave that o= ut of scope
> =A0 =A0 (though if I
> =A0 =A0 > =A0 =A0 > understand your concern better I may feel ot= herwise). L3VPN
> =A0 =A0 can work
> =A0 =A0 > =A0 =A0 > over GRE tunnels/ L2TP tunnels, which can th= emselves use IPsec.
> =A0 =A0 > =A0 =A0 Again in
> =A0 =A0 > =A0 =A0 > my view the L3VPN and the IPsec VPN are 2 di= fferent layers
> =A0 =A0 in the
> =A0 =A0 > =A0 =A0 stack
> =A0 =A0 > =A0 =A0 > if they run on the same device.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 I'm not sure I agree with this statement. =A0= Let's say you have
> =A0 =A0 a BGP VPN
> =A0 =A0 > =A0 =A0 that uses IPsec tunnels between the PEs (which wa= s described
> =A0 =A0 in a couple
> =A0 =A0 > =A0 =A0 of expired drafts and can be supported using RFC5= 566), and
> =A0 =A0 then wants to
> =A0 =A0 > =A0 =A0 be able to use dynamic PE to PE IPsec tunnels. = =A0Does this fit
> =A0 =A0 your "2
> =A0 =A0 > =A0 =A0 different layer" perspective?
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Either way, I think such usage should be explicit= ly in scope
> =A0 =A0 as it is a
> =A0 =A0 > =A0 =A0 very different model / use case from CE-based IPs= ec VPNs.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 > Do you see a reason to explicitly
> =A0 =A0 > =A0 =A0 > mention L3VPN in this case?
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 I'm open to different ways to cover the above= .
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Much thanks,
> =A0 =A0 > =A0 =A0 Lou
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > Thanks,
> =A0 =A0 > =A0 =A0 > Vishwas
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > I see the 2 working in differen= t
> =A0 =A0 > =A0 =A0 > =A0 =A0 > layers, and interacting only in= edge gateways where both
> =A0 =A0 > =A0 =A0 solutions
> =A0 =A0 > =A0 =A0 > =A0 =A0 have
> =A0 =A0 > =A0 =A0 > =A0 =A0 > an edge.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 Sure, but the problem exists for bot= h.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 Thanks,
> =A0 =A0 > =A0 =A0 > =A0 =A0 Lou
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 I also have a few more = minor comments:
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > I am ok with the minor suggesti= ons you have.
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > Thanks,
> =A0 =A0 > =A0 =A0 > =A0 =A0 > Vishwas
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 - In section 2.1, you i= ntroduce the term "NAT
> =A0 =A0 gateway" and
> =A0 =A0 > =A0 =A0 > =A0 =A0 then later
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 use just "gateway&= quot; when I suspect you mean "NAT
> =A0 =A0 gateway". =A0I
> =A0 =A0 > =A0 =A0 > =A0 =A0 suggest
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 using the term "NA= T" and thereby not introduce
> =A0 =A0 possible
> =A0 =A0 > =A0 =A0 confusion
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 between the gateway ter= m defined in section 1.1
> =A0 =A0 and "NAT
> =A0 =A0 > =A0 =A0 > =A0 =A0 gateways".
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 - In section 2.2, s/occ= upies/requires
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 - In sections 2.2, and = Section 3.2 you say dynamic
> =A0 =A0 > =A0 =A0 addresses makes
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 static configuration im= possible. =A0This doesn't reflect
> =A0 =A0 > =A0 =A0 the use of
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 dynamic dns to handle t= his issues (and is currently
> =A0 =A0 > =A0 =A0 supported
> =A0 =A0 > =A0 =A0 > =A0 =A0 by some
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 vendors.)
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 Let me know what you th= ink,
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 Lou
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 _______________________= ________________________
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 IPsec mailing list
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 IPsec@ietf.org <mailto:= IPsec@ietf.org>
> =A0 =A0 <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>> > =A0 =A0 > =A0 =A0 <mailto:IPse= c@ietf.org <mailto:IPsec@ietf.org<= /a>>
> =A0 =A0 <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>&g= t;
> =A0 =A0 > =A0 =A0 <mailto:IPse= c@ietf.org <mailto:IPsec@ietf.org<= /a>>
> =A0 =A0 <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>> > =A0 =A0 > =A0 =A0 > =A0 =A0 <mailto:IPsec@ietf.org <mailto:IP= sec@ietf.org>
> =A0 =A0 <mailto:IPsec= @ietf.org <mailto:IPsec@ietf.org>>>>
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 https://www.ietf.org/mai= lman/listinfo/ipsec
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 >
>
>

--f46d04088e11d6272604cea186a5-- From lberger@labn.net Fri Nov 16 11:17:31 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532A521F8AD2 for ; Fri, 16 Nov 2012 11:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.12 X-Spam-Level: X-Spam-Status: No, score=-100.12 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETBlmHJJbPpp for ; Fri, 16 Nov 2012 11:17:30 -0800 (PST) Received: from oproxy12-pub.bluehost.com (50-87-16-10.unifiedlayer.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id D2DA521F8745 for ; Fri, 16 Nov 2012 11:17:29 -0800 (PST) Received: (qmail 4801 invoked by uid 0); 16 Nov 2012 19:17:07 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 16 Nov 2012 19:17:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=S61cxsgOEDQq5cRjfDt2ZGcmodUCT88xQQ92jCxDxuA=; b=kyP1JkbahaDcK8SswvvZYJ970qSwU2QafL89Ty7WZm5u1ov9FvROk0QEQjSBxFBmRHv4xr2fhLDiNvWLrVYzZITes4YpOFgoWxniXZGXr55IiZ8ZUCMzjCVYiZFfQeas; Received: from box313.bluehost.com ([69.89.31.113]:33586 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1TZRPV-0000sp-Em; Fri, 16 Nov 2012 12:17:07 -0700 Message-ID: <50A69122.2000402@labn.net> Date: Fri, 16 Nov 2012 14:16:50 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Vishwas Manral References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 19:17:31 -0000 Sounds like a plan. Thanks for the quick response(s). Lou On 11/16/2012 2:10 PM, Vishwas Manral wrote: > Thanks Lou, > > Let me heard back from the WG on this, if they have any opinion. If not > we can go ahead with your suggestion. > > -Vishwas > > On Fri, Nov 16, 2012 at 11:00 AM, Lou Berger > wrote: > > Vishwas, > > On 11/16/2012 1:48 PM, Vishwas Manral wrote: > > Hi Lou, > > > > Got it. Can you suggest some text for this? I will try to incorporate > > the same into the document. > > Assuming you don't like my prior attempt: > X. The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364]. > > How about something like: > X. The solution MUST support Provider Edge (PE) based VPNs. > > Note that this phrasing doesn't indicate a specific solutions which is > why I now suggest "MUST" vs "SHOULD". > > Lou > > > > > Thanks, > > Vishwas > > > > On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger > > >> wrote: > > > > Vishwas, > > Sure, but it's the BGP information that indicates what > IPsec > > tunnels > > are needed / when the SAs get established... > > > > Again, I just asking for language that points to this use > case, not > > implementation details. > > > > Thanks, > > Lou > > > > On 11/16/2012 1:34 PM, Vishwas Manral wrote: > > > Hi Lou, > > > > > >> I'm not sure I agree with this statement. Let's say you have > > >> a BGP VPN that uses IPsec tunnels between the PEs (which > > >> was described in a couple of expired drafts and can be > supported > > >> using RFC5566), and then wants to be able to use dynamic PE > > >> to PE IPsec tunnels. Does this fit your "2 different layer" > > >> perspective? > > > IPsec with ADVPN secures the tunnel and creates the mesh > underlay on > > > need basis/ or automatically. L3VPN creates the overlay, > > identifies the > > > tenant/ customer a packet belongs to and passes the packet on. > > > > > > Where do we see the need for tighter integration here? Is it > allowing > > > the ability to create groups of ADVPN instances? > > > > > > Thanks, > > > Vishwas > > > > > > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger > > > > > > > > >>> wrote: > > > > > > Vishwas, > > > > > > Please see below. > > > > > > On 11/16/2012 12:49 PM, Vishwas Manral wrote: > > > > Hi Lou, > > > > > > > > Thanks for the quick reply. Just a few comments prefixed > > with a "VM>": > > > > > > > > > > > > > > We can add something in the lines of additional > protocols > > > are run over > > > > > the IPsec tunnels and the solution should make an > > effort to > > > allow for > > > > > additional protocols like OSPF to be run > optimally without > > > too many > > > > > changes in configuration. > > > > > > > > > > Infact we have a requirement to the effect in > section 4.1 > > > > > > > > yes, this is what I referred to as 4.2 below, and > > suggested some > > > > replacement text... > > > > > > > > OK got it. > > > > > > > > > > > > > > Gateways MUST allow tunnel binding, such that > > > applications like > > > > > Routing using the tunnels can work seamlessly > > without any > > > > updates to > > > > > the higher level application configuration > i.e. OSPF > > > > configuration. > > > > > > > > > > - In section 4.2, how about: > > > > > (replacement text) > > > > > 3. Gateways MUST allow for the operation of > > > tunneling and > > > > > routing protocols operating over > spoke-to-spoke > > IPsec > > > Tunnels > > > > > with minimal, or no, configuration impact. > > > > > > > > VM> Ok will specifically specify tunnels and routing > protocols. > > > > > > > > > > Great. > > > > > > > > > > > > > > > > > > > > > > X. The solution SHOULD support BGP/MPLS IP > > VPNs, see > > > > [RFC4364]. > > > > > > > > > > If you want, you can make the "SHOULD" a > "MUST", and > > > "support" > > > > could be > > > > > "be compatible with". > > > > > > > > > > I do not want to go ahead into details of what other > > routing > > > solutions > > > > > it should support. > > > > > > > > > > With that said I am not sure what you mean by > having BGP > > > MPLS VPN > > > > in an > > > > > ADVPN scenario. BGP MPLS VPN is a provider > provisioned VPN > > > solution, > > > > > this is a customer provisioned one. > > > > > > > > Ahh, interesting point. When I read the document > I was > > > looking to see > > > > if it was scoped purely to CE/customer based > solutions. > > > Reading section > > > > 2 (intro) and 2.2, I saw no such restriction. So > I think > > > section 2.2 > > > > should be explicit on this point either way. Which > is why I > > > proposed the > > > > text "There is also the case when L3VPNs operate > over IPsec > > > Tunnels." > > > > (To explicitly include this case.) If the WG > wants this > > case > > > excluded, > > > > that's fine too. > > > > > > > > VM> It is not scoped purely as a CE device scenario, and > > after seeing > > > > your comment I see no reason to leave that out of scope > > (though if I > > > > understand your concern better I may feel otherwise). > L3VPN > > can work > > > > over GRE tunnels/ L2TP tunnels, which can themselves > use IPsec. > > > Again in > > > > my view the L3VPN and the IPsec VPN are 2 different layers > > in the > > > stack > > > > if they run on the same device. > > > > > > I'm not sure I agree with this statement. Let's say you > have > > a BGP VPN > > > that uses IPsec tunnels between the PEs (which was described > > in a couple > > > of expired drafts and can be supported using RFC5566), and > > then wants to > > > be able to use dynamic PE to PE IPsec tunnels. Does > this fit > > your "2 > > > different layer" perspective? > > > > > > Either way, I think such usage should be explicitly in scope > > as it is a > > > very different model / use case from CE-based IPsec VPNs. > > > > > > > Do you see a reason to explicitly > > > > mention L3VPN in this case? > > > > > > I'm open to different ways to cover the above. > > > > > > Much thanks, > > > Lou > > > > > > > > Thanks, > > > > Vishwas > > > > > > > > > > > > > > > > > I see the 2 working in different > > > > > layers, and interacting only in edge gateways > where both > > > solutions > > > > have > > > > > an edge. > > > > > > > > Sure, but the problem exists for both. > > > > > > > > Thanks, > > > > Lou > > > > > > > > > > > > > > > I also have a few more minor comments: > > > > > > > > > > I am ok with the minor suggestions you have. > > > > > > > > > > Thanks, > > > > > Vishwas > > > > > > > > > > > > > > > > > > > > - In section 2.1, you introduce the term "NAT > > gateway" and > > > > then later > > > > > use just "gateway" when I suspect you mean "NAT > > gateway". I > > > > suggest > > > > > using the term "NAT" and thereby not introduce > > possible > > > confusion > > > > > between the gateway term defined in section 1.1 > > and "NAT > > > > gateways". > > > > > > > > > > - In section 2.2, s/occupies/requires > > > > > > > > > > - In sections 2.2, and Section 3.2 you say > dynamic > > > addresses makes > > > > > static configuration impossible. This > doesn't reflect > > > the use of > > > > > dynamic dns to handle this issues (and is > currently > > > supported > > > > by some > > > > > vendors.) > > > > > > > > > > Let me know what you think, > > > > > Lou > > > > > _______________________________________________ > > > > > IPsec mailing list > > > > > IPsec@ietf.org > > > > > >> > > > > > > > > >>> > > > > > > > > >> > > > > > > > > > >>>> > > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From liushucheng@huawei.com Fri Nov 23 17:41:51 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C205721F8613 for ; Fri, 23 Nov 2012 17:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EONDKkF8HaxH for ; Fri, 23 Nov 2012 17:41:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7907721F8612 for ; Fri, 23 Nov 2012 17:41:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANC10191; Sat, 24 Nov 2012 01:41:47 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 24 Nov 2012 01:41:05 +0000 Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 24 Nov 2012 09:41:44 +0800 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.70]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.01.0323.003; Sat, 24 Nov 2012 09:41:41 +0800 From: "Will Liu (Shucheng)" To: Paul Hoffman Thread-Topic: [IPsec] Minutes from Atlanta meeting Thread-Index: AQHNwUgvOVhM31rHcEyIE2M0mKqiC5f4Rr4w Date: Sat, 24 Nov 2012 01:41:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.79.177] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPsecme WG Subject: Re: [IPsec] Minutes from Atlanta meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 01:41:51 -0000 Thanks for your efforts.=20 Btw, is there a voice recording for IPsec session? Will > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Tuesday, November 13, 2012 10:40 AM > To: IPsecme WG > Subject: [IPsec] Minutes from Atlanta meeting >=20 > Carl Wallace did a fine job of taking minutes. I cleaned them up just a t= ad; > they are at > . >=20 > Please send corrections *only* for things that are wrong in the minutes. = If > you want to discuss a topic from the minutes, please start a new thread. > Thanks in advance! >=20 > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From joelja@bogus.com Fri Nov 23 17:57:43 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897EE21F867C for ; Fri, 23 Nov 2012 17:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wa8I2U+INrju for ; Fri, 23 Nov 2012 17:57:43 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 16A5A21F866C for ; Fri, 23 Nov 2012 17:57:43 -0800 (PST) Received: from joels-MacBook-Air.local (c-71-193-176-225.hsd1.wa.comcast.net [71.193.176.225]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id qAO1urJm084789 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 24 Nov 2012 01:56:54 GMT (envelope-from joelja@bogus.com) Message-ID: <50B02960.3030607@bogus.com> Date: Fri, 23 Nov 2012 17:56:48 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Will Liu (Shucheng)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 24 Nov 2012 01:56:54 +0000 (UTC) Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Minutes from Atlanta meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 01:57:43 -0000 On 11/23/12 5:41 PM, Will Liu (Shucheng) wrote: > Thanks for your efforts. > > Btw, is there a voice recording for IPsec session? http://www.ietf.org/audio/ietf85/ > Will > > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >> Paul Hoffman >> Sent: Tuesday, November 13, 2012 10:40 AM >> To: IPsecme WG >> Subject: [IPsec] Minutes from Atlanta meeting >> >> Carl Wallace did a fine job of taking minutes. I cleaned them up just a tad; >> they are at >> . >> >> Please send corrections *only* for things that are wrong in the minutes. If >> you want to discuss a topic from the minutes, please start a new thread. >> Thanks in advance! >> >> --Paul Hoffman >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From vishwas.ietf@gmail.com Sat Nov 24 09:21:14 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFF921F8496 for ; Sat, 24 Nov 2012 09:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VnM8CU-7+rP for ; Sat, 24 Nov 2012 09:21:12 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCDC721F8481 for ; Sat, 24 Nov 2012 09:21:10 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so8272223lbk.31 for ; Sat, 24 Nov 2012 09:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jviClVHPfXqSxBfVTuIhklm8BwLGOSMYllVXlk52U6Y=; b=cflYJHAOz6u54iT4vnRVh27B9rgXuRicKhBN0ECQzXHb8RNjVAgpByDix+vn7Ouy/T ZYt0GcBnhYXpH0tGyWkIfm39wCFS42qN+7u0vGMLs86uvsKK+kLlTr4+uyfiNHridndG HbsSLZQmJP7f6FguSPJKAuZXgetRM7pwcL0xAH4RYSHlw8c5eoKIApw1Qvp7XvTClofT +GqrzWPCJ5yLhMrRw9P9gF3cXUANEl+ntc3HpVyVDX3Kr9lIJOD+A+mx0aXSsECQsu4k 0hdvYIRmo0IoQf2970YEnI7WEFqbtIVKuZixvEWxrIfeJUg+gX2ymw2vCP8/v+i1Gnhi IICQ== MIME-Version: 1.0 Received: by 10.112.26.67 with SMTP id j3mr3198714lbg.39.1353777669826; Sat, 24 Nov 2012 09:21:09 -0800 (PST) Received: by 10.114.75.110 with HTTP; Sat, 24 Nov 2012 09:21:09 -0800 (PST) In-Reply-To: References: <50A5703F.4070305@labn.net> <50A58CDB.30402@labn.net> <50A682F8.9080907@labn.net> <50A689A9.1090803@labn.net> <50A68D30.2040203@labn.net> Date: Sat, 24 Nov 2012 09:21:09 -0800 Message-ID: From: Vishwas Manral To: Lou Berger Content-Type: multipart/alternative; boundary=bcaec55556781d692b04cf40edb4 Cc: IPsecme WG Subject: Re: [IPsec] Some comments / questions on draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 17:21:14 -0000 --bcaec55556781d692b04cf40edb4 Content-Type: text/plain; charset=ISO-8859-1 Hi WG-participants, As its been a week and I have not heard any objections, I will update this requirement and post the draft across. Thanks, Vishwas On Fri, Nov 16, 2012 at 11:10 AM, Vishwas Manral wrote: > Thanks Lou, > > Let me heard back from the WG on this, if they have any opinion. If not we > can go ahead with your suggestion. > > -Vishwas > > > On Fri, Nov 16, 2012 at 11:00 AM, Lou Berger wrote: > >> Vishwas, >> >> On 11/16/2012 1:48 PM, Vishwas Manral wrote: >> > Hi Lou, >> > >> > Got it. Can you suggest some text for this? I will try to incorporate >> > the same into the document. >> >> Assuming you don't like my prior attempt: >> X. The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364]. >> >> How about something like: >> X. The solution MUST support Provider Edge (PE) based VPNs. >> >> Note that this phrasing doesn't indicate a specific solutions which is >> why I now suggest "MUST" vs "SHOULD". >> >> Lou >> >> > >> > Thanks, >> > Vishwas >> > >> > On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger > > > wrote: >> > >> > Vishwas, >> > Sure, but it's the BGP information that indicates what IPsec >> > tunnels >> > are needed / when the SAs get established... >> > >> > Again, I just asking for language that points to this use case, not >> > implementation details. >> > >> > Thanks, >> > Lou >> > >> > On 11/16/2012 1:34 PM, Vishwas Manral wrote: >> > > Hi Lou, >> > > >> > >> I'm not sure I agree with this statement. Let's say you have >> > >> a BGP VPN that uses IPsec tunnels between the PEs (which >> > >> was described in a couple of expired drafts and can be supported >> > >> using RFC5566), and then wants to be able to use dynamic PE >> > >> to PE IPsec tunnels. Does this fit your "2 different layer" >> > >> perspective? >> > > IPsec with ADVPN secures the tunnel and creates the mesh underlay >> on >> > > need basis/ or automatically. L3VPN creates the overlay, >> > identifies the >> > > tenant/ customer a packet belongs to and passes the packet on. >> > > >> > > Where do we see the need for tighter integration here? Is it >> allowing >> > > the ability to create groups of ADVPN instances? >> > > >> > > Thanks, >> > > Vishwas >> > > >> > > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger > > >> > > >> wrote: >> > > >> > > Vishwas, >> > > >> > > Please see below. >> > > >> > > On 11/16/2012 12:49 PM, Vishwas Manral wrote: >> > > > Hi Lou, >> > > > >> > > > Thanks for the quick reply. Just a few comments prefixed >> > with a "VM>": >> > > > >> > > > > >> > > > > We can add something in the lines of additional >> protocols >> > > are run over >> > > > > the IPsec tunnels and the solution should make an >> > effort to >> > > allow for >> > > > > additional protocols like OSPF to be run optimally >> without >> > > too many >> > > > > changes in configuration. >> > > > > >> > > > > Infact we have a requirement to the effect in section >> 4.1 >> > > > >> > > > yes, this is what I referred to as 4.2 below, and >> > suggested some >> > > > replacement text... >> > > > >> > > > OK got it. >> > > > >> > > > > >> > > > > Gateways MUST allow tunnel binding, such that >> > > applications like >> > > > > Routing using the tunnels can work seamlessly >> > without any >> > > > updates to >> > > > > the higher level application configuration i.e. >> OSPF >> > > > configuration. >> > > > > >> > > > > - In section 4.2, how about: >> > > > > (replacement text) >> > > > > 3. Gateways MUST allow for the operation of >> > > tunneling and >> > > > > routing protocols operating over spoke-to-spoke >> > IPsec >> > > Tunnels >> > > > > with minimal, or no, configuration impact. >> > > > >> > > > VM> Ok will specifically specify tunnels and routing >> protocols. >> > > > >> > > >> > > Great. >> > > >> > > > >> > > > > >> > > > > >> > > > > X. The solution SHOULD support BGP/MPLS IP >> > VPNs, see >> > > > [RFC4364]. >> > > > > >> > > > > If you want, you can make the "SHOULD" a "MUST", >> and >> > > "support" >> > > > could be >> > > > > "be compatible with". >> > > > > >> > > > > I do not want to go ahead into details of what other >> > routing >> > > solutions >> > > > > it should support. >> > > > > >> > > > > With that said I am not sure what you mean by having >> BGP >> > > MPLS VPN >> > > > in an >> > > > > ADVPN scenario. BGP MPLS VPN is a provider >> provisioned VPN >> > > solution, >> > > > > this is a customer provisioned one. >> > > > >> > > > Ahh, interesting point. When I read the document I was >> > > looking to see >> > > > if it was scoped purely to CE/customer based solutions. >> > > Reading section >> > > > 2 (intro) and 2.2, I saw no such restriction. So I >> think >> > > section 2.2 >> > > > should be explicit on this point either way. Which is >> why I >> > > proposed the >> > > > text "There is also the case when L3VPNs operate over >> IPsec >> > > Tunnels." >> > > > (To explicitly include this case.) If the WG wants this >> > case >> > > excluded, >> > > > that's fine too. >> > > > >> > > > VM> It is not scoped purely as a CE device scenario, and >> > after seeing >> > > > your comment I see no reason to leave that out of scope >> > (though if I >> > > > understand your concern better I may feel otherwise). L3VPN >> > can work >> > > > over GRE tunnels/ L2TP tunnels, which can themselves use >> IPsec. >> > > Again in >> > > > my view the L3VPN and the IPsec VPN are 2 different layers >> > in the >> > > stack >> > > > if they run on the same device. >> > > >> > > I'm not sure I agree with this statement. Let's say you have >> > a BGP VPN >> > > that uses IPsec tunnels between the PEs (which was described >> > in a couple >> > > of expired drafts and can be supported using RFC5566), and >> > then wants to >> > > be able to use dynamic PE to PE IPsec tunnels. Does this fit >> > your "2 >> > > different layer" perspective? >> > > >> > > Either way, I think such usage should be explicitly in scope >> > as it is a >> > > very different model / use case from CE-based IPsec VPNs. >> > > >> > > > Do you see a reason to explicitly >> > > > mention L3VPN in this case? >> > > >> > > I'm open to different ways to cover the above. >> > > >> > > Much thanks, >> > > Lou >> > > > >> > > > Thanks, >> > > > Vishwas >> > > > >> > > > >> > > > >> > > > > I see the 2 working in different >> > > > > layers, and interacting only in edge gateways where >> both >> > > solutions >> > > > have >> > > > > an edge. >> > > > >> > > > Sure, but the problem exists for both. >> > > > >> > > > Thanks, >> > > > Lou >> > > > > >> > > > > >> > > > > I also have a few more minor comments: >> > > > > >> > > > > I am ok with the minor suggestions you have. >> > > > > >> > > > > Thanks, >> > > > > Vishwas >> > > > > >> > > > > >> > > > > >> > > > > - In section 2.1, you introduce the term "NAT >> > gateway" and >> > > > then later >> > > > > use just "gateway" when I suspect you mean "NAT >> > gateway". I >> > > > suggest >> > > > > using the term "NAT" and thereby not introduce >> > possible >> > > confusion >> > > > > between the gateway term defined in section 1.1 >> > and "NAT >> > > > gateways". >> > > > > >> > > > > - In section 2.2, s/occupies/requires >> > > > > >> > > > > - In sections 2.2, and Section 3.2 you say dynamic >> > > addresses makes >> > > > > static configuration impossible. This doesn't >> reflect >> > > the use of >> > > > > dynamic dns to handle this issues (and is >> currently >> > > supported >> > > > by some >> > > > > vendors.) >> > > > > >> > > > > Let me know what you think, >> > > > > Lou >> > > > > _______________________________________________ >> > > > > IPsec mailing list >> > > > > IPsec@ietf.org >> > > >> > > >> > >> >> > > >> > > >> > > > >> > >>> >> > > > > https://www.ietf.org/mailman/listinfo/ipsec >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > >> > >> > > --bcaec55556781d692b04cf40edb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi WG-participants,
=A0
As its been a week and I h= ave not heard any objections, I will update this requirement and post the d= raft across.
=A0
Thanks,
Vishwas
On Fri, Nov 16, 2012 at 11:10 AM, Vishwas Manral <vishwas.ietf@gmail.= com> wrote:
Thanks Lou,

Let me heard back from the WG on this, if they have any = opinion. If not we can go ahead with your suggestion.

-Vishwas


On Fri, Nov 16, 2012 a= t 11:00 AM, Lou Berger <lberger@labn.net> wrote:
Vishwas,

On 11/16/2012 1:48 PM, Vishwas Manral wrote:
> Hi Lou,
>
> Got it. Can you suggest some text for this? I will try to i= ncorporate
> the same into the document.

Assuming you don't like my prior attempt:
X. =A0The solution SHOULD support BGP/MPLS IP VPNs, see [RFC4364].

How about something like:
X. The solution MUST support Provider Edge (PE) based VPNs.

Note that this phrasing doesn't indicate a specific solutions which is<= br> why I now suggest "MUST" vs "SHOULD".

Lou

>
> Thanks,
> Vishwas
>
> On Fri, Nov 16, 2012 at 10:44 AM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>> wrote:
>
> =A0 =A0 Vishwas,
> =A0 =A0 =A0 =A0 =A0 =A0 Sure, but it's the BGP information that in= dicates what IPsec
> =A0 =A0 tunnels
> =A0 =A0 are needed / when the SAs get established...
>
> =A0 =A0 Again, I just asking for language that points to this use case= , not
> =A0 =A0 implementation details.
>
> =A0 =A0 Thanks,
> =A0 =A0 Lou
>
> =A0 =A0 On 11/16/2012 1:34 PM, Vishwas Manral wrote:
> =A0 =A0 > Hi Lou,
> =A0 =A0 >
> =A0 =A0 >> I'm not sure I agree with this statement. =A0Let&= #39;s say you have
> =A0 =A0 >> a BGP VPN that uses IPsec tunnels between the PEs (wh= ich
> =A0 =A0 >> was described in a couple of expired drafts and can b= e supported
> =A0 =A0 >> using RFC5566), and then wants to be able to use dyna= mic PE
> =A0 =A0 >> to PE IPsec tunnels. =A0Does this fit your "2 di= fferent layer"
> =A0 =A0 >> perspective?
> =A0 =A0 > IPsec with ADVPN secures the tunnel and creates the mesh = underlay on
> =A0 =A0 > need basis/ or automatically. L3VPN creates the overlay,<= br> > =A0 =A0 identifies the
> =A0 =A0 > tenant/ customer a packet belongs to and passes the packe= t on.
> =A0 =A0 >
> =A0 =A0 > Where do we see the need for tighter integration here? Is= it allowing
> =A0 =A0 > the ability to create groups of ADVPN instances?
> =A0 =A0 >
> =A0 =A0 > Thanks,
> =A0 =A0 > Vishwas
> =A0 =A0 >
> =A0 =A0 > On Fri, Nov 16, 2012 at 10:16 AM, Lou Berger <lberger@labn.net
> =A0 =A0 <mailto:lberger@labn.net>
> =A0 =A0 > <mailto:lberger@labn.net <mailto:lberger@labn.net>>> w= rote:
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Vishwas,
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Please see below.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 On 11/16/2012 12:49 PM, Vishwas Manral wrote:
> =A0 =A0 > =A0 =A0 > Hi Lou,
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > Thanks for the quick reply. Just a few comme= nts prefixed
> =A0 =A0 with a "VM>":
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > We can add something in the lin= es of additional protocols
> =A0 =A0 > =A0 =A0 are run over
> =A0 =A0 > =A0 =A0 > =A0 =A0 > the IPsec tunnels and the solut= ion should make an
> =A0 =A0 effort to
> =A0 =A0 > =A0 =A0 allow for
> =A0 =A0 > =A0 =A0 > =A0 =A0 > additional protocols like OSPF = to be run optimally without
> =A0 =A0 > =A0 =A0 too many
> =A0 =A0 > =A0 =A0 > =A0 =A0 > changes in configuration.
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > Infact we have a requirement to= the effect in section 4.1
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 yes, this is what I referred to as 4= .2 below, and
> =A0 =A0 suggested some
> =A0 =A0 > =A0 =A0 > =A0 =A0 replacement text...
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > OK got it.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 Gateways MUST allow tun= nel binding, such that
> =A0 =A0 > =A0 =A0 applications like
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0Routing using the tunnel= s can work seamlessly
> =A0 =A0 without any
> =A0 =A0 > =A0 =A0 > =A0 =A0 updates to
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0the higher level applica= tion configuration i.e. =A0OSPF
> =A0 =A0 > =A0 =A0 > =A0 =A0 configuration.
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 - In section 4.2, how a= bout:
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A0(replacement tex= t)
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A03. =A0Gateways M= UST allow for the operation of
> =A0 =A0 > =A0 =A0 tunneling and
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A0routing protocol= s operating over spoke-to-spoke
> =A0 =A0 IPsec
> =A0 =A0 > =A0 =A0 Tunnels
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A0with minimal, or= no, configuration impact.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > VM> Ok will specifically specify tunnels = and routing protocols.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Great.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 =A0 =A0X. =A0The soluti= on SHOULD support BGP/MPLS IP
> =A0 =A0 VPNs, see
> =A0 =A0 > =A0 =A0 > =A0 =A0 [RFC4364].
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 If you want, you can ma= ke the "SHOULD" a "MUST", and
> =A0 =A0 > =A0 =A0 "support"
> =A0 =A0 > =A0 =A0 > =A0 =A0 could be
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 "be compatible wit= h".
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > I do not want to go ahead into = details of what other
> =A0 =A0 routing
> =A0 =A0 > =A0 =A0 solutions
> =A0 =A0 > =A0 =A0 > =A0 =A0 > it should support.
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > With that said I am not sure wh= at you mean by having BGP
> =A0 =A0 > =A0 =A0 MPLS VPN
> =A0 =A0 > =A0 =A0 > =A0 =A0 in an
> =A0 =A0 > =A0 =A0 > =A0 =A0 > ADVPN scenario. BGP MPLS VPN is= a provider provisioned VPN
> =A0 =A0 > =A0 =A0 solution,
> =A0 =A0 > =A0 =A0 > =A0 =A0 > this is a customer provisioned = one.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 Ahh, interesting point. =A0When I re= ad the document I was
> =A0 =A0 > =A0 =A0 looking to see
> =A0 =A0 > =A0 =A0 > =A0 =A0 if it was scoped purely to CE/custom= er based solutions.
> =A0 =A0 > =A0 =A0 =A0Reading section
> =A0 =A0 > =A0 =A0 > =A0 =A0 2 (intro) and 2.2, I saw no such res= triction. =A0So I think
> =A0 =A0 > =A0 =A0 section 2.2
> =A0 =A0 > =A0 =A0 > =A0 =A0 should be explicit on this point eit= her way. Which is why I
> =A0 =A0 > =A0 =A0 proposed the
> =A0 =A0 > =A0 =A0 > =A0 =A0 text "There is also the case wh= en L3VPNs operate over IPsec
> =A0 =A0 > =A0 =A0 Tunnels."
> =A0 =A0 > =A0 =A0 > =A0 =A0 (To explicitly include this case.) = =A0If the WG wants this
> =A0 =A0 case
> =A0 =A0 > =A0 =A0 excluded,
> =A0 =A0 > =A0 =A0 > =A0 =A0 that's fine too.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > VM> It is not scoped purely as a CE devic= e scenario, and
> =A0 =A0 after seeing
> =A0 =A0 > =A0 =A0 > your comment I see no reason to leave that o= ut of scope
> =A0 =A0 (though if I
> =A0 =A0 > =A0 =A0 > understand your concern better I may feel ot= herwise). L3VPN
> =A0 =A0 can work
> =A0 =A0 > =A0 =A0 > over GRE tunnels/ L2TP tunnels, which can th= emselves use IPsec.
> =A0 =A0 > =A0 =A0 Again in
> =A0 =A0 > =A0 =A0 > my view the L3VPN and the IPsec VPN are 2 di= fferent layers
> =A0 =A0 in the
> =A0 =A0 > =A0 =A0 stack
> =A0 =A0 > =A0 =A0 > if they run on the same device.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 I'm not sure I agree with this statement. =A0= Let's say you have
> =A0 =A0 a BGP VPN
> =A0 =A0 > =A0 =A0 that uses IPsec tunnels between the PEs (which wa= s described
> =A0 =A0 in a couple
> =A0 =A0 > =A0 =A0 of expired drafts and can be supported using RFC5= 566), and
> =A0 =A0 then wants to
> =A0 =A0 > =A0 =A0 be able to use dynamic PE to PE IPsec tunnels. = =A0Does this fit
> =A0 =A0 your "2
> =A0 =A0 > =A0 =A0 different layer" perspective?
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Either way, I think such usage should be explicit= ly in scope
> =A0 =A0 as it is a
> =A0 =A0 > =A0 =A0 very different model / use case from CE-based IPs= ec VPNs.
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 > Do you see a reason to explicitly
> =A0 =A0 > =A0 =A0 > mention L3VPN in this case?
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 I'm open to different ways to cover the above= .
> =A0 =A0 >
> =A0 =A0 > =A0 =A0 Much thanks,
> =A0 =A0 > =A0 =A0 Lou
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > Thanks,
> =A0 =A0 > =A0 =A0 > Vishwas
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > I see the 2 working in differen= t
> =A0 =A0 > =A0 =A0 > =A0 =A0 > layers, and interacting only in= edge gateways where both
> =A0 =A0 > =A0 =A0 solutions
> =A0 =A0 > =A0 =A0 > =A0 =A0 have
> =A0 =A0 > =A0 =A0 > =A0 =A0 > an edge.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 Sure, but the problem exists for bot= h.
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 Thanks,
> =A0 =A0 > =A0 =A0 > =A0 =A0 Lou
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 I also have a few more = minor comments:
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > I am ok with the minor suggesti= ons you have.
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > Thanks,
> =A0 =A0 > =A0 =A0 > =A0 =A0 > Vishwas
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 - In section 2.1, you i= ntroduce the term "NAT
> =A0 =A0 gateway" and
> =A0 =A0 > =A0 =A0 > =A0 =A0 then later
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 use just "gateway&= quot; when I suspect you mean "NAT
> =A0 =A0 gateway". =A0I
> =A0 =A0 > =A0 =A0 > =A0 =A0 suggest
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 using the term "NA= T" and thereby not introduce
> =A0 =A0 possible
> =A0 =A0 > =A0 =A0 confusion
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 between the gateway ter= m defined in section 1.1
> =A0 =A0 and "NAT
> =A0 =A0 > =A0 =A0 > =A0 =A0 gateways".
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 - In section 2.2, s/occ= upies/requires
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 - In sections 2.2, and = Section 3.2 you say dynamic
> =A0 =A0 > =A0 =A0 addresses makes
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 static configuration im= possible. =A0This doesn't reflect
> =A0 =A0 > =A0 =A0 the use of
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 dynamic dns to handle t= his issues (and is currently
> =A0 =A0 > =A0 =A0 supported
> =A0 =A0 > =A0 =A0 > =A0 =A0 by some
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 vendors.)
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 Let me know what you th= ink,
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 Lou
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 _______________________= ________________________
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 IPsec mailing list
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 IPsec@ietf.org <mailto:IPsec@ietf.org>
> =A0 =A0 <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>
> =A0 =A0 > =A0 =A0 <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>
> =A0 =A0 <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>>
> =A0 =A0 > =A0 =A0 <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>
> =A0 =A0 <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>
> =A0 =A0 > =A0 =A0 > =A0 =A0 <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>
> =A0 =A0 <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>>>
> =A0 =A0 > =A0 =A0 > =A0 =A0 > =A0 =A0 https://www.ietf.org/mai= lman/listinfo/ipsec
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 > =A0 =A0 >
> =A0 =A0 >
> =A0 =A0 >
>
>


--bcaec55556781d692b04cf40edb4-- From internet-drafts@ietf.org Mon Nov 26 09:25:08 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D935F21F8540; Mon, 26 Nov 2012 09:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Rb5cvKAPqjz; Mon, 26 Nov 2012 09:25:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FEA21F85AC; Mon, 26 Nov 2012 09:25:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121126172508.8014.10385.idtracker@ietfa.amsl.com> Date: Mon, 26 Nov 2012 09:25:08 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ad-vpn-problem-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 17:25:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Auto Discovery VPN Problem Statement and Requirements Author(s) : Steve Hanna Vishwas Manral Filename : draft-ietf-ipsecme-ad-vpn-problem-01.txt Pages : 16 Date : 2012-11-26 Abstract: This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of endpoints change or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution is chartered to address these requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ad-vpn-problem-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From fgont@si6networks.com Tue Nov 27 07:11:23 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A335F21F872E for ; Tue, 27 Nov 2012 07:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pljqmlqYatJx for ; Tue, 27 Nov 2012 07:11:23 -0800 (PST) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA2121F85A1 for ; Tue, 27 Nov 2012 07:11:22 -0800 (PST) Received: from 187-135-17-190.fibertel.com.ar ([190.17.135.187] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TdMoF-0004PD-7i; Tue, 27 Nov 2012 16:10:53 +0100 Message-ID: <50B4D7F6.20401@si6networks.com> Date: Tue, 27 Nov 2012 12:10:46 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <67832B1175062E48926BF3CB27C49B240C832724@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B240C832724@xmb-aln-x12.cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [IPsec] Fwd: [opsec] Call for WG adoption in OPSEC - Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 15:11:23 -0000 Hi, folks, I had presented this I-D (http://datatracker.ietf.org/doc/draft-gont-opsec-vpn-leakages/) at the last ipsecme wg meeting, just as a kin of heads-up on what were discussing in the opsec wg. FYI, the opsec wg is now being polled about wg adoption of this document. Please feel free to send your comments to: Thanks, Fernando -------- Original Message -------- From: Gunter Van de Velde (gvandeve) To: opsec@ietf.org Thread-Topic: Call for WG adoption in OPSEC - Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks Thread-Index: Ac3Mnk8XCC7UKWxNT+OWDCCme2iK1A== Date: Tue, 27 Nov 2012 12:57:32 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240C832724@xmb-aln-x12.cisco.com> Cc: v6ops v6ops WG (v6ops@ietf.org) Subject: [v6ops] Call for WG adoption in OPSEC - Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks Dear all, Please find this call as result of IETF85 OPSEC meeting for WG adoption for document http://datatracker.ietf.org/doc/draft-gont-opsec-vpn-leakages/ Please speak out during the next 2 weeks on your opinion to adopt within OPSEC or not adopt. Kind Regards, OPSEC chairs From ynir@checkpoint.com Wed Nov 28 00:08:14 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B66321F850C for ; Wed, 28 Nov 2012 00:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.74 X-Spam-Level: X-Spam-Status: No, score=-8.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDFTnpImfjZB for ; Wed, 28 Nov 2012 00:08:13 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6EE21F8624 for ; Wed, 28 Nov 2012 00:08:12 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qAS88ADB028141 for ; Wed, 28 Nov 2012 10:08:11 +0200 X-CheckPoint: {50B5C682-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.194]) by IL-EX10.ad.checkpoint.com ([169.254.2.194]) with mapi id 14.02.0318.004; Wed, 28 Nov 2012 10:07:53 +0200 From: Yoav Nir To: IPsecme WG Thread-Topic: Question about IKEv1 and ECDSA Thread-Index: AQHNzT93tyWp2/IlgECv+9TpKnXuTw== Date: Wed, 28 Nov 2012 08:07:53 +0000 Message-ID: <4613980CFC78314ABFD7F85CC3027721023F2E@IL-EX10.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.38] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <41F598EC2363F14191CFABE5AAE75573@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Question about IKEv1 and ECDSA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 08:08:14 -0000 Hi I know we don't like IKEv1 questions, but RFC 4754 does mention it, so here= goes. And sorry if this has been discussed before. I couldn't find it. In IKEv1 the authentication method is negotiated as an SA parameter. So pre= sumably the Initiator proposes RSA signatures, ECDSA with the P-256 curve, = etc, and the Responder chooses one of them. This happens in packets #1 and = #2. Later the certificate to actually present (in packets #5 and #6) is chosen = based on a Certificate Request payload, and availability. This is different= from IKEv2, where authentication method is implied by the certificates rat= her than negotiated. So two questions: 1. Is it impossible to have one peer authenticate with RSA while the other = authenticates with ECDSA, or even to mix curves? Or am I missing something= ? 2. What if an IKE endpoint has >1 certificates, but the one best-suited for= the certificate request has a different type key than the one agreed to in= packet #2? If I'm not missing something, it seems like IKEv1 is the wrong vehicle for = the gradual introduction of ECDSA. I'm not proposing to fix it, just tryin= g to understand. Yoav From paul.hoffman@vpnc.org Wed Nov 28 07:02:30 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C16A21F8874 for ; Wed, 28 Nov 2012 07:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiCh1sEg+ZiW for ; Wed, 28 Nov 2012 07:02:29 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id A793921F8869 for ; Wed, 28 Nov 2012 07:02:29 -0800 (PST) Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qASF2IPS043433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Nov 2012 08:02:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <4613980CFC78314ABFD7F85CC3027721023F2E@IL-EX10.ad.checkpoint.com> Date: Wed, 28 Nov 2012 07:02:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <060190F3-C914-4995-82E3-9F613461B8BB@vpnc.org> References: <4613980CFC78314ABFD7F85CC3027721023F2E@IL-EX10.ad.checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1499) Cc: IPsecme WG Subject: Re: [IPsec] Question about IKEv1 and ECDSA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 15:02:30 -0000 On Nov 28, 2012, at 12:07 AM, Yoav Nir wrote: > 1. Is it impossible to have one peer authenticate with RSA while the = other authenticates with ECDSA, or even to mix curves? Or am I missing = something? This was discussed a decade ago at interop events, and the general = agreement was that it is impossible to do without an extension, and no = one cared to do that. (The question was actually about PlainOldDSA, not = ECDSA, but the result is the same.) > 2. What if an IKE endpoint has >1 certificates, but the one = best-suited for the certificate request has a different type key than = the one agreed to in packet #2? Same. --Paul Hoffman= From yaronf.ietf@gmail.com Wed Nov 28 11:48:50 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C9D21F8843 for ; Wed, 28 Nov 2012 11:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NihS25a63GDZ for ; Wed, 28 Nov 2012 11:48:50 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE62121F8857 for ; Wed, 28 Nov 2012 11:48:49 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so6641901bku.31 for ; Wed, 28 Nov 2012 11:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=JgLDQ13Yjz1EuffR49hInXTyCczgt+b3WwoRW/BRJm0=; b=1A2P0RARE2eBtvyQIiEEFi2W3gz8gsGdNTAyMWSoGu2IIE2VIPxwhZR1qcOLmkU9Hv ZZNlFndeF0XDctTzOJvQt417wkxoO+CBDK/n4VzK0Lfx8l/ZXy6Z1WhTOMcJzsyPcAio IOBh1Qw55SXpvHgyqQ7MgqRJca/G1d3tGdPOmRteZXrsDk73kwbg/250PXcqFUNmySXr U0K+Ln6WRio79weo+QuBldw6oZgNfOWQvrxx+HsK9rp2nwhW0Y12AG9RK3FKqJqvKzKH wrgd0CofMj8tZwPqyJn6zhYkj/NLKQep84mJPQBU+NYAsv93Q5Ttjke1ng0Idcqa2o4M TPTQ== Received: by 10.204.147.139 with SMTP id l11mr6303978bkv.46.1354132128244; Wed, 28 Nov 2012 11:48:48 -0800 (PST) Received: from [10.0.0.3] (bzq-79-183-164-29.red.bezeqint.net. [79.183.164.29]) by mx.google.com with ESMTPS id i20sm13620182bkw.5.2012.11.28.11.48.46 (version=SSLv3 cipher=OTHER); Wed, 28 Nov 2012 11:48:47 -0800 (PST) Message-ID: <50B66A9C.8020001@gmail.com> Date: Wed, 28 Nov 2012 21:48:44 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] AD VPN document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 19:48:50 -0000 Hi everyone, Vishwas and Steve recently published version 01 of the Problem Statement ( http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-01). We have already gone through WG last call on this one, so I would like to ask those who commented on the previous version to verify that their inputs have been taken into account. If no comments were missed, Paul and I will send the document to our AD within a week. Moving forward on the auto-discovery VPN front, now is the time to start working on protocol proposals. We will not adopt any of them as WG items before the Requirements are stable (have gone through IETF and IESG review). But individual drafts are certainly welcome. Thanks, Yaron From dharkins@lounge.org Wed Nov 28 11:56:49 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127E021F8593 for ; Wed, 28 Nov 2012 11:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF7AkBgC5Yyn for ; Wed, 28 Nov 2012 11:56:48 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 99AC821F8590 for ; Wed, 28 Nov 2012 11:56:48 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 93F031022400A; Wed, 28 Nov 2012 11:56:47 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 28 Nov 2012 11:56:48 -0800 (PST) Message-ID: <1578f8a270e41136de93c6eb6ef78ddb.squirrel@www.trepanning.net> In-Reply-To: <4613980CFC78314ABFD7F85CC3027721023F2E@IL-EX10.ad.checkpoint.com> References: <4613980CFC78314ABFD7F85CC3027721023F2E@IL-EX10.ad.checkpoint.com> Date: Wed, 28 Nov 2012 11:56:48 -0800 (PST) From: "Dan Harkins" To: "Yoav Nir" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG Subject: Re: [IPsec] Question about IKEv1 and ECDSA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 19:56:49 -0000 Hello, On Wed, November 28, 2012 12:07 am, Yoav Nir wrote: > Hi > > I know we don't like IKEv1 questions, but RFC 4754 does mention it, so > here goes. And sorry if this has been discussed before. I couldn't find > it. What do you mean "we"? :-) > In IKEv1 the authentication method is negotiated as an SA parameter. So > presumably the Initiator proposes RSA signatures, ECDSA with the P-256 > curve, etc, and the Responder chooses one of them. This happens in packets > #1 and #2. > > Later the certificate to actually present (in packets #5 and #6) is chosen > based on a Certificate Request payload, and availability. This is > different from IKEv2, where authentication method is implied by the > certificates rather than negotiated. > > So two questions: > 1. Is it impossible to have one peer authenticate with RSA while the other > authenticates with ECDSA, or even to mix curves? Or am I missing > something? No, they both have to do ECDSA. The way that ECDSA was added to IKEv1-- make it bound to the curve-- was unfortunate. That means that you can't really mix curves either after agreeing to do ECDSA with one particular curve. It would have be much more useful to divorce the curve from the willingness to do ECDSA. But oh well. > 2. What if an IKE endpoint has >1 certificates, but the one best-suited > for the certificate request has a different type key than the one agreed > to in packet #2? Tough luck. You agreed to ECDSA with a particular curve and that's what you go with. > If I'm not missing something, it seems like IKEv1 is the wrong vehicle for > the gradual introduction of ECDSA. I'm not proposing to fix it, just > trying to understand. It should work in the general case but you have pointed out some conditions that make it somewhat suboptimal. I believe the ECDSA tiger team has properly addressed these issues for IKEv2. Please speak up if you disagree. regards, Dan. From kivinen@iki.fi Thu Nov 29 05:51:37 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F7321F89E5 for ; Thu, 29 Nov 2012 05:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WszYgHZjtB3L for ; Thu, 29 Nov 2012 05:51:36 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id A394B21F89A7 for ; Thu, 29 Nov 2012 05:51:34 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qATDpQ5x014968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Nov 2012 15:51:26 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qATDpNeo025637; Thu, 29 Nov 2012 15:51:23 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20663.26715.668188.141385@fireball.kivinen.iki.fi> Date: Thu, 29 Nov 2012 15:51:23 +0200 From: Tero Kivinen To: ipsec@ietf.org In-Reply-To: <20633.24231.244628.939482@fireball.kivinen.iki.fi> References: <20633.24231.244628.939482@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 50 min Cc: Sean Turner Subject: [IPsec] Which option to pick on draft-kivinen-ipsecme-oob-pubkey-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 13:51:37 -0000 Tero Kivinen writes: > My draft draft-kivinen-ipsecme-oob-pubkey-02.txt defines new way to > send any type of raw public keys inside IKEv2. RFC5996 only allows > sending RSA raw public keys. This means after this we would have two > ways to do send RSA raw public keys, old RFC5996 and new format define > din my draft. > > 3) Obsolete old format > > Make old RFC 5996 format as MUST NOT, and officially obsolete > it. This means all implementations should switch to new format > as soon as possible. This document must be standard track, and > update RFC5996. > > In the discussion we did not found out that there would have been wide > use for the old RFC 5996 defined RSA raw public key, so feeling was > that it would be possible to obsolete the old format. It was > considered a bad idea to keep two ways of doing same thing. > > So now I want to know if anybody have anything against if we do just > that, i.e. pick the 3rd option and obsolete the old RSA raw public key > format. As there as not been any objections to this change, I will change my draft to say that RFC 5996 format is MUST NOT, and obsolete the old RSA public key format. The new draft is already posted as draft-kivinen-ipsecme-oob-pubkey-03.txt. http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey/ Diff: http://www.ietf.org/rfcdiff?url1=draft-kivinen-ipsecme-oob-pubkey-02&difftype=--html&submit=Go!&url2=draft-kivinen-ipsecme-oob-pubkey-03 > The another question is whether this document needs to be WG document > or not. As it seems to be that we are updating the RFC5996 and > obsoleting stuff from it, there seemed to be some people who felt that > this should be WG document. Send your comments about this too. Only comment to this in the list was from Michael supporting of making this to WG document (especially if it can fit to charter). Yaron said in the meeting that he was unhappy this being individual since it obsoletes old format. So now we need a comment from the ADs and/or chairs whether they feel that this fits our current charter (maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to IKEv2) or do we need to update the charter. I have feeling that as this updates RFC5996 we should modify the charter, and accept this as WG item, but that will add some delay, as I think this document should be ready now, and as we are obsoleting things it best to get this out as soon as possible... On the other hand it might be faster to do charter update, than wait for anybody in the list to say anything about this issue :-) -- kivinen@iki.fi From turners@ieca.com Thu Nov 29 06:15:24 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97E621F8A30 for ; Thu, 29 Nov 2012 06:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPiSqoWanCz9 for ; Thu, 29 Nov 2012 06:15:24 -0800 (PST) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [64.5.52.9]) by ietfa.amsl.com (Postfix) with ESMTP id 18DB021F89F0 for ; Thu, 29 Nov 2012 06:15:24 -0800 (PST) Received: by gateway06.websitewelcome.com (Postfix, from userid 5007) id 3E72CA049C291; Thu, 29 Nov 2012 08:15:23 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway06.websitewelcome.com (Postfix) with ESMTP id 0EAB6A049C16B for ; Thu, 29 Nov 2012 08:15:23 -0600 (CST) Received: from [108.45.19.185] (port=57798 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Te4te-0002yA-OH; Thu, 29 Nov 2012 08:15:22 -0600 Message-ID: <50B76DFA.9010705@ieca.com> Date: Thu, 29 Nov 2012 09:15:22 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tero Kivinen References: <20633.24231.244628.939482@fireball.kivinen.iki.fi> <20663.26715.668188.141385@fireball.kivinen.iki.fi> In-Reply-To: <20663.26715.668188.141385@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:57798 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: ipsec@ietf.org Subject: Re: [IPsec] Which option to pick on draft-kivinen-ipsecme-oob-pubkey-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 14:15:25 -0000 On 11/29/12 8:51 AM, Tero Kivinen wrote: > Tero Kivinen writes: >> My draft draft-kivinen-ipsecme-oob-pubkey-02.txt defines new way to >> send any type of raw public keys inside IKEv2. RFC5996 only allows >> sending RSA raw public keys. This means after this we would have two >> ways to do send RSA raw public keys, old RFC5996 and new format define >> din my draft. >> >> 3) Obsolete old format >> >> Make old RFC 5996 format as MUST NOT, and officially obsolete >> it. This means all implementations should switch to new format >> as soon as possible. This document must be standard track, and >> update RFC5996. >> >> In the discussion we did not found out that there would have been wide >> use for the old RFC 5996 defined RSA raw public key, so feeling was >> that it would be possible to obsolete the old format. It was >> considered a bad idea to keep two ways of doing same thing. >> >> So now I want to know if anybody have anything against if we do just >> that, i.e. pick the 3rd option and obsolete the old RSA raw public key >> format. > > As there as not been any objections to this change, I will change my > draft to say that RFC 5996 format is MUST NOT, and obsolete the old > RSA public key format. The new draft is already posted as > draft-kivinen-ipsecme-oob-pubkey-03.txt. > > http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey/ > > Diff: > > http://www.ietf.org/rfcdiff?url1=draft-kivinen-ipsecme-oob-pubkey-02&difftype=--html&submit=Go!&url2=draft-kivinen-ipsecme-oob-pubkey-03 > >> The another question is whether this document needs to be WG document >> or not. As it seems to be that we are updating the RFC5996 and >> obsoleting stuff from it, there seemed to be some people who felt that >> this should be WG document. Send your comments about this too. > > Only comment to this in the list was from Michael supporting of making > this to WG document (especially if it can fit to charter). > > Yaron said in the meeting that he was unhappy this being individual > since it obsoletes old format. > > So now we need a comment from the ADs and/or chairs whether they feel > that this fits our current charter (maintain the IPsec standard and to > facilitate discussion of clarifications, improvements, and extensions > to IPsec, mostly to IKEv2) or do we need to update the charter. The one sentence change to add this to the charter is on today's telechat. spt From turners@ieca.com Thu Nov 29 09:07:08 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A3721F8B14 for ; Thu, 29 Nov 2012 09:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SywJPkYhnzhr for ; Thu, 29 Nov 2012 09:07:06 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [64.5.52.7]) by ietfa.amsl.com (Postfix) with ESMTP id EE06721F8B18 for ; Thu, 29 Nov 2012 09:07:04 -0800 (PST) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 683D190C9F82E; Thu, 29 Nov 2012 11:07:01 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 5AB2290C9F800 for ; Thu, 29 Nov 2012 11:07:01 -0600 (CST) Received: from [108.45.19.185] (port=49783 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Te7Zl-0004XR-Rc; Thu, 29 Nov 2012 11:07:01 -0600 Message-ID: <50B79635.3080306@ieca.com> Date: Thu, 29 Nov 2012 12:07:01 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Tero Kivinen References: <20633.24231.244628.939482@fireball.kivinen.iki.fi> <20663.26715.668188.141385@fireball.kivinen.iki.fi> <50B76DFA.9010705@ieca.com> In-Reply-To: <50B76DFA.9010705@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:49783 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: ipsec@ietf.org Subject: Re: [IPsec] Which option to pick on draft-kivinen-ipsecme-oob-pubkey-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 17:07:08 -0000 On 11/29/12 9:15 AM, Sean Turner wrote: > On 11/29/12 8:51 AM, Tero Kivinen wrote: >> Tero Kivinen writes: >>> My draft draft-kivinen-ipsecme-oob-pubkey-02.txt defines new way to >>> send any type of raw public keys inside IKEv2. RFC5996 only allows >>> sending RSA raw public keys. This means after this we would have two >>> ways to do send RSA raw public keys, old RFC5996 and new format define >>> din my draft. >>> >>> 3) Obsolete old format >>> >>> Make old RFC 5996 format as MUST NOT, and officially obsolete >>> it. This means all implementations should switch to new format >>> as soon as possible. This document must be standard track, and >>> update RFC5996. >>> >>> In the discussion we did not found out that there would have been wide >>> use for the old RFC 5996 defined RSA raw public key, so feeling was >>> that it would be possible to obsolete the old format. It was >>> considered a bad idea to keep two ways of doing same thing. >>> >>> So now I want to know if anybody have anything against if we do just >>> that, i.e. pick the 3rd option and obsolete the old RSA raw public key >>> format. >> >> As there as not been any objections to this change, I will change my >> draft to say that RFC 5996 format is MUST NOT, and obsolete the old >> RSA public key format. The new draft is already posted as >> draft-kivinen-ipsecme-oob-pubkey-03.txt. >> >> http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey/ >> >> Diff: >> >> http://www.ietf.org/rfcdiff?url1=draft-kivinen-ipsecme-oob-pubkey-02&difftype=--html&submit=Go!&url2=draft-kivinen-ipsecme-oob-pubkey-03 >> >> >>> The another question is whether this document needs to be WG document >>> or not. As it seems to be that we are updating the RFC5996 and >>> obsoleting stuff from it, there seemed to be some people who felt that >>> this should be WG document. Send your comments about this too. >> >> Only comment to this in the list was from Michael supporting of making >> this to WG document (especially if it can fit to charter). >> >> Yaron said in the meeting that he was unhappy this being individual >> since it obsoletes old format. >> >> So now we need a comment from the ADs and/or chairs whether they feel >> that this fits our current charter (maintain the IPsec standard and to >> facilitate discussion of clarifications, improvements, and extensions >> to IPsec, mostly to IKEv2) or do we need to update the charter. > > The one sentence change to add this to the charter is on today's telechat. Ugh .. I sent it in too late so it's on the next telechat. spt From Johannes.Merkle@secunet.com Fri Nov 30 04:11:59 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3012F21F87A8 for ; Fri, 30 Nov 2012 04:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B27yfmTH6D8d for ; Fri, 30 Nov 2012 04:11:58 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 93B1F21F8705 for ; Fri, 30 Nov 2012 04:11:58 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 2B1A51A0083; Fri, 30 Nov 2012 13:11:17 +0100 (CET) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id B1D5C1A0076; Fri, 30 Nov 2012 13:11:12 +0100 (CET) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Nov 2012 13:11:52 +0100 Message-ID: <50B8A287.9090509@secunet.com> Date: Fri, 30 Nov 2012 13:11:51 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IPsecme WG X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2012 12:11:52.0718 (UTC) FILETIME=[E1F902E0:01CDCEF3] Cc: Manfred Lochter , "Turner, Sean P." , rfc-ise@rfc-editor.org Subject: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 12:11:59 -0000 We have submitted a new revision of the Internet Draft on Using the ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ Since there was considerable objection to the point compression method in the WG, we have removed this option altogether and define only the uncompressed KE payload format, which is in full accordance with RFC 5903. Any feedback is welcome. -- Johannes From dharkins@lounge.org Fri Nov 30 09:57:26 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9534621F8659 for ; Fri, 30 Nov 2012 09:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnqIhvSeNEhZ for ; Fri, 30 Nov 2012 09:57:25 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id C58BF21F85D9 for ; Fri, 30 Nov 2012 09:57:25 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8B81F1022400A; Fri, 30 Nov 2012 09:57:24 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 30 Nov 2012 09:57:25 -0800 (PST) Message-ID: <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> In-Reply-To: <50B8A287.9090509@secunet.com> References: <50B8A287.9090509@secunet.com> Date: Fri, 30 Nov 2012 09:57:25 -0800 (PST) From: "Dan Harkins" To: "Johannes Merkle" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG , Manfred Lochter , "Turner, Sean P." , rfc-ise@rfc-editor.org Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 17:57:26 -0000 Hi Johannes, On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: > We have submitted a new revision of the Internet Draft on > Using the ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key > Exchange > https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ > > Since there was considerable objection to the point compression method in > the WG, we have removed this option altogether > and define only the uncompressed KE payload format, which is in full > accordance with RFC 5903. > > > Any feedback is welcome. I see that there is a requirement that an implementation MUST verify that the D-H common value is not the point-at-infinity. Do you think there should also be a requirement that an implementation MUST verify that the x- and y-coordinates received from a peer satisfy the equation of the negotiated curve (and abort the exchange if not)? regards, Dan. From sfluhrer@cisco.com Fri Nov 30 10:26:39 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98F421F8AC8 for ; Fri, 30 Nov 2012 10:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 074aPrdPBv44 for ; Fri, 30 Nov 2012 10:26:39 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DFCF421F8A60 for ; Fri, 30 Nov 2012 10:26:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2589; q=dns/txt; s=iport; t=1354299996; x=1355509596; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MP6Sl2X7PZtgzF/MUXQ2ujtLXPVZiHSxw/SPh5YYQbE=; b=BLFaz2ao9FPTffeP/63rIiGJOCdzNKLDiz44rWfJtoFGydf9kt2GoVaI GIgvqF9xp8nDuEGXpojldmOEz0o8CdCRu9bXIbma++aSDXsE/P3+502vK wLoV6XG/IFv5bVWBiLb3EHW3t3yIb/lg5/ay3u3PNpLv5TJ/5AlxjTGJD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADX6uFCtJV2d/2dsb2JhbABEv38Wc4IeAQEBBAEBATcyAggDDAQCAQgOAwQBAQEKFAkHJwsUCQgCBAENBQiICAzAAgSMQINgYQOSTpN2gnKBZSQY X-IronPort-AV: E=McAfee;i="5400,1158,6912"; a="148067254" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 30 Nov 2012 18:26:26 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAUIQQkv019503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Nov 2012 18:26:26 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Fri, 30 Nov 2012 12:26:26 -0600 From: "Scott Fluhrer (sfluhrer)" To: Dan Harkins , Johannes Merkle Thread-Topic: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Thread-Index: AQHNzvPr3RuFFj57U0u04fPTF6DjPpgDDvyA//+dJBA= Date: Fri, 30 Nov 2012 18:26:25 +0000 Message-ID: References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> In-Reply-To: <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Manfred Lochter , "Turner, Sean P." , "rfc-ise@rfc-editor.org" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 18:26:39 -0000 There should *absolutely* be a requirement that any point you receive from = the peer is actually a point on the curve. What can happen if you don't? Well, that depends on the implementation of = the point addition/doubling; what happens with the normal implementation is= that it acts as if it was a different curve with a different curve order -= - this means that someone introducing a bogus value can give us a point wit= h a small order (which can't happen with the normal Brainpool curves, becau= se those curves have prime orders). In addition, validating the values is cheap; easily worth the gain. Also, given the you validate the peer's value, and forbid public points whi= ch are the point-at-infinity, doubling checking that the D-H common value i= s not the point at infinity appears to be unneeded. The Brainpool Curves a= re (again) of prime order; this implies that the D-H common value is the po= int at infinity only if the peer's public value is the point at infinity (w= hich ought to be forbidden), or our secret value is a multiple of the curve= order (in which case, our public value is the point at infinity). -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of D= an Harkins Sent: Friday, November 30, 2012 12:57 PM To: Johannes Merkle Cc: IPsecme WG; Manfred Lochter; Turner, Sean P.; rfc-ise@rfc-editor.org Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Ex= change Hi Johannes, On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: > We have submitted a new revision of the Internet Draft on Using the=20 > ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange=20 > https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ > > Since there was considerable objection to the point compression method=20 > in the WG, we have removed this option altogether and define only the=20 > uncompressed KE payload format, which is in full accordance with RFC=20 > 5903. > > > Any feedback is welcome. I see that there is a requirement that an implementation MUST verify that= the D-H common value is not the point-at-infinity. Do you think there shou= ld also be a requirement that an implementation MUST verify that the x- and= y-coordinates received from a peer satisfy the equation of the negotiated = curve (and abort the exchange if not)? regards, Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Fri Nov 30 13:04:08 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105C621F89E4 for ; Fri, 30 Nov 2012 13:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwhtMv2T3AT1 for ; Fri, 30 Nov 2012 13:04:07 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2750321F85A7 for ; Fri, 30 Nov 2012 13:04:07 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so624120eek.31 for ; Fri, 30 Nov 2012 13:04:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5yVAvR/hpaSzMjqiEeFrBs1Jbsk++JWvFHCnIq6Gz8g=; b=V3EOA/yJFu3vlq1fLbagskpzRj9BYG47LT/zv4//Jf8QO1zMHtvnoR5Xp/K0j27bU6 PXm0mzvOiDhYW+kx5jxNaAhxu8oayk85nRHcS2fO2ow/fIOBTOOrwp35xyOXiOCVEeHf rqPP1gM+9orQs9mvwuTNUpK4Hs4gF/6se3k3JRHoJeg8iOhOtAzx62wGm31MZYC2e1VQ edZDbjmuimqItKrwjyKgzRFOdYDptnxyqrIzShq6Cdk18z/boyShbuFJswOUqVc2gVua xqY9awiq9O/dx8hzt4/YgmFn/0be1knXkCP4n7SGHfELlFSf1NxA1SlhVbC6LVuNWYde MnFA== Received: by 10.14.216.193 with SMTP id g41mr8333913eep.37.1354309446301; Fri, 30 Nov 2012 13:04:06 -0800 (PST) Received: from [10.0.0.3] (bzq-79-183-164-29.red.bezeqint.net. [79.183.164.29]) by mx.google.com with ESMTPS id b2sm12868880eep.9.2012.11.30.13.03.56 (version=SSLv3 cipher=OTHER); Fri, 30 Nov 2012 13:04:05 -0800 (PST) Message-ID: <50B91F37.1010503@gmail.com> Date: Fri, 30 Nov 2012 23:03:51 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Scott Fluhrer (sfluhrer)" References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Johannes Merkle , Manfred Lochter , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Turner, Sean P." Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 21:04:08 -0000 The problem I have with this discussion is, this check (if really required) should have been in the base protocol, because the protocol has supported EC groups from day one. It doesn't belong in a specific curve definition. We could use the errata process to add it. It's not ideal, but certainly better than republishing RFC 5996. Thanks, Yaron On 11/30/2012 08:26 PM, Scott Fluhrer (sfluhrer) wrote: > There should *absolutely* be a requirement that any point you receive from the peer is actually a point on the curve. > > What can happen if you don't? Well, that depends on the implementation of the point addition/doubling; what happens with the normal implementation is that it acts as if it was a different curve with a different curve order -- this means that someone introducing a bogus value can give us a point with a small order (which can't happen with the normal Brainpool curves, because those curves have prime orders). > > In addition, validating the values is cheap; easily worth the gain. > > > Also, given the you validate the peer's value, and forbid public points which are the point-at-infinity, doubling checking that the D-H common value is not the point at infinity appears to be unneeded. The Brainpool Curves are (again) of prime order; this implies that the D-H common value is the point at infinity only if the peer's public value is the point at infinity (which ought to be forbidden), or our secret value is a multiple of the curve order (in which case, our public value is the point at infinity). > > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Dan Harkins > Sent: Friday, November 30, 2012 12:57 PM > To: Johannes Merkle > Cc: IPsecme WG; Manfred Lochter; Turner, Sean P.; rfc-ise@rfc-editor.org > Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange > > > Hi Johannes, > > On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: >> We have submitted a new revision of the Internet Draft on Using the >> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange >> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ >> >> Since there was considerable objection to the point compression method >> in the WG, we have removed this option altogether and define only the >> uncompressed KE payload format, which is in full accordance with RFC >> 5903. >> >> >> Any feedback is welcome. > > I see that there is a requirement that an implementation MUST verify that the D-H common value is not the point-at-infinity. Do you think there should also be a requirement that an implementation MUST verify that the x- and y-coordinates received from a peer satisfy the equation of the negotiated curve (and abort the exchange if not)? > > regards, > > Dan. > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From ynir@checkpoint.com Fri Nov 30 13:39:20 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CEC21F8540 for ; Fri, 30 Nov 2012 13:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.134 X-Spam-Level: X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DFK+A6CANUA for ; Fri, 30 Nov 2012 13:39:19 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0E121F853E for ; Fri, 30 Nov 2012 13:39:18 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qAULd8KY029348; Fri, 30 Nov 2012 23:39:09 +0200 X-CheckPoint: {50B92771-2-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.14]) by IL-EX10.ad.checkpoint.com ([194.29.34.147]) with mapi id 14.02.0318.004; Fri, 30 Nov 2012 23:39:08 +0200 From: Yoav Nir To: Johannes Merkle Thread-Topic: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Thread-Index: AQHNzvPvKh0P6YfEsUabMlIh19DBmZgCiN+AgAA98oA= Date: Fri, 30 Nov 2012 21:39:08 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> In-Reply-To: <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.170] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Manfred Lochter , "Sean P. Turner" , Dan Harkins , "rfc-ise@rfc-editor.org" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 21:39:20 -0000 Hi Johannes, Dan't question made me realise something I hadn't noticed before.=20 In section 2.3, the draft says: For the encoding of the key exchange payload and the derivation of the shared secret, the methods specified in [RFC5903] are adopted. In an ECP key exchange in IKEv2, the Diffie-Hellman public value passed in a KE payload consists of two components, x and y, However, according to RFC 5903: The Diffie-Hellman shared secret value consists of the x value of the Diffie-Hellman common value. In fact RFC 5903 replaced 4753 just to say that the encoding consists only = of x, not both x and y. This also relates to Dan't question. If the y value is missing, what is the= re to verify? Yoav On Nov 30, 2012, at 7:57 PM, Dan Harkins wrote: >=20 > Hi Johannes, >=20 > On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: >> We have submitted a new revision of the Internet Draft on >> Using the ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key >> Exchange >> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ >>=20 >> Since there was considerable objection to the point compression method i= n >> the WG, we have removed this option altogether >> and define only the uncompressed KE payload format, which is in full >> accordance with RFC 5903. >>=20 >>=20 >> Any feedback is welcome. >=20 > I see that there is a requirement that an implementation MUST verify > that the D-H common value is not the point-at-infinity. Do you think > there should also be a requirement that an implementation MUST verify > that the x- and y-coordinates received from a peer satisfy the equation > of the negotiated curve (and abort the exchange if not)? >=20 > regards, >=20 > Dan. From sfluhrer@cisco.com Fri Nov 30 14:00:57 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8031221F8589 for ; Fri, 30 Nov 2012 14:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3eH5ih5ACC0 for ; Fri, 30 Nov 2012 14:00:56 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5261821F85C3 for ; Fri, 30 Nov 2012 14:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3593; q=dns/txt; s=iport; t=1354312856; x=1355522456; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SBqj+B1L0xBTxXvc1e2Vw88fExvxTHl9ywTyhEotcvc=; b=NICtc1Dc5+BkykhQKtBuXj00jSMG9H6m8yVYK9t+e2qS5Pf+uBdY/54o fLRzuUNvh0o5u8KG7R6vnEQAuVSBCcH1TOHe9mdW2NEwKmclyszhRLZmu xRlC0fbTeGZe5FgJ7hCa6Xrwgc1v+Jzzhqx7k4DGrzBVJiPJexx28hvlw s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAG4ruVCtJV2b/2dsb2JhbABEwAIWc4IeAQEBAwEBAQE3NAsMBAIBCA4DBAEBAQoUCQcnCxQJCAIEAQ0FCIgCBgy/UgSMQINgYQOmRIJygWUkGA X-IronPort-AV: E=McAfee;i="5400,1158,6912"; a="145137851" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 30 Nov 2012 22:00:55 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAUM0tHK006846 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Nov 2012 22:00:55 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.203]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Fri, 30 Nov 2012 16:00:55 -0600 From: "Scott Fluhrer (sfluhrer)" To: Yoav Nir , Johannes Merkle Thread-Topic: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Thread-Index: AQHNzvPr3RuFFj57U0u04fPTF6DjPpgDDvyAgAA98gD//55asA== Date: Fri, 30 Nov 2012 22:00:55 +0000 Message-ID: References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> In-Reply-To: <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.86] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Manfred Lochter , "Sean P. Turner" , Dan Harkins , "rfc-ise@rfc-editor.org" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 22:00:57 -0000 With ECDH, there are two separate EC points that are output by the algorith= m: - There's the public value xG (where x is our secret); this is passed in th= e KE payload - There's the shared secret value xyG (where x is our shared secret, and y = is the peer's secret); this is used in the key derivation function. What RFC5903 says is: - The public value xG will be expressed as explicit x, y coordinates. - The shared secret value xyG (that is, the value we give to the sk generat= ion function) will be only the x coordinate; the y coordinate will not be u= sed. Yes, this implies that doing point compression on the shared secret value d= oesn't make much sense (as point compression discards all but one bit of y = -- the format that RFC5903 chooses already discards all the bits of y). Ho= wever, the argument about point compression was never about the shared secr= et value; instead, it was about the repesentation that appeared in the KE p= ayload (that is, the one that is specified to have both the x and y coordin= ates). As for Dan's question, it was about whether we should validate the public v= alue we get from the peer, well, the public value does have explicit x and = y coordinates, and so it makes sense to check them. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= oav Nir Sent: Friday, November 30, 2012 4:39 PM To: Johannes Merkle Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; rfc-ise@rfc-e= ditor.org Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Ex= change Hi Johannes, Dan't question made me realise something I hadn't noticed before.=20 In section 2.3, the draft says: For the encoding of the key exchange payload and the derivation of the shared secret, the methods specified in [RFC5903] are adopted. In an ECP key exchange in IKEv2, the Diffie-Hellman public value passed in a KE payload consists of two components, x and y, However, according to RFC 5903: The Diffie-Hellman shared secret value consists of the x value of the Diffie-Hellman common value. In fact RFC 5903 replaced 4753 just to say that the encoding consists only = of x, not both x and y. This also relates to Dan't question. If the y value is missing, what is the= re to verify? Yoav On Nov 30, 2012, at 7:57 PM, Dan Harkins wrote: >=20 > Hi Johannes, >=20 > On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: >> We have submitted a new revision of the Internet Draft on Using the=20 >> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange=20 >> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ >>=20 >> Since there was considerable objection to the point compression=20 >> method in the WG, we have removed this option altogether and define=20 >> only the uncompressed KE payload format, which is in full accordance=20 >> with RFC 5903. >>=20 >>=20 >> Any feedback is welcome. >=20 > I see that there is a requirement that an implementation MUST verify=20 > that the D-H common value is not the point-at-infinity. Do you think=20 > there should also be a requirement that an implementation MUST verify=20 > that the x- and y-coordinates received from a peer satisfy the=20 > equation of the negotiated curve (and abort the exchange if not)? >=20 > regards, >=20 > Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From dharkins@lounge.org Fri Nov 30 14:09:08 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F52121F8659 for ; Fri, 30 Nov 2012 14:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3HmQY0gFICJ for ; Fri, 30 Nov 2012 14:09:07 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id B012D21F8495 for ; Fri, 30 Nov 2012 14:09:07 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D074510224050; Fri, 30 Nov 2012 14:09:06 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 30 Nov 2012 14:09:07 -0800 (PST) Message-ID: <2597e22bba80eae78e590f08ac4b65ed.squirrel@www.trepanning.net> In-Reply-To: <50B91F37.1010503@gmail.com> References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <50B91F37.1010503@gmail.com> Date: Fri, 30 Nov 2012 14:09:07 -0800 (PST) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Johannes Merkle , Manfred Lochter , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , Scott Fluhrer , "Turner, Sean P." Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 22:09:08 -0000 On Fri, November 30, 2012 1:03 pm, Yaron Sheffer wrote: > The problem I have with this discussion is, this check (if really > required) should have been in the base protocol, because the protocol > has supported EC groups from day one. It doesn't belong in a specific > curve definition. We could use the errata process to add it. It's not > ideal, but certainly better than republishing RFC 5996. Yes, this check is required for the reasons Scott explained. I think "the protocol has supported EC groups from day one" is a bit of an overstatement. EC support was poorly defined as the protocol says that g^ir is the shared secret and it's an octet string. That's it. Many people who were familiar with ECDH assumed that, when doing ECDH, that octet string is just the x-coordinate of the point that results from completing the exchange. (Note: it's bad for protocols to leave it up to the reader to assume). Then along came RFC 4753 that said the concatenation of the x- and y-coordinates (in that order) was the thing that was "used in the formation of SKEYSEED." Well that screwed up all the people who (rightly) assumed that it was just the x-coordinate. This was realized a bit late so now we have RFC 5903 which obsoletes RFC 4753 that says the ECDH shared secret is the x-coordinate. Unfortunately, RFC 5114 adds two more ECP groups-- 25 and 26- but says that the format of the shared secret for them is per 4753, i.e. the wrong way. And RFC 5114 has not (yet) been obsoleted to fix that. So we can have an IKEv2-compliant implementation from prior to June 2010 that will not interoperate with an IKEv2-compliant implementation after June 2010. And to be a truly RFC-compliant implementation it would mean that you represent the ECDH shared secret differently for P256 and P224. Yuck, what a mess. A recipe for spagetti code. RFC 5996 followed this mess but did nothing to specify what is the right behavior for ECDH while it was obsoleting RFC 4306. While I tend to agree that specification of this critical issue should not be left to the RFC that defines the curve that horse has already left the barn for IKEv2. As far as republishing RFC 5996 is concerned, I think a better approach would be to acknowledge that interoperability is problematic with IKEv2 and there's not much we can do about it now, so the best way to proceed is to obsolete it before it gets traction in the field. And I know a draft that can do just that! regards, Dan. > Thanks, > Yaron > > On 11/30/2012 08:26 PM, Scott Fluhrer (sfluhrer) wrote: >> There should *absolutely* be a requirement that any point you receive >> from the peer is actually a point on the curve. >> >> What can happen if you don't? Well, that depends on the implementation >> of the point addition/doubling; what happens with the normal >> implementation is that it acts as if it was a different curve with a >> different curve order -- this means that someone introducing a bogus >> value can give us a point with a small order (which can't happen with >> the normal Brainpool curves, because those curves have prime orders). >> >> In addition, validating the values is cheap; easily worth the gain. >> >> >> Also, given the you validate the peer's value, and forbid public points >> which are the point-at-infinity, doubling checking that the D-H common >> value is not the point at infinity appears to be unneeded. The >> Brainpool Curves are (again) of prime order; this implies that the D-H >> common value is the point at infinity only if the peer's public value is >> the point at infinity (which ought to be forbidden), or our secret value >> is a multiple of the curve order (in which case, our public value is the >> point at infinity). >> >> >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Dan Harkins >> Sent: Friday, November 30, 2012 12:57 PM >> To: Johannes Merkle >> Cc: IPsecme WG; Manfred Lochter; Turner, Sean P.; rfc-ise@rfc-editor.org >> Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key >> Exchange >> >> >> Hi Johannes, >> >> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: >>> We have submitted a new revision of the Internet Draft on Using the >>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange >>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ >>> >>> Since there was considerable objection to the point compression method >>> in the WG, we have removed this option altogether and define only the >>> uncompressed KE payload format, which is in full accordance with RFC >>> 5903. >>> >>> >>> Any feedback is welcome. >> >> I see that there is a requirement that an implementation MUST verify >> that the D-H common value is not the point-at-infinity. Do you think >> there should also be a requirement that an implementation MUST verify >> that the x- and y-coordinates received from a peer satisfy the >> equation of the negotiated curve (and abort the exchange if not)? >> >> regards, >> >> Dan. >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > From ynir@checkpoint.com Fri Nov 30 14:27:36 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7326A21F8699 for ; Fri, 30 Nov 2012 14:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.289 X-Spam-Level: X-Spam-Status: No, score=-10.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zYxcbfLs2yd for ; Fri, 30 Nov 2012 14:27:35 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 46EF321F8688 for ; Fri, 30 Nov 2012 14:27:35 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qAUMRJBQ002766; Sat, 1 Dec 2012 00:27:19 +0200 X-CheckPoint: {50B932BC-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.14]) by IL-EX10.ad.checkpoint.com ([194.29.34.147]) with mapi id 14.02.0318.004; Sat, 1 Dec 2012 00:27:19 +0200 From: Yoav Nir To: "Scott Fluhrer (sfluhrer)" Thread-Topic: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange Thread-Index: AQHNzvPvKh0P6YfEsUabMlIh19DBmZgCiN+AgAA98oCAAAYXgIAAB18A Date: Fri, 30 Nov 2012 22:27:18 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277210EDCE792@IL-EX10.ad.checkpoint.com> References: <50B8A287.9090509@secunet.com> <074557eff2f722f10198aac4fb2f8d9c.squirrel@www.trepanning.net> <4613980CFC78314ABFD7F85CC30277210EDCE571@IL-EX10.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.170] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Johannes Merkle , Manfred Lochter , Dan Harkins , IPsecme WG , "rfc-ise@rfc-editor.org" , "Sean P. Turner" Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 22:27:36 -0000 Right. I cut-and-pasted and didn't notice that it said "shared secret". Nev= er mind.=20 On Dec 1, 2012, at 12:00 AM, Scott Fluhrer (sfluhrer) = wrote: > With ECDH, there are two separate EC points that are output by the algori= thm: >=20 > - There's the public value xG (where x is our secret); this is passed in = the KE payload > - There's the shared secret value xyG (where x is our shared secret, and = y is the peer's secret); this is used in the key derivation function. >=20 > What RFC5903 says is: > - The public value xG will be expressed as explicit x, y coordinates. > - The shared secret value xyG (that is, the value we give to the sk gener= ation function) will be only the x coordinate; the y coordinate will not be= used. >=20 > Yes, this implies that doing point compression on the shared secret value= doesn't make much sense (as point compression discards all but one bit of = y -- the format that RFC5903 chooses already discards all the bits of y). = However, the argument about point compression was never about the shared se= cret value; instead, it was about the repesentation that appeared in the KE= payload (that is, the one that is specified to have both the x and y coord= inates). >=20 > As for Dan's question, it was about whether we should validate the public= value we get from the peer, well, the public value does have explicit x an= d y coordinates, and so it makes sense to check them. >=20 >=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of= Yoav Nir > Sent: Friday, November 30, 2012 4:39 PM > To: Johannes Merkle > Cc: IPsecme WG; Manfred Lochter; Sean P. Turner; Dan Harkins; rfc-ise@rfc= -editor.org > Subject: Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key = Exchange >=20 > Hi Johannes, >=20 > Dan't question made me realise something I hadn't noticed before.=20 >=20 > In section 2.3, the draft says: > For the encoding of the key exchange payload and the derivation of > the shared secret, the methods specified in [RFC5903] are adopted. >=20 > In an ECP key exchange in IKEv2, the Diffie-Hellman public value > passed in a KE payload consists of two components, x and y, >=20 > However, according to RFC 5903: > The Diffie-Hellman shared secret value consists of the x value of > the Diffie-Hellman common value. >=20 > In fact RFC 5903 replaced 4753 just to say that the encoding consists onl= y of x, not both x and y. >=20 > This also relates to Dan't question. If the y value is missing, what is t= here to verify? >=20 > Yoav >=20 > On Nov 30, 2012, at 7:57 PM, Dan Harkins wrote: >=20 >>=20 >> Hi Johannes, >>=20 >> On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: >>> We have submitted a new revision of the Internet Draft on Using the=20 >>> ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key Exchange=20 >>> https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ >>>=20 >>> Since there was considerable objection to the point compression=20 >>> method in the WG, we have removed this option altogether and define=20 >>> only the uncompressed KE payload format, which is in full accordance=20 >>> with RFC 5903. >>>=20 >>>=20 >>> Any feedback is welcome. >>=20 >> I see that there is a requirement that an implementation MUST verify=20 >> that the D-H common value is not the point-at-infinity. Do you think=20 >> there should also be a requirement that an implementation MUST verify=20 >> that the x- and y-coordinates received from a peer satisfy the=20 >> equation of the negotiated curve (and abort the exchange if not)? >>=20 >> regards, >>=20 >> Dan. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Email secured by Check Point