From paul.hoffman@vpnc.org Wed Oct 2 09:16:06 2013 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 4D45921F9926 for ; Wed, 2 Oct 2013 09:16:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0HPLlLMrUSx for ; Wed, 2 Oct 2013 09:15:56 -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 856BF21F9AE2 for ; Wed, 2 Oct 2013 09:14:30 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r92GDsmw022468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 2 Oct 2013 09:14:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <59B98C2D-ED10-4B68-A6AE-DF9FEE3BADCF@vpnc.org> Date: Wed, 2 Oct 2013 09:14:29 -0700 To: "ipsec@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 02 Oct 2013 16:16:06 -0000 Greetings again. As we announced, we will be having a virtual interim meeting next = Wednesday, October 9. The agenda is: - Detailed presentations of two AD VPN drafts: draft-detienne-dmvpn-00 = and draft-mao-ipsecme-ad-vpn-protocol-02. [This is the main focus of the = meeting.] - A short discussion of draft-ietf-ipsecme-esp-ah-reqts-01. To ensure an effective discussion, we request WG members to have a quick = review of the two AD VPN drafts. We suggest that you don't review any of = them in detail, instead just consider whether the proposed approach = seems to be technically sound and in line with the AD VPN requirements. = Please send a short email to the list regarding one of the drafts (or, = preferably one email about each) by Wednesday of this week, so we can = start a discussion on the mailing list that will help the discussion at = the virtual interim meeting. Thanks, Paul and Yaron From ynir@checkpoint.com Wed Oct 2 11:49:25 2013 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 6BB8D21F9E45 for ; Wed, 2 Oct 2013 11:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.574 X-Spam-Level: X-Spam-Status: No, score=-9.574 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpUlqetdFXEi for ; Wed, 2 Oct 2013 11:49:13 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 73F3621F9E44 for ; Wed, 2 Oct 2013 11:44:34 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r92IiNIN016089; Wed, 2 Oct 2013 21:44:28 +0300 X-CheckPoint: {524C6987-8-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Wed, 2 Oct 2013 21:44:24 +0300 From: Yoav Nir To: Paul Hoffman Thread-Topic: [IPsec] NUDGE: Reviewing the AD VPN drafts Thread-Index: AQHOv4q8Jl2BZkK4jkym/RtXzK/zWpnhjXKA Date: Wed, 2 Oct 2013 18:44:23 +0000 Message-ID: References: <59B98C2D-ED10-4B68-A6AE-DF9FEE3BADCF@vpnc.org> In-Reply-To: <59B98C2D-ED10-4B68-A6AE-DF9FEE3BADCF@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.2] 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: "ipsec@ietf.org WG" Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 02 Oct 2013 18:49:25 -0000 Hi I have read the DM-VPN draft. I would not call my reading a review, as it w= as quite superficial, but here's some thoughts: - I have to admit that I'm still having trouble wrapping my head around som= e of the concepts. I understand domain-based and route-pased VPNs, as well = as IPsec and GRE tunnels. But I haven't thought of all the VPN endpoints as= actually being on the same network. In fact I always thought of VPN as an = abstract concept or as a bunch of tunnels, not as a real network. Having sa= id that, I'm still trying to get used to the idea of NHRP being used for di= scovery (and to the idea of NHRP itself). To my mind a VPN is not an NBMA, = but that does not mean an NBMA cannot serve as a good model for a VPN. - I like how the process described in section 4.3 to 4.6 quickly converges.= If host a behind gateway A sends packets to host e behind gateway E, and t= he packets travel though the tunnels AB, BC, CD, and DE, then the discovery= process might go through several hops, but the next tunnel to be set up is= AE. There is no case of setting up AC or AD. - Reading section 4.8, I see that within a single DM-VPN, there is a natura= l progression from hub&spoke to mesh. There doesn't seem to be a place for = policy on whether a shortcut should or should not be established. The resol= ution request is forwarded until the egress node. So if, for example, you h= ave two government agencies, each with its own set of gateways, and two gat= eways (one belonging to each agency) have a tunnel between them, there are = two possible configurations: a single DM-VPN, in which case they become a m= esh, or two DM-VPNs, so that the interdomain tunnel endpoints are egress no= des on their respective DM-VPNs. Is there a way to implement a policy so th= at some shortcuts are created between those other gateways? - Section 4.10 seems to be missing something. Suppose gateway A is forwardi= ng traffic to gateway B, and receives an Indirection notification. So A sen= ds a Resolution request. After a while, it receives a Resolution reply with= TunS2 and PubS2 addresses. So now A should open a tunnel with TunS2 (right= ? I'm not clear about the fields). So section 4.10 says that authentication= between these two nodes will be done using certificates. Considering that = A has only just heard of TunS2's existence, what fields are there going to = be in the certificate that will let A know that this is indeed TunS2? While= a single domain might have some convention for this, AD-VPN is supposed to= be good for multiple administrative domains, so there should be some rule = about this. - The same section hints at using certificate fields for filtering. This so= unds weird. Suppose two gateways learn of each other through the resolution= process. Now they try to connect, only to find out that the certificate fi= elds do not allow them to connect. So we've gone through an entire IKE hand= shake just to discover that policy prohibits forming this tunnel? And becau= se caches expire, the gateways will try again and again to form this tunnel= , all the time failing on authorization.=20 Yoav From mcr@sandelman.ca Thu Oct 3 07:03:52 2013 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 3793221F8578 for ; Thu, 3 Oct 2013 07:03:52 -0700 (PDT) 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_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtZxDENt9wNf for ; Thu, 3 Oct 2013 07:03:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id E32B821E8063 for ; Thu, 3 Oct 2013 06:57:12 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4EF8A2017B; Thu, 3 Oct 2013 11:06:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1F51D63B18; Thu, 3 Oct 2013 09:57:10 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 099DF63AED; Thu, 3 Oct 2013 09:57:10 -0400 (EDT) From: Michael Richardson To: Yoav Nir In-Reply-To: References: <59B98C2D-ED10-4B68-A6AE-DF9FEE3BADCF@vpnc.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "ipsec@ietf.org WG" , Paul Hoffman Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 03 Oct 2013 14:03:52 -0000 --=-=-= I've also read both documents. Yoav Nir wrote: > itself). To my mind a VPN is not an NBMA, but that does not mean an > NBMA cannot serve as a good model for a VPN. I agree. I like the idea of thinking of it as an NBMA, but not the idea of using the layer-2 protocol *directly*. It is clearly a quick (but Brilliant!) hack inside IOS to reuse some layer-2 ATM code over a WAN. I also do not like the lack of policy control that GRE/IPsec implies, specifically it directly leads to LPM only routing, and your comment: > natural progression from hub&spoke to mesh. There doesn't seem to be a > place for policy on whether a shortcut should or should not be > established. This is really a direct result. It's not clear to me what prevents parts of the mesh from impersonating other parts, etc. ====== I also read: draft-mao-ipsecme-ad-vpn-protocol and while conceptually I found it okay, I think that the protocol should be inside IKE. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUk13s4qHRg3pndX9AQKAYAQAixC8afgYSIXAMtLMXVtPiGvXlh3o1bgA CCjXw+4QqvjfyK+YD+uGZH/At3RkPBb5cXL7lYkkjZ7HTUkzoU8gF127p9YecPgJ GMTfnqICIXaMCMsOv8SSzmeJbcgBKxTkNvGMPKgguZRY6eVxwMayj14WHsM5dWPm deLQz6jnwkI= =ZOsj -----END PGP SIGNATURE----- --=-=-=-- From ynir@checkpoint.com Thu Oct 3 14:29:32 2013 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 1B34721F856A for ; Thu, 3 Oct 2013 14:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.959 X-Spam-Level: X-Spam-Status: No, score=-9.959 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 425de2HrG3X0 for ; Thu, 3 Oct 2013 14:29:20 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E2E5621E8090 for ; Thu, 3 Oct 2013 14:21:23 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r93LLHNV010287; Fri, 4 Oct 2013 00:21:17 +0300 X-CheckPoint: {524DDFCD-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Fri, 4 Oct 2013 00:21:17 +0300 From: Yoav Nir To: Michael Richardson Thread-Topic: [IPsec] NUDGE: Reviewing the AD VPN drafts Thread-Index: AQHOv4q8Jl2BZkK4jkym/RtXzK/zWpnhjXKAgAFCFgCAAHwRgA== Date: Thu, 3 Oct 2013 21:21:16 +0000 Message-ID: References: <59B98C2D-ED10-4B68-A6AE-DF9FEE3BADCF@vpnc.org> <14105.1380808630@sandelman.ca> In-Reply-To: <14105.1380808630@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.46] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <44195EE63A079D4FA70F9531DD57ACDE@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 03 Oct 2013 21:29:32 -0000 On Oct 3, 2013, at 4:57 PM, Michael Richardson wrot= e: >=20 >=20 > I also read: draft-mao-ipsecme-ad-vpn-protocol and while conceptually I f= ound > it okay, I think that the protocol should be inside IKE. Funny, I came to the opposite conclusion. I think it's too much like IKE. But actually, this should be split in two.=20 ADC to ADC communications, like the REDIRECT and SESSION could easily run o= ver an Informational exchange in IKE.=20 But the ADC to ADS communications are, to quote section 1.1, "a client and = server protocol". And there is no reason to assume that the ADS can even do= IKE - it's a controller. So I think those parts of the protocol could be d= one in a web service. But, why am I designing someone else's proposal? From ynir@checkpoint.com Thu Oct 3 14:46:51 2013 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 89C2921F8578 for ; Thu, 3 Oct 2013 14:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T42EMvAZquPE for ; Thu, 3 Oct 2013 14:46:39 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDB11F0D21 for ; Thu, 3 Oct 2013 14:46:37 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r93LkSq9018145; Fri, 4 Oct 2013 00:46:32 +0300 X-CheckPoint: {524DE5B4-D-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Fri, 4 Oct 2013 00:46:28 +0300 From: Yoav Nir To: Paul Hoffman Thread-Topic: [IPsec] NUDGE: Reviewing the AD VPN drafts Thread-Index: AQHOv4q8Jl2BZkK4jkym/RtXzK/zWpnjUqaA Date: Thu, 3 Oct 2013 21:46:28 +0000 Message-ID: References: <59B98C2D-ED10-4B68-A6AE-DF9FEE3BADCF@vpnc.org> In-Reply-To: <59B98C2D-ED10-4B68-A6AE-DF9FEE3BADCF@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.46] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <4966CA91DCA89B4EA7BE99375ADF7907@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 03 Oct 2013 21:46:51 -0000 Hi There is something that I think is missing from all three proposals, and th= at is the handling of duplicate protected networks. As long as we live in a= predominantly IPv4 world, we have a lot of NATs and a lot of RFC 1918 addr= esses. So unprotected traffic from such networks gets NATted by the perimeter gate= way (or a dedicated device between the gateway and the Internet). For prote= cted traffic, there qre two options: 1. Translate the traffic before sending it through the tunnel, or 2. Send packets from non-routable addresses through the tunnel Option #1 has a weird side effect. If the translated address is a routable = address of the gateway, the peer gateway cannot forward it to the Internet = without translating it again: the return packets would go directly to the o= riginal gateway, creating some asymmetric routing. So let's assume option #2, the other tunnel endpoint will NAT the traffic b= ehind itself if it forwards the traffic to the Internet. If it forwards the= traffic through another tunnel, it has the same choices as the first gatew= ay. But if it forwards the traffic to its own protected domain, it has two = options 1. Forward them as is. That requires that there be no duplicates, and that = routing will be set up so that return packets go to this gateway., or 2. NAT the packets behind itself. There are more subtleties to this, but it's a complexity that network peopl= e deal with all the time. The NATs are configured where appropriate, and co= llisions are avoided through a combination of NATs and a manual partitionin= g of the RFC 1918 space. All this goes out the window the moment you try to connect with other admin= istrative domains or worse - merge some administrative domains. And a dynam= ic setup of tunnels runs a high risk of having the same network on both sid= es of the tunnel.=20 Consider the trivial example. Host a, behind gateway A, sends traffic to ho= st c behind gateway C, but the traffic goes through gateway B, which is the= hub gateway. c is a server, so it has port forwarding on gateway C, and C = belongs to another organization. A is the gateway of a branch office. Every= branch office has a different 192.168.x.0/24 subnet, so within the adminis= trative domain, all hosts have unique IPs.=20 So A sends the ac packet unmodified. B is an egress gateway, so it NATs all= such addresses behind itself. That's OK because a is a client. Now, regardless of which solution we choose, it is decided that A should se= nd traffic directly to C, skipping B. But that means that A should now NAT = the packets, because C does not wish to receive non-routable IP addresses f= rom a partner. It has its own 192.168.x.x addresses within its network. Bu= t here's a problem. Regardless of whether A does or does not NAT when sendi= ng traffic to C, connections are going to be severed. Why? Because the sour= ce IP address of the traffic coming from 'a' changes. Before 'c' got the tr= affic from B's public address. But now it's coming either from 'a''s non-ro= utable address, or from A's public address. Either way, TCP connections get= severed. I don't think this issue is addressed in any of the current drafts. Yoav = From mcr@sandelman.ca Thu Oct 3 16:31:54 2013 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 30CB711E80DC for ; Thu, 3 Oct 2013 16:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_BACKHAIR_33=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx-tgzao-yd0 for ; Thu, 3 Oct 2013 16:31:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA3D21F8DA3 for ; Thu, 3 Oct 2013 16:31:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DEC7A2017A; Thu, 3 Oct 2013 20:40:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B416463B18; Thu, 3 Oct 2013 19:30:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A293963AED; Thu, 3 Oct 2013 19:30:54 -0400 (EDT) From: Michael Richardson To: Yoav Nir In-Reply-To: References: <59B98C2D-ED10-4B68-A6AE-DF9FEE3BADCF@vpnc.org> <14105.1380808630@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 03 Oct 2013 23:31:54 -0000 --=-=-= Yoav Nir wrote: >> I also read: draft-mao-ipsecme-ad-vpn-protocol and while conceptually >> I found it okay, I think that the protocol should be inside IKE. > Funny, I came to the opposite conclusion. I think it's too much like > IKE. > But actually, this should be split in two. > ADC to ADC communications, like the REDIRECT and SESSION could easily > run over an Informational exchange in IKE. I agree. > But the ADC to ADS communications are, to quote section 1.1, "a client > and server protocol". And there is no reason to assume that the ADS can > even do IKE - it's a controller. So I think those parts of the protocol > could be done in a web service. I think that the right model to think about here is EAP, IKE, Radius. I think that the much of the ADC<->ADS protocol is EAP-like in nature. I think that it should be carried in IKE, much like EAP is, to a hub. The Hubs (which are small in number, and are well managed) would speak carry ADVPN in PROTOCOL X, to the ADS. Protocol X may well be TCP over IPsec, or just TCP, or maybe it's RESTful HTTP(s). I don't think it matters a hoot if the ADS can do IPsec. It's IKE. IKE is a UDP based protocol, and if you remove the IPsec requirement, it's just another deamon. It is the *HUB* and the *SPOKES* where I think one wants to remove as many moving parts as possible, and in particular, remove any additional firewall/policy complexity. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUk3+JYqHRg3pndX9AQLzPAP9HLqsX3dODKE3FoKVQIfUKJAU+YWcRivv 3ihxW09GUNWgOX+w5vw9VbYnDghtTFkzcb02L6LQaAOkI14ZkJ2WDLTZWdVxqZoN ZwWXGpqKAouqNeSKxPbT9qW2v9F1BDklI9bvYwkARFo3AajcarQpZ1w/jvq6MDNf ci47KEOCV80= =I951 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Oct 3 16:46:48 2013 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 A092411E80FE for ; Thu, 3 Oct 2013 16:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5U6vtH9ol31 for ; Thu, 3 Oct 2013 16:46:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC2121F8495 for ; Thu, 3 Oct 2013 16:46:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 41F7D2017A for ; Thu, 3 Oct 2013 20:55:59 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6AA7E63B18; Thu, 3 Oct 2013 19:46:12 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5CA2363781 for ; Thu, 3 Oct 2013 19:46:12 -0400 (EDT) From: Michael Richardson To: "ipsec\@ietf.org WG" In-Reply-To: References: <59B98C2D-ED10-4B68-A6AE-DF9FEE3BADCF@vpnc.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 03 Oct 2013 23:46:48 -0000 --=-=-= Yoav Nir wrote: > There is something that I think is missing from all three proposals, > and that is the handling of duplicate protected networks. As long as we > live in a predominantly IPv4 world, we have a lot of NATs and a lot of > RFC 1918 addresses. That's one of the reasons I think that it should run inside IKE, so that we don't have issues of how the spokes talk to the "ADS"... > All this goes out the window the moment you try to connect with other > administrative domains or worse - merge some administrative > domains. And a dynamic setup of tunnels runs a high risk of having the > same network on both sides of the tunnel. I think that connecting multiple adminstrative domains together just won't work. You have to go through a HUB machine that does the appropriate (double?) NAT. Further, you simply have no way to know, when the client says he wants to talk to 192.168.1.1, which machine they mean. So: 1) protocol must support IPv6. 2) protocol SHOULD support doing lookups using IPv4-mapped IPv6 addresses I'm thinking about some variations of RFC 6333 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion being used, but I have to think about it more. Consider further how a Teredo-type IPv6 address can incorporate an IPv4 + port number, and if one then does *ADVPN* for that address... 3) It's less of a big deal to connect the two adminstrative domains given ADVPN: one can have as many NAT44 machines as one needs to get the job done, and they can be distributed into as many data centres as one likes, because the ADVPN protocol would just direct the spokes in a consistent and load balanced way. 4) IPv6 traffic goes direct, or goes through a NAT'ess ADVPN router. One still has the problem that two end systems have difficulty addressing each other, but potentially the address each gets NAT'ed to that leads to the other system could concievably be managed by the same ADVPN multi-realm hub. > Now, regardless of which solution we choose, it is decided that A > should send traffic directly to C, skipping B. But that means that A > should now NAT the packets, because C does not wish to receive > non-routable IP addresses from a partner. It has its own 192.168.x.x > addresses within its network. But here's a problem. Regardless of > whether A does or does not NAT when sending traffic to C, connections > are going to be severed. Why? Because the source IP address of the > traffic coming from 'a' changes. Before 'c' got the traffic from B's > public address. But now it's coming either from 'a''s non-routable > address, or from A's public address. Either way, TCP connections get > severed. What you say is true. But, if the goal is to shortcut things like media traffic, then it might be okay. The media setup protocol may be able to deal with the changes to the addresses/port numbers. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUk4BwoqHRg3pndX9AQJ3zQQAquHqVsZfAtIrInU4C33+72F6ia4KekEA ktLTOK/ASnUPQUfcjzUdQnAdHjbcVsJXNd50bz/A9gd8UOnUSCq13KYwMvDmrzS5 79Vdf6uc96/By3FMrDo1R19f6na02Rpa+3V/N/DBTfgnesukmX2KTpAo9RnO/MJk 2uNE00oYHsU= =RxhN -----END PGP SIGNATURE----- --=-=-=-- From internet-drafts@ietf.org Fri Oct 4 05:46:59 2013 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 96F7521F88BA; Fri, 4 Oct 2013 05:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPUOSEL1m+3j; Fri, 4 Oct 2013 05:46:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D573321F9C78; Fri, 4 Oct 2013 05:35:52 -0700 (PDT) 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.80 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> Date: Fri, 04 Oct 2013 05:35:52 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 12:46:59 -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 : IKEv2 Fragmentation Author(s) : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-fragmentation-03.txt Pages : 20 Date : 2013-10-04 Abstract: This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ikev2-fragmentation-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From svanru@gmail.com Fri Oct 4 06:08:43 2013 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 52DD621F99B0 for ; Fri, 4 Oct 2013 06:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZtv27-YyabF for ; Fri, 4 Oct 2013 06:08:36 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D840121F9A6C for ; Fri, 4 Oct 2013 05:57:00 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id eh20so3180524lab.18 for ; Fri, 04 Oct 2013 05:56:48 -0700 (PDT) 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; bh=aJ+mMKcdbvMsHR1aWFxL1m4a65Qf4egcnAbTlUr1bxU=; b=LfHWlC9nQp5fN21B///LTmVcgMma87+raS1m0RR2TmuVs1FDxkXcNSPs/yrVLNl2vS 8nhYN2g2577kEBJ2u+zCNtdrdooxs/+wdYs7sY/4MTg0FEWrWiKK1BEz9EI4/7mSjIjO HjfDU0FRjJUEYNM0mF0QGMZQDWLyUtltx7dTRZJi+5/4S/QEAtt2OZxztpWWw6f/rI/Q LsXFLEoInLeJ49u6tdn5gXaqVs1sx14+YWSs9XX9WHdOdGSCIEyC2zPYuGTRqYBX/p5M WaICTcIQAVSei0N8qABons7YpYJ/J4Mk6SREaRWayTEfo3pCcphmT7NFhJTD5gAE7OJ7 vCJg== X-Received: by 10.152.8.12 with SMTP id n12mr11868808laa.10.1380891408841; Fri, 04 Oct 2013 05:56:48 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id vx8sm8747681lbb.8.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 04 Oct 2013 05:56:47 -0700 (PDT) Message-ID: <44D6A1836A274C98907D95D59E530FE6@buildpc> From: "Valery Smyslov" To: References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> Date: Fri, 4 Oct 2013 16:56:44 +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] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Fri, 04 Oct 2013 13:08:43 -0000 Hi all, I've just posted new version of IKEv2 Fragmentation draft. Comparing with -02 version it clarifies Initiator's behaviour with regard to retransmissions. Regards, Valery Smyslov. ----- Original Message ----- From: To: Cc: Sent: Friday, October 04, 2013 4:35 PM Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > > Title : IKEv2 Fragmentation > Author(s) : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-fragmentation-03.txt > Pages : 20 > Date : 2013-10-04 > > Abstract: > This document describes the way to avoid IP fragmentation of large > IKEv2 messages. This allows IKEv2 messages to traverse network > devices that don't allow IP fragments to pass through. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Fri Oct 4 06:54:01 2013 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 AE89121F9B9F for ; Fri, 4 Oct 2013 06:54:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYaLOB8b5xXJ for ; Fri, 4 Oct 2013 06:53:45 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id D347F21F9C7D for ; Fri, 4 Oct 2013 06:47:21 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cb5so1670561wib.10 for ; Fri, 04 Oct 2013 06:47:21 -0700 (PDT) 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=mRCv83Y6dq3WxJKg7BSMPAqlfKVqfjLqTTgPK/iuhuI=; b=qRieh54sQWvIscPYWuiqUd0jPpv7BybiEFnecFUXaVVty3Jkzp+v/eykJi5DkPJCGe z6aayRPlTrjiHKam93xQToeyhJlBc1BGTdO0HDcJ8M4GXA+A3FtOZ6pFXKuHRSEdHT9R 4TsLH4a+ESzrhv5ZIp5Y9iyOOfrecWZdL5S/2mZe1Q9EXE6In8gm0gb9vvSFIwSW4uyy xsvoNEW8SVsHuVDf/gwQ7Xmc31HB4j0aMPICjreBgpkoVZX473KD/JyCLS466WyV2O0g urHulTBODJQtBwfEXa7n23ffVg5JbdbStMQyHs5G3NhB0oeuttltnJWQMOas7OWWCnzf soYw== X-Received: by 10.194.19.5 with SMTP id a5mr1956307wje.48.1380894441031; Fri, 04 Oct 2013 06:47:21 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-181-221-227.red.bezeqint.net. [79.181.221.227]) by mx.google.com with ESMTPSA id e5sm10157872wiy.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Oct 2013 06:47:20 -0700 (PDT) Message-ID: <524EC6D8.9040006@gmail.com> Date: Fri, 04 Oct 2013 16:47:04 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Valery Smyslov References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> In-Reply-To: <44D6A1836A274C98907D95D59E530FE6@buildpc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Fri, 04 Oct 2013 13:54:01 -0000 Hi Valery, thanks for the update. A question about some text that's not new to -03: Quoting from Sec. 2: If Responder receives IKE Fragment Message after it received, successfully verified and processed regular message with the same Message ID, it means that response message didn't reach Initiator and it activated IKE Fragmentation. If Fragment Number in Encrypted Fragment Payload in this message is equal to 1, Responder MUST fragment its response and retransmit it back to Initiator in fragmented form. I think the MUST in the second sentence is incorrect. Assume the sender switched to fragmented form, but the responder knows that it sent a very short response. The response got lost, but this is unrelated to fragmentation. So the responder should simply retransmit it as-is, and there's no reason to fragment it. Also I'm not happy with the first part of the new text (last paragraph of Sec. 2), which adds complexity for both sender and responder. The sender must ensure that when it re-fragments the message, the fragment count is indeed higher (so it cannot use a simple table of possible fragment sizes). And the receiver must add the number of fragments into its IKE-level retransmit logic. I understand why this might be needed sometimes, but is the added flexibility (allowing to retry different fragment sizes) worth the complexity? Thanks, Yaron On 4.10.2013 15:56, Valery Smyslov wrote: > Hi all, > > I've just posted new version of IKEv2 Fragmentation draft. > Comparing with -02 version it clarifies Initiator's behaviour > with regard to retransmissions. > > Regards, > Valery Smyslov. > > > ----- Original Message ----- From: > To: > Cc: > Sent: Friday, October 04, 2013 4:35 PM > Subject: [IPsec] I-D Action: > draft-ietf-ipsecme-ikev2-fragmentation-03.txt > > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the IP Security Maintenance and >> Extensions Working Group of the IETF. >> >> Title : IKEv2 Fragmentation >> Author(s) : Valery Smyslov >> Filename : draft-ietf-ipsecme-ikev2-fragmentation-03.txt >> Pages : 20 >> Date : 2013-10-04 >> >> Abstract: >> This document describes the way to avoid IP fragmentation of large >> IKEv2 messages. This allows IKEv2 messages to traverse network >> devices that don't allow IP fragments to pass through. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-03 >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 svanru@gmail.com Fri Oct 4 08:03:31 2013 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 5695E21F9C46 for ; Fri, 4 Oct 2013 08:03:31 -0700 (PDT) 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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xbFCkNy0yta for ; Fri, 4 Oct 2013 08:03:24 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D687E21F967A for ; Fri, 4 Oct 2013 07:59:35 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id ep20so3377388lab.29 for ; Fri, 04 Oct 2013 07:59:34 -0700 (PDT) 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; bh=2FU9X/vQbTakLJcAbLZFwJgpdsh0D1qvcdu6NVENEto=; b=ADo4zMCJz+hyzaEugPh6ZDcj5F5Xy5HFriHqprUMPjrJt2pnNZf69H5tM0RP6mBdsi 6Z4yiuzGky1aeSvpIScR2UZAM9UrdybK5bMxF9VR0fDASPh9KPOamfmS5RRfKcoH/ybK qkO2Q3EkLMG8diT1nImxjQSCikeMxt28rKO/1k80F+O29OW6mqr1fHfYoo/VMOVTmhiq g95zkvQFEyxchA5PspflZKBvewHNQ6WjaRWr3Y/FqksVX5+ouA6qstfcxQHfodgUra0W JJDf8xFw52GRxeu749l82RD6KTAvK5AqgVqBVFf401R+W/q5TGCosdkHYuZo+yDUNi5V ciow== X-Received: by 10.112.77.134 with SMTP id s6mr1963513lbw.38.1380898774703; Fri, 04 Oct 2013 07:59:34 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id n15sm11444775laa.2.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 04 Oct 2013 07:59:33 -0700 (PDT) Message-ID: <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> Date: Fri, 4 Oct 2013 18:59:30 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response 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] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Fri, 04 Oct 2013 15:03:31 -0000 Hi Yaron, > If Responder receives IKE Fragment Message after it received, successfully > verified and processed regular message with the same Message ID, it means > that response message didn't reach Initiator and it activated IKE > Fragmentation. If Fragment Number in Encrypted Fragment Payload in this > message is equal to 1, Responder MUST fragment its response and retransmit > it back to Initiator in fragmented form. > > I think the MUST in the second sentence is incorrect. Assume the sender > switched to fragmented form, but the responder knows that it sent a very > short response. The response got lost, but this is unrelated to > fragmentation. So the responder should simply retransmit it as-is, and > there's no reason to fragment it. The idea is that it is Initiator who decides whether to use fragmentation or not, as only he/she is responsible for retransmissions. Responder is just a "slave". And for simplicity we assume that either both use fragmentation or both don't. It is stated in the beginning of Page 5: "Responder MUST send response message in the same form (fragmented or not) as corresponded request message." You are right that it may lead (and actually leads) to "false positive" decisions to use fragmentation in situations when it actually can't help. We may change this logic as follows: Responder MUST fragment its response if it is greater than Responder's fragmentation threshold and SHOULD NOT do it otherwise. Is it OK? In this case the requirement for Responder to use the same form should also be changed to SHOULD (or removed completely). > Also I'm not happy with the first part of the new text (last paragraph of > Sec. 2), which adds complexity for both sender and responder. The sender > must ensure that when it re-fragments the message, the fragment count is > indeed higher (so it cannot use a simple table of possible fragment > sizes). And the receiver must add the number of fragments into its > IKE-level retransmit logic. I understand why this might be needed > sometimes, but is the added flexibility (allowing to retry different > fragment sizes) worth the complexity? That is the question. This is only for PMTU discovery. Still waiting for WG members to discuss whether it is needed. And anyway all this functionality is marked as MAY. "MUST" for ensuring that fragments number is increased after refragmenting is just for fo desire "to be on the safe side" - in real life it will almost always be increased as IKE PMTU discovery is coarse-grained: if you decrease fragment size in half you will get twice as many fragments. And there's no need for IKE to perform fine-grained PMTU discovery, if any. What about the need for responder to take fragments number into consideration, - I don't think it will complicate implementation, just one more field to compare. From paul@cypherpunks.ca Fri Oct 4 08:59:40 2013 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 3484F21F99F0 for ; Fri, 4 Oct 2013 08:59:40 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhKJ2XcLqr8I for ; Fri, 4 Oct 2013 08:59:25 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id A445521F9A90 for ; Fri, 4 Oct 2013 08:57:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3crwh04hRdz9Qs; Fri, 4 Oct 2013 11:57:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ePxD-gdA2TOa; Fri, 4 Oct 2013 11:57:03 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 4 Oct 2013 11:57:02 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 656D4805FD; Fri, 4 Oct 2013 11:57:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3C4CB80097; Fri, 4 Oct 2013 11:57:01 -0400 (EDT) Date: Fri, 4 Oct 2013 11:57:01 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Valery Smyslov In-Reply-To: <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> Message-ID: References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Fri, 04 Oct 2013 15:59:40 -0000 On Fri, 4 Oct 2013, Valery Smyslov wrote: > The idea is that it is Initiator who decides whether to use fragmentation or > not, > as only he/she is responsible for retransmissions. Responder is just a > "slave". > And for simplicity we assume that either both use fragmentation or both > don't. > It is stated in the beginning of Page 5: "Responder MUST send response > message > in the same form (fragmented or not) as corresponded request message." > You are right that it may lead (and actually leads) to "false positive" > decisions to use fragmentation in situations when it actually can't help. > > We may change this logic as follows: > > Responder MUST fragment its response if it is greater than > Responder's fragmentation threshold and SHOULD NOT do it otherwise. > > Is it OK? In this case the requirement for Responder to use the same > form should also be changed to SHOULD (or removed completely). I still think that's not right. A responder might know that it is connected to a network with mtu issues. It should be able to skip the failure of the first response packet not making it by starting out with fragmenting (in ikev1 terms that would be ike_frag=force). I think either end should be able to start fragmentation. Once an endpoint receives a full fragmented packet correctly, it should also send back using fragments. The goal is to reduce latency and retransmissions. On mobile devices with an "always on" VPN, that is really important. (i.e. my iphone is failing at that terribly, but for other reasons) >> Also I'm not happy with the first part of the new text (last paragraph of >> Sec. 2), which adds complexity for both sender and responder. The sender >> must ensure that when it re-fragments the message, the fragment count is >> indeed higher (so it cannot use a simple table of possible fragment sizes). >> And the receiver must add the number of fragments into its IKE-level >> retransmit logic. I understand why this might be needed sometimes, but is >> the added flexibility (allowing to retry different fragment sizes) worth >> the complexity? > > That is the question. This is only for PMTU discovery. Still waiting for WG > members > to discuss whether it is needed. And anyway all this functionality is marked > as MAY. I already think authenticated fragments is adding a lot of logic. Let's not add more. Optimising on size is pointless, just fragment near the minimum packet size. It's going to add what? 1 more fragment? > What about the need for responder to take fragments number > into consideration, - I don't think it will complicate implementation, > just one more field to compare. The word "number" and "id" is confusing in the IKEv1 version. I'm not sure what you are referring to here (I have to re-read the entire draft to give feedback before vancouver) The IKEv1 fragment id is never used. All real world implementations always set it to 1 AFAIK. A peer never really has more then one fragmented IKE packet outstanding with a peer. Perhaps that is different in v2? Paul From svanru@gmail.com Fri Oct 4 10:53:43 2013 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 9108C21F93DB for ; Fri, 4 Oct 2013 10:53:43 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx2WU1qk2R00 for ; Fri, 4 Oct 2013 10:53:42 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5A99C21F9D62 for ; Fri, 4 Oct 2013 10:53:30 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id x18so3589791lbi.17 for ; Fri, 04 Oct 2013 10:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=SwCeQXKtC1wHGADgFVGbDa5Y2MJCwARew0ecy1/Muwc=; b=WvXFZx8z9O8zpvzqAURxqriy3PE8alfx6rPA6j7/gG3HnndWuNgIxXb9pbqzh1L1tg kGe2ScdHqhY3xZdPLhMInI/jWOfvUeISWmYlyWUGCQXVu5HGP5E9K2AhIlhxYhsdz0Jo jWL2AOgj9UV3HUSI6jVffDhrXfMWUEeNWIKUeAj/bQmJi9gVv2KIiEO9CbaiqHZur+bT vwjID3r4I531gBgG0kteNtrPmwIBb/FSzG23OAowIMFIhekxPmpKRDwVUPvypSkNvZHg sai1LO0mOXNyOl2Y6zP0x7uOYghvVlxxBP0DYOFxbja08WtJDxwrb+wNu+9CtG8CkzAV WR4A== X-Received: by 10.112.42.68 with SMTP id m4mr12713080lbl.4.1380909209365; Fri, 04 Oct 2013 10:53:29 -0700 (PDT) Received: from chichi (ppp91-77-179-4.pppoe.mtu-net.ru. [91.77.179.4]) by mx.google.com with ESMTPSA id ur6sm9524358lbc.5.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 04 Oct 2013 10:53:28 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> In-Reply-To: Date: Fri, 4 Oct 2013 21:53:22 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Fri, 04 Oct 2013 17:53:43 -0000 Hi Paul, > > The idea is that it is Initiator who decides whether to use > > fragmentation or not, > > as only he/she is responsible for retransmissions. Responder is just a > > "slave". > > And for simplicity we assume that either both use fragmentation or both > > don't. > > It is stated in the beginning of Page 5: "Responder MUST send response > > message > > in the same form (fragmented or not) as corresponded request message." > > You are right that it may lead (and actually leads) to "false positive" > > decisions to use fragmentation in situations when it actually can't > > help. > > > > We may change this logic as follows: > > > > Responder MUST fragment its response if it is greater than > > Responder's fragmentation threshold and SHOULD NOT do it otherwise. > > > > Is it OK? In this case the requirement for Responder to use the same > > form should also be changed to SHOULD (or removed completely). > > I still think that's not right. A responder might know that it is > connected to a network with mtu issues. It should be able to skip the > failure of the first response packet not making it by starting out with > fragmenting (in ikev1 terms that would be ike_frag=force). > > I think either end should be able to start fragmentation. Once an > endpoint receives a full fragmented packet correctly, it should also > send back using fragments. While I agree with you that ability to start using fragmentation by responder without waiting for fragmented message from initiator is useful in some situations, I still think that in general it is initiator who should turn this option on. In most situations peers will first try to send unfragmented message in hope that it will pass. In this case it is not reliable to rely on responder's logic when to turn fragmentation on, as responder may only respond to retransmitting messages and it doesn't know how many retries initiator will do. So it may decide to fragment message too late. The only exception - the situation you described, when responder always sends messages fragmented. I think we may add this exception to responder's logic. > >> Also I'm not happy with the first part of the new text (last paragraph > >> of Sec. 2), which adds complexity for both sender and responder. The > >> sender must ensure that when it re-fragments the message, the fragment > >> count is indeed higher (so it cannot use a simple table of possible > >> fragment sizes). And the receiver must add the number of fragments into > >> its IKE-level retransmit logic. I understand why this might be needed > >> sometimes, but is the added flexibility (allowing to retry different > >> fragment sizes) worth the complexity? > > > > That is the question. This is only for PMTU discovery. Still waiting for > > WG members > > to discuss whether it is needed. And anyway all this functionality is > > marked as MAY. > > I already think authenticated fragments is adding a lot of > logic. Let's not add more. Optimising on size is pointless, just > fragment near the minimum packet size. It's going to add what? 1 more > fragment? I also think that PMTU discovery isn't very useful for IKE. That's why it is MAY. I just don't like hardcoded values for message size, especially 576 bytes, as I couldn't find in the RFCs that IP datagrams of this size will pass anywhere. So, in my mind, we don't have safe low limit for IPv4. That's why I leave a small backdoor - PMTU discovery, that is not limited to any predefined value. > > What about the need for responder to take fragments number > > into consideration, - I don't think it will complicate implementation, > > just one more field to compare. > > The word "number" and "id" is confusing in the IKEv1 version. I'm not > sure what you are referring to here (I have to re-read the entire draft > to give feedback before vancouver) > > The IKEv1 fragment id is never used. All real world implementations > always set it to 1 AFAIK. A peer never really has more then one > fragmented IKE packet outstanding with a peer. Perhaps that is different > in v2? There is no field "id" in IKEv2 Fragmentation Payload - just Fragment Number and Total Fragments. But Total Fragments field plays a dual role if peer uses PMTU discovery - i.e. tries several fragment sizes. In this case Total Fragments allows to distinguish between fragments from different sets (assuming that trying smaller fragment size results in increasing number of fragments). Regards, Valery. From mls@cisco.com Sun Oct 6 12:45:42 2013 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 193011F0D57 for ; Sun, 6 Oct 2013 12:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfUnizzbFBjF for ; Sun, 6 Oct 2013 12:45:34 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 888021F0D21 for ; Sun, 6 Oct 2013 12:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9466; q=dns/txt; s=iport; t=1381088721; x=1382298321; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JlSZtqfacSxbKYNBiGILm/DuGjn6RZ12R7I1sTKW1N0=; b=cA1PTmPcwUsQhSHCeGvCX2IsIp6KCR18fRWwpkFErwmlCKg0mM+y0iui TbYZAObxXF1RIvcw0eQJ8HBlKW5deH8cL4W1czEodfKlQ75dRm5AUbK91 6wIEmrjQ8UNhpNEpsx01ZyIMscVxKwqnFoXpCgxzpPT2NEf0qQypOrzBz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAOW8UVKtJV2b/2dsb2JhbABZgwc4UsEYgRQWdIIlAQEBAwEBAQFrCwUHBAIBCA4DBAEBCx0HJwsUCQgCBAENBQiHeAUBDLo+BI4SgQ4xBwaDGYEEA4kBoQCDJIFoBzs X-IronPort-AV: E=Sophos;i="4.90,1045,1371081600"; d="scan'208";a="265726355" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 06 Oct 2013 19:45:16 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r96JjFnD005872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 6 Oct 2013 19:45:15 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.176]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Sun, 6 Oct 2013 14:45:15 -0500 From: "Mike Sullenberger (mls)" To: Yoav Nir , Paul Hoffman Thread-Topic: [IPsec] NUDGE: Reviewing the AD VPN drafts Thread-Index: AQHOv4q31xzpFf+CCUWb5Xh9lO3O3pniE4+AgAXu/1A= Date: Sun, 6 Oct 2013 19:45:14 +0000 Message-ID: <9D83DE546CB6DC47A3AE04086FDE35F523F892E8@xmb-aln-x06.cisco.com> References: <59B98C2D-ED10-4B68-A6AE-DF9FEE3BADCF@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.69.89.26] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" , "Mike Sullenberger \(mls\)" Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 06 Oct 2013 19:45:42 -0000 Hi Yoav, I thought I would answer your questions about DMVPN. I also think that th= ere are a couple places where we need to clarify some concepts in the draft= . More inline. Thanks, Mike. Mike Sullenberger, DSE mls@cisco.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 .:|:.:|:. Customer Advocacy=A0=A0=A0=A0=A0=A0=A0=A0=A0 CISCO > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Yoav Nir > Sent: Wednesday, October 02, 2013 11:44 AM > To: Paul Hoffman > Cc: ipsec@ietf.org WG > Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts >=20 > Hi >=20 > I have read the DM-VPN draft. I would not call my reading a review, as it= was > quite superficial, but here's some thoughts: >=20 > - I have to admit that I'm still having trouble wrapping my head around s= ome > of the concepts. I understand domain-based and route-based VPNs, as well > as IPsec and GRE tunnels. But I haven't thought of all the VPN endpoints = as > actually being on the same network. In fact I always thought of VPN as an > abstract concept or as a bunch of tunnels, not as a real network. Having = said > that, I'm still trying to get used to the idea of NHRP being used for dis= covery > (and to the idea of NHRP itself). To my mind a VPN is not an NBMA, but th= at > does not mean an NBMA cannot serve as a good model for a VPN. It is true that we normally have a single tunnel subnet (IP addresses on th= e tunnel interfaces), but it isn't a requirement, we can support using tunn= els with different subnets in the same DMVPN. Though often within a single = domain/area having the tunnels in the same subnet works well for grouping t= hose nodes. Spokes in region A connect to Region A Hub and Spokes in regio= n B connect to region B Hub. Region A and B hubs connect to central hub. T= his could be divided into three tunnel subnets (Region A, B and Central). = We still support dynamic spoke-spoke tunnels between any pair of nodes (spo= ke in A - spoke in A, spoke in A - spoke in B, Spoke in A or B - Central Hu= b, Region A Hub - Region B Hub, spoke in A - Region B Hub, spoke in B Regio= n A Hub). The use of GRE with NHRP was our way of using layering to solve issues. By= separating the tunneling function from the encryption function we solve a = number of issues. 1. Encryption only has to deal with encrypting the GRE/IP tunnel packet so = there is at most one set of encryption selectors between encryption peers n= eeded, no matter how many host data flows or subnets are using the tunnel. 2. We naturally handle two VPN gateways supporting the same hosts/subnets. = The remote peer can use regular routing/forwarding to forward traffic over = the two tunnels to one or both (load-balancing) to the VPN gateways. 3. It is easy to add other passenger protocols, because we only need to add= them to GRE (Protocol Type field in header) and to NHRP (is designed to ha= ndle multiple passenger protocol types). For example: this made it easy to = add IPv6 passenger support. > - I like how the process described in section 4.3 to 4.6 quickly converge= s. If > host a behind gateway A sends packets to host e behind gateway E, and the > packets travel though the tunnels AB, BC, CD, and DE, then the discovery > process might go through several hops, but the next tunnel to be set up i= s > AE. There is no case of setting up AC or AD. We worked fairly diligently to make it so we only build the end-to-end tunn= el (ingress-egress) tunnel. > - Reading section 4.8, I see that within a single DM-VPN, there is a natu= ral > progression from hub&spoke to mesh. There doesn't seem to be a place for > policy on whether a shortcut should or should not be established. The > resolution request is forwarded until the egress node. So if, for example= , > you have two government agencies, each with its own set of gateways, and > two gateways (one belonging to each agency) have a tunnel between them, > there are two possible configurations: a single DM-VPN, in which case the= y > become a mesh, or two DM-VPNs, so that the inter-domain tunnel endpoints > are egress nodes on their respective DM-VPNs. Is there a way to implement > a policy so that some shortcuts are created between those other gateways? Yes you can. This would be controlled on the gateways. They could be conf= igured to send or not to send indirection messages depending on destination= subnet or routing to the destination subnet. That would suppress indirecti= on messages when you don't want a spoke-spoke tunnel at all. Otherwise an = indirection message would be sent, which would generate a resolution reques= t. The resolution request goes through the same path as the data packets th= at triggered the indirection. At this point the gateways on either side of= the inter-government tunnel have the choice of answering the resolution re= quest themselves (shortcut the end-end tunnel) or forwarding the resolution= request (allow the end-end tunnel). Note, the endpoint devices will not k= now the difference. I think that this is not very clear in the draft, and w= e will have to expand the explanation. > - Section 4.10 seems to be missing something. Suppose gateway A is > forwarding traffic to gateway B, and receives an Indirection notification= . So > A sends a Resolution request. After a while, it receives a Resolution rep= ly > with TunS2 and PubS2 addresses. So now A should open a tunnel with TunS2 > (right? I'm not clear about the fields). Two things can happen, when B receives the resolution request from A, withi= n the request is the TunS1 and PubS1 addresses. 1. B now has sufficient information to initiate the tunnel (PubS2 - PubS1) = back to A. Assuming B authenticates with A and they have common crypto par= ameters, then B will send the resolution reply through this new tunnel. Wh= en A receives the resolution reply it will check to initiate a tunnel back = to B (PubS1- PubS2) only to find on already exists and it only needs to ch= ange the packet forwarding to send data packets over the new tunnel. 2. B sends the resolution reply back to A via the gateway/hub path. A rece= ives the resolution reply and it now has sufficient information to initiate= the tunnel (PubS1 - PubS2) to B. Once the tunnel is setup the A can change= the packet forwarding to send data packets over the new tunnel. Note, this describes the interaction for data traffic going from A to B. It= is assumed that there will also be corresponding data traffic going from B= to A. The same above actions take place relative to this "return" traffic= . But, since the tunnels use PubS1 and PubS2 as the endpoints we only get = one tunnel/encryption between these two endpoints which is used for the by = directional traffic within two data subnets. Note, if there is only one-wa= y data traffic (say A to B) everything still works, it is just that B will= never send a resolution request nor receive a resolution reply and not mod= ify its routing/forwarding for corresponding packets going B to A. The A to= B traffic will flow over the tunnel. > So section 4.10 says that > authentication between these two nodes will be done using certificates. > Considering that A has only just heard of TunS2's existence, what fields = are > there going to be in the certificate that will let A know that this is in= deed > TunS2? While a single domain might have some convention for this, AD-VPN > is supposed to be good for multiple administrative domains, so there > should be some rule about this. The assumption has been that the certificates have a common node in the cer= tificate chain or the nodes have multiple certificate chains installed so t= hat they can authenticate each other. I agree that this may not cover all = inter-domain scenarios. You could add the capability in the Gateway nodes = (those that have the inter-domain interconnect tunnel) for them to attach a= ny needed certificate information to the resolution request and replies. T= his would mean that for these types of connections you would use option 2 i= n the above forwarding of request and replies.=20 =20 > - The same section hints at using certificate fields for filtering. This = sounds > weird. Suppose two gateways learn of each other through the resolution > process. Now they try to connect, only to find out that the certificate f= ields > do not allow them to connect. So we've gone through an entire IKE > handshake just to discover that policy prohibits forming this tunnel? And > because caches expire, the gateways will try again and again to form this > tunnel, all the time failing on authorization. I covered this above. If the policy is such that if two nodes should not b= uild a direct tunnel then they or their gateways should be configured to bl= ock sending indirection messages, block sending resolution requests, block = sending resolution replies (optional to send NACK resolution reply). Also = indirection messages must be rate-limited so if the above condition is tran= sitory, we don't trigger the end nodes "too often" to attempt to set up the= direct tunnel. >=20 > Yoav >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From manishkr@cisco.com Mon Oct 7 10:47:29 2013 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 66F9F11E80F5 for ; Mon, 7 Oct 2013 10:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pmxP1YZtK50 for ; Mon, 7 Oct 2013 10:47:24 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 08FB511E8109 for ; Mon, 7 Oct 2013 10:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5101; q=dns/txt; s=iport; t=1381168042; x=1382377642; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Z2tC8TgutOTnaVriyGr39iveqK0BH+kAG97En47Ji7Y=; b=IpZsOB4pNYOSqdLmN/S6JAGccRHJPTy6WBLsZGMbpaPzja7ANGsf6fER umTKvz8dXYa7OZND/IEbORat+j2rSD/noLWtYhe0tfrFZXFEwPGN52Qt9 RK0QhmKnAGdPEdcJ6LOAo8O8eNI4ZqyrHXhi4tARfbdGK2QWhqmVoc7IJ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAHPyUlKtJV2d/2dsb2JhbABZgwc4UsEfgR4WdIInAQQBAQE3LQcLEgEIDhQUNwslAgQBDQUIh34MunMEjyAxB4MfgQQDqgGDJIIq X-IronPort-AV: E=Sophos;i="4.90,1051,1371081600"; d="scan'208";a="269087554" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 07 Oct 2013 17:47:21 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r97HlLnp026156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Oct 2013 17:47:21 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.21]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 7 Oct 2013 12:47:20 -0500 From: "Manish Kumar (manishkr)" To: Yoav Nir , Paul Hoffman Thread-Topic: [IPsec] NUDGE: Reviewing the AD VPN drafts Thread-Index: AQHOv4q3j4vt1vufa0eBNaKhzF7irJniE4+AgAgn6YA= Date: Mon, 7 Oct 2013 17:47:20 +0000 Message-ID: <68EC0A9FF2689047993640F410CB97E4185A76CE@xmb-rcd-x05.cisco.com> In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.65.37.175] Content-Type: text/plain; charset="us-ascii" Content-ID: <6FDF14D8F9A834488CE21FE4EE610630@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 07 Oct 2013 17:47:29 -0000 Hi Yoav, Thanks for your comments. I would try adding clarity to some of these inline [Manish] to supplement what Mike said. Manish On 03/10/13 12:14 AM, "Yoav Nir" wrote: >Hi > >I have read the DM-VPN draft. I would not call my reading a review, as it >was quite superficial, but here's some thoughts: > >- I have to admit that I'm still having trouble wrapping my head around >some of the concepts. I understand domain-based and route-pased VPNs, as >well as IPsec and GRE tunnels. But I haven't thought of all the VPN >endpoints as actually being on the same network. In fact I always thought >of VPN as an abstract concept or as a bunch of tunnels, not as a real >network. Having said that, I'm still trying to get used to the idea of >NHRP being used for discovery (and to the idea of NHRP itself). To my >mind a VPN is not an NBMA, but that does not mean an NBMA cannot serve as >a good model for a VPN. [Manish]: What the applications running over the VPN see a VPN as (NBMA or otherwise), depends a lot on the services provided on the VPN and the draft doesn't preclude any possibilities that way. RFC 4301 already prescribes the arms and ammunitions needed to protect IP packets (when used in connection with GRE can be used to protect IP multicast as well as non-IP packets) over untrusted networks. Also, as appropriately noted in the requirements document, 4301 is silent on the way the IPSec databases are populated. So the problem is essentially of discovery and resolution. The discovery can be left to the routing protocol but the resolution would still be needed unless IGPs are multi-protocol, which they typically aren't. Even if they were, this would need a next-hop preservation which won't scale. So, essentially DMVPN picks up an appropriate address resolution protocol in NHRP which is enhanced to support both discovery and resolution. This is combined with GRE to make sure IP multicast and non-IP packets can be seamlessly(without changing any other layer/protocol) carried across the same tunnel and also to simplify the SPDs. > >- I like how the process described in section 4.3 to 4.6 quickly >converges. If host a behind gateway A sends packets to host e behind >gateway E, and the packets travel though the tunnels AB, BC, CD, and DE, >then the discovery process might go through several hops, but the next >tunnel to be set up is AE. There is no case of setting up AC or AD. > >- Reading section 4.8, I see that within a single DM-VPN, there is a >natural progression from hub&spoke to mesh. There doesn't seem to be a >place for policy on whether a shortcut should or should not be >established. The resolution request is forwarded until the egress node. >So if, for example, you have two government agencies, each with its own >set of gateways, and two gateways (one belonging to each agency) have a >tunnel between them, there are two possible configurations: a single >DM-VPN, in which case they become a mesh, or two DM-VPNs, so that the >interdomain tunnel endpoints are egress nodes on their respective >DM-VPNs. Is there a way to implement a policy so that some shortcuts are >created between those other gateways? > >- Section 4.10 seems to be missing something. Suppose gateway A is >forwarding traffic to gateway B, and receives an Indirection >notification. So A sends a Resolution request. After a while, it receives >a Resolution reply with TunS2 and PubS2 addresses. So now A should open a >tunnel with TunS2 (right? I'm not clear about the fields). So section >4.10 says that authentication between these two nodes will be done using >certificates. Considering that A has only just heard of TunS2's >existence, what fields are there going to be in the certificate that will >let A know that this is indeed TunS2? While a single domain might have >some convention for this, AD-VPN is supposed to be good for multiple >administrative domains, so there should be some rule about this. > >- The same section hints at using certificate fields for filtering. This >sounds weird. Suppose two gateways learn of each other through the >resolution process. Now they try to connect, only to find out that the >certificate fields do not allow them to connect. So we've gone through an >entire IKE handshake just to discover that policy prohibits forming this >tunnel? And because caches expire, the gateways will try again and again >to form this tunnel, all the time failing on authorization. [Manish]: Iff routing and NHRP policies(in general, all upper layer policies) allow the shortcut, IKE proceeds till Auth the first time and fails; this can be conveyed back to the upper layer (NHRP) with an appropriate error code, which sends a NACK resolution reply. The NACK serves to stop further resolutions either permanently or for an interval either configured or communicated by the peer. >=20 > >Yoav > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From paul@cypherpunks.ca Tue Oct 8 07:52:29 2013 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 01A7321E81CB for ; Tue, 8 Oct 2013 07:52:28 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yE0+Rc+iZkrP for ; Tue, 8 Oct 2013 07:52:13 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1312A21E81A2 for ; Tue, 8 Oct 2013 07:52:13 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cvM3C3gzCz9b6; Tue, 8 Oct 2013 10:52:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id JG_mCxPyH5qV; Tue, 8 Oct 2013 10:52:06 -0400 (EDT) Received: from bofh.nohats.ca (unknown [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 8 Oct 2013 10:52:06 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 3B05E80097; Tue, 8 Oct 2013 10:51:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 25A8B8002F; Tue, 8 Oct 2013 10:51:56 -0400 (EDT) Date: Tue, 8 Oct 2013 10:51:56 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Valery Smyslov In-Reply-To: Message-ID: References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Tue, 08 Oct 2013 14:52:29 -0000 On Fri, 4 Oct 2013, Valery Smyslov wrote: > So it may decide to fragment message too late. The only exception - > the situation you described, when responder always sends messages > fragmented. I think we may add this exception to responder's logic. Okay. > I also think that PMTU discovery isn't very useful for IKE. > That's why it is MAY. That does not help implementors who still have to implement the MAY's. if even you as a document author does not think it is veru usefil, then I think it should just not be in the document. > I just don't like hardcoded values for message size, > especially 576 bytes, as I couldn't find in the RFCs that > IP datagrams of this size will pass anywhere. So, in my mind, we don't have > safe low limit for IPv4. That's why I leave a small backdoor - > PMTU discovery, that is not limited to any predefined value. But the hardcoded value does not need to be set in stone for everyone. It can be a value of "at least X and at most Y", and then left to implementors and operational experience. > There is no field "id" in IKEv2 Fragmentation Payload - just Fragment Number > and Total Fragments. But Total Fragments field plays a dual role if > peer uses PMTU discovery - i.e. tries several fragment sizes. > In this case Total Fragments allows to distinguish between fragments from > different sets (assuming that trying smaller fragment size results in > increasing number of fragments). All the more reasons not to have PMTU dicovery. Paul From yumao9@gmail.com Tue Oct 8 08:44:08 2013 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 B1E9121E818D for ; Tue, 8 Oct 2013 08:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9XD2-OWrtQo for ; Tue, 8 Oct 2013 08:44:08 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5D221F9F19 for ; Tue, 8 Oct 2013 08:44:08 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id as1so1549166iec.27 for ; Tue, 08 Oct 2013 08:44:07 -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=/cJ4xbKxKj1DnVngIpmwS/DDc2RXxQFHYEmX6bkzMF8=; b=Gwv0XApFHx+pFtQAxQiReMkvcoKILYyfLmvtA/lPzneX9AcGlbmFFdj5/J/7+r8w+h 4lFU4/DroeX0RUH7/z9Ua3CI5c0+SxA1wiAyGED06jP6a1wuLRGAEyc0+r4DVJb0Afod GcLTElqKVRUnVNqiWurlKLXW6GIq1WHLfHSpQHHsGxBEIc5ZTHSeIDORiReenYjSVPEf U0BsmtAfD5kQ/jkV4uTOfucUrcXp9r9cY0SCwnM338OAgLk2QHhwHaDRI6fTJwDq0ilK c1a/P8tPUcyZpy2r3R6pp1GDhOI0+iaP2GB+JQPCkPMGUcex20c5XUJYWlOnuRNrWDRY XQqg== MIME-Version: 1.0 X-Received: by 10.43.151.12 with SMTP id kq12mr1530635icc.55.1381247047496; Tue, 08 Oct 2013 08:44:07 -0700 (PDT) Received: by 10.43.129.8 with HTTP; Tue, 8 Oct 2013 08:44:07 -0700 (PDT) In-Reply-To: References: <59B98C2D-ED10-4B68-A6AE-DF9FEE3BADCF@vpnc.org> <14105.1380808630@sandelman.ca> Date: Tue, 8 Oct 2013 23:44:07 +0800 Message-ID: From: Toby Mao To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Cc: "ipsec@ietf.org WG" , Michael Richardson Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 08 Oct 2013 15:44:08 -0000 On Fri, Oct 4, 2013 at 5:21 AM, Yoav Nir wrote: > > On Oct 3, 2013, at 4:57 PM, Michael Richardson wrote: >> >> >> I also read: draft-mao-ipsecme-ad-vpn-protocol and while conceptually I found >> it okay, I think that the protocol should be inside IKE. > > Funny, I came to the opposite conclusion. I think it's too much like IKE. > > But actually, this should be split in two. > > ADC to ADC communications, like the REDIRECT and SESSION could easily run over an Informational exchange in IKE. [Toby]: Yes, it may be, but I think the ADVPN protocol should be a seperate and complete protocol, thus it is better not to extend IKE protocol, it can be protected by IKE/IPsec protocol. > > But the ADC to ADS communications are, to quote section 1.1, "a client and server protocol". And there is no reason to assume that the ADS can even do IKE - it's a controller. So I think those parts of the protocol could be done in a web service. > > But, why am I designing someone else's proposal? > [Toby]: For ADVPN solution, the main goal of ADVPN protocol is to discover IPsec peer neighbor on demand and establish a shortcut tunnel. To find the shortcut path efficiently, It maintains the private network information and private/public address. It is different with IKE protocol, so it can be a totally new protocol. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Tue Oct 8 09:14:09 2013 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 A812511E80FB for ; Tue, 8 Oct 2013 09:14:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMXdob2sDTUe for ; Tue, 8 Oct 2013 09:14:09 -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 A232A21E8099 for ; Tue, 8 Oct 2013 09:11:21 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r98GB25f080529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 8 Oct 2013 09:11:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <317DC188-9889-43D7-9B42-73E6983D5D0F@vpnc.org> Date: Tue, 8 Oct 2013 09:11:02 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [IPsec] Virtual Interim on two AD VPN drafts: Call-in details 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, 08 Oct 2013 16:14:09 -0000 Greetings again. =46rom the earlier announcement: The IPsecME Working Group will hold a virtual interim meeting on = Wednesday, Oct. 9, 2013 via a phone bridge. The main goal of the meeting = will be to advance the auto-discovery VPN solution. The time for the meeting is: 15:00 UTC 8:00 San Francisco 17:00 Berlin 18:00 Tel Aviv Duration: 1:30 hours. Agenda: - Detailed presentations of two AD VPN drafts: draft-detienne-dmvpn-00 = and draft-mao-ipsecme-ad-vpn-protocol-02. - A short discussion of draft-ietf-ipsecme-esp-ah-reqts-01. It would be grand if people would discuss that draft on the list before = the phone call as well. The call-in details are: Tele: +1 712-775-7400 Code: 809604# Virtual interim meetings are like real IETF meetings in that we have to = take attendance and have minutes. If someone would volunteer to be = minutes-taker, that would be grand. --Paul Hoffman From kivinen@iki.fi Wed Oct 9 04:10:39 2013 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 99C5A21F9A78 for ; Wed, 9 Oct 2013 04:10:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2cr4aE4rebU for ; Wed, 9 Oct 2013 04:10:38 -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 EF43C21E8121 for ; Wed, 9 Oct 2013 04:10:35 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r99BAViB026175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 9 Oct 2013 14:10:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r99BAVNr024130; Wed, 9 Oct 2013 14:10:31 +0300 (EEST) 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: <21077.14759.253612.481464@fireball.kivinen.iki.fi> Date: Wed, 9 Oct 2013 14:10:31 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 25 min Subject: [IPsec] Comments to draft-nir-ipsecme-cafr-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: Wed, 09 Oct 2013 11:10:39 -0000 In section "2.2. Verifying the HAND_OVER_CHILD_SAS Notification" the document lists operations which needs to be done when handling the notification. The process seems otherwise quite good, expect the error handling seems to be bit drastic. It currently says that if the authenticated identites are different then other end replies with INVALID_SYNTAX error message: ---------------------------------------------------------------------- 2.2. Verifying the HAND_OVER_CHILD_SAS Notification ... o The authenticated identities of both sides under the new IKE SA are the same as those under the old IKE SA. If the authenticated identity of one peer differs from the authenticated identity that it had in the previous IKE SA, the other side MUST respond with an INVALID_SYNTAX notification. ... ---------------------------------------------------------------------- >From RFC5996, the INVALID_SYNTAX processing is described as following: ---------------------------------------------------------------------- 2.21.3. Error Handling after IKE SA is Authenticated ... If a peer parsing a request notices that it is badly formatted (after it has passed the message authentication code checks and window checks) and it returns an INVALID_SYNTAX notification, then this error notification is considered fatal in both peers, meaning that the IKE SA is deleted without needing an explicit Delete payload. ---------------------------------------------------------------------- I.e. the INVALID_SYNTAX notification is considered fatal in both peers, meaning that IKE SA is deleted. In this case this will cause the OLD IKE SA to be deleted. I do not think we want to be that to happen. Perhaps something less fatal error message would be better as this is not error cases listed in the RFC5996: "message that was received was invalid because some type, length, or value was out of range or because the request was rejected for policy reasons." (Ok, it could be considered to be rejected because policy reasons). As we are moving CHILD SAs, perhaps we could consider this as normal "Generic Child SA error" and use NO_PROPOSAL_CHOSEN. Also in the end of the section 2.2 it says: ---------------------------------------------------------------------- If the Initiator has sent the notification, but the notification from the Responder does not match the IKE SPIs in the Initiator's notification, the Initiator MUST send a SYNTAX_ERROR notification and MUST NOT transfer the Child SAs. ---------------------------------------------------------------------- but there is no SYNTAX_ERROR error message in the IKEv2. This on the other hand is clearly fatal error, as it indicates that the responder has somehow corrupted its state, or there is implementation bug there, if it cannot copy SPI from the request to the reply properly. On the other hand I see no reason why the reply should include the SPI it all. It would be better that initiator just sends the notify with the SPI, and responder replies with the notify and does not include SPI at all (i.e. its notify data would be empty). The SPI in the responder message does not have any meaning or use. In section 7 Security Considerations I can see the attack that can happen if the authenticated identities are not same. I.e. if host uses authenticated identities also outside the IPsec. For example the host might export the authenticated identities to the nfs-server, and nfs-server could use that to verify what kind of operations the user can do. In that case attacker might create IKE SA and Child SA to nfs-server of the server, and then move the Child SA to another users IKE SA, and then start doing nfs-requests. Now when nfs-server asks from the IPsec engine who is on the other end of the protected IPsec tunnel the IPsec engine would respond wrong users... As long as the IPsec is mostly used for VPNs this kind of setups are not used, but if host to host IPsec ever comes reality this kind of setups might happen, so I think that check is very important... -- kivinen@iki.fi From kivinen@iki.fi Wed Oct 9 04:50:06 2013 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 B91D411E8141 for ; Wed, 9 Oct 2013 04:50:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PDJIiB+M+eX for ; Wed, 9 Oct 2013 04:50:06 -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 6D0F521F9E51 for ; Wed, 9 Oct 2013 04:50:05 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r99BnvPq021698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Oct 2013 14:49:57 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r99Bnu7A025566; Wed, 9 Oct 2013 14:49:56 +0300 (EEST) 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: <21077.17123.827427.858811@fireball.kivinen.iki.fi> Date: Wed, 9 Oct 2013 14:49:55 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 20 min X-Total-Time: 19 min Cc: ipsec@ietf.org, Paul Wouters Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Wed, 09 Oct 2013 11:50:06 -0000 Valery Smyslov writes: > There is no field "id" in IKEv2 Fragmentation Payload - just Fragment Number > and Total Fragments. But Total Fragments field plays a dual role if > peer uses PMTU discovery - i.e. tries several fragment sizes. > In this case Total Fragments allows to distinguish between fragments from > different sets (assuming that trying smaller fragment size results in > increasing number of fragments). This was the thing that confiused me when reading the document. The section 2.5 should explain the Total Fragments much better. I.e. change the definition something like: o Total Fragments (2 octets) - number of fragments original message was divided into. If original message is resent with different fragmentation boundaries this value MUST be larger than the previously used Total Fragments value, i.e the responder will use this to detect whether the incoming message belongs to the group of packets fragmented in same way. This field MUST NOT be zero. Or something like that. Also I do not understand why the Fragment Number and Total Fragments start from 1. I think it would be more logical to have first fragment be 0, second 1, and the Total Fragments would be The Last Fragment# field. That way we do not need to have special check that fragment needs to be ignored if Fragment Number or Total Fragments are 0. In general I think the sending and receiving rules should be explained a bit more. For example the o Check message validity - in particular, check whether values of Fragment Number and Total Fragments in Encrypted Fragment Payload are valid. If not - message MUST be silently discarded. should be changed to say: o Check message validity - in particular, check whether values of Fragment Number (must be <= Total Fragments) and Total Fragments (must be >= previously seen Total Fragments for this message) in Encrypted Fragment Payload are valid. If not - message MUST be silently discarded. It should clearly say that if Total Fragments is less than previously seen then this fragment needs to be discarded. Now when I am reading th text several times through I see that all the required things are there, but when I was reading it first time through it was really hard to parse what is going on, and especially as I missed the dual role of the Total Fragments I got confused. It might be enough to just add more text in the Total Fragments description, clearly stating that it has dual role, i.e. telling what is the max fragment number of this message, and to separate the different fragmentation boundaries. My text above does not yet properly describe that either, so some better text is needed. -- kivinen@iki.fi From paul@cypherpunks.ca Wed Oct 9 06:40:33 2013 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 9B33A11E8183 for ; Wed, 9 Oct 2013 06:40:33 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a4AL-ZIgnkl for ; Wed, 9 Oct 2013 06:40:27 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD7621F9A16 for ; Wed, 9 Oct 2013 06:40:27 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cvxPy1wnRz1yR; Wed, 9 Oct 2013 09:40:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id fyxkw1P_3Xnn; Wed, 9 Oct 2013 09:40:20 -0400 (EDT) Received: from bofh.nohats.ca (unknown [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 9 Oct 2013 09:40:19 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 9BD6C80097; Wed, 9 Oct 2013 09:40:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8F75D80018; Wed, 9 Oct 2013 09:40:08 -0400 (EDT) Date: Wed, 9 Oct 2013 09:40:08 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: <21077.17123.827427.858811@fireball.kivinen.iki.fi> Message-ID: References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <21077.17123.827427.858811@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" , Valery Smyslov Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Wed, 09 Oct 2013 13:40:34 -0000 On Wed, 9 Oct 2013, Tero Kivinen wrote: > For example the > > o Check message validity - in particular, check whether values of > Fragment Number and Total Fragments in Encrypted Fragment Payload > are valid. If not - message MUST be silently discarded. > > should be changed to say: > > o Check message validity - in particular, check whether values of > Fragment Number (must be <= Total Fragments) and Total Fragments > (must be >= previously seen Total Fragments for this message) in > Encrypted Fragment Payload are valid. If not - message MUST be > silently discarded. > > It should clearly say that if Total Fragments is less than previously > seen then this fragment needs to be discarded. But you must only do that after the decryption/authentication of the fragment or we are back at square one with an easy DoS this whole mechanism was supposed to protect us from. Which of course means an attacker can just send crap faster that you can verify it is crap after performing crypto on the fragment. Paul From mcr@sandelman.ca Wed Oct 9 07:02:30 2013 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 4D36111E819D for ; Wed, 9 Oct 2013 07:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3d53YxzIztQ for ; Wed, 9 Oct 2013 07:02:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id E865311E8190 for ; Wed, 9 Oct 2013 07:02:24 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9B8B320251; Wed, 9 Oct 2013 11:12:28 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4CC5463B88; Wed, 9 Oct 2013 10:02:18 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2507E63B87; Wed, 9 Oct 2013 10:02:18 -0400 (EDT) From: Michael Richardson To: Paul Hoffman In-Reply-To: <317DC188-9889-43D7-9B42-73E6983D5D0F@vpnc.org> References: <317DC188-9889-43D7-9B42-73E6983D5D0F@vpnc.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: IPsecme WG Subject: Re: [IPsec] Virtual Interim on two AD VPN drafts: Call-in details 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, 09 Oct 2013 14:02:30 -0000 --=-=-= Paul Hoffman wrote: > The call-in details are: > Tele: +1 712-775-7400 > Code: 809604# Two LD suppliers (entirely different phones) tell me that I can not reach this number from my line. I'm gonna try Google Talk now. (and I guess it's really in an hour anyway) -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUlVh6YqHRg3pndX9AQJ3xwQAmarHDOa7DbGoGeKZXe4r7ghhQw+1SDsL Cc7NfbyWssLymq78V3gpe8cVYS4IKl6EplQgKuS35GdgsHhZ8SBBc/a5G6A7edS6 AEHF9Dv8SjqRdy2lGEY9P26+qnxSE91D3NjRn+tTiZOzPysBrOxtrGXL2nFq69GZ VF4YQroddkU= =e+/I -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Wed Oct 9 07:12:39 2013 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 9810B11E818C for ; Wed, 9 Oct 2013 07:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmgEvL-aqbfk for ; Wed, 9 Oct 2013 07:12:38 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id C30DA11E8198 for ; Wed, 9 Oct 2013 07:12:37 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 341E920251; Wed, 9 Oct 2013 11:22:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4A7C163B88; Wed, 9 Oct 2013 10:12:32 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3BA0663B87; Wed, 9 Oct 2013 10:12:32 -0400 (EDT) From: Michael Richardson to: Paul Hoffman , IPsecme WG In-Reply-To: <7439.1381327338@sandelman.ca> References: <317DC188-9889-43D7-9B42-73E6983D5D0F@vpnc.org> <7439.1381327338@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [IPsec] Virtual Interim on two AD VPN drafts: Call-in details 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, 09 Oct 2013 14:12:39 -0000 --=-=-= Michael Richardson wrote: >> The call-in details are: >> Tele: +1 712-775-7400 >> Code: 809604# mcr> Two LD suppliers (entirely different phones) tell me that I can not reach mcr> this number from my line. I wonder if this exchange has an inflated LD rate? Nice if there was a SIP option to reach them.... how does that ENUM RR work again :-) mcr> I'm gonna try Google Talk now. GoogleTalk connected. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUlVkUIqHRg3pndX9AQKARAP/Ta7QV7vds29WynjLzW8T/LpHTvyEwQhP jPAN4Ba9EtRSY1HgifmvFBygqgik50v48FV5g/96OukgO76isBdrHsyKPdBvXo3s cDyjOUVP9V/o4mDdfryMbkMNUIKX8xrNNx8BzE6DrOE3bEma2+G/Qh5oRVa/faNk umn/Ew6G6r4= =XTmn -----END PGP SIGNATURE----- --=-=-=-- From kivinen@iki.fi Wed Oct 9 07:36:40 2013 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 1CD6C21F9C4C for ; Wed, 9 Oct 2013 07:36:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3TRNgoCWrB0 for ; Wed, 9 Oct 2013 07:36:39 -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 B9F4921F9C12 for ; Wed, 9 Oct 2013 07:36:17 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r99EaEUE004307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 9 Oct 2013 17:36:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r99EaEEE003427; Wed, 9 Oct 2013 17:36:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Message-ID: <21077.27102.726599.177776@fireball.kivinen.iki.fi> Date: Wed, 9 Oct 2013 17:36:14 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Vn2aEED1rw" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 18 min X-Total-Time: 29 min Subject: [IPsec] Comments to draft-song-ipsecme-seq-icv-01 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, 09 Oct 2013 14:36:40 -0000 --Vn2aEED1rw Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit The new SEQ-ICV calculation is no more safer than the previous one. It is trivial to break it: SEQ-ICV = (SEQ + ICV[0-3]) ^ K[0-3] + (SEQ + ICV[4-7]) ^ K[4-7] + (SEQ + ICV[8-11]) ^ K[8-11] The problem is that lowest byte of the SEQ-ICV only depends on the K[3] + K[7] + K[11], as the SEQ and ICV is known to the attacker. So attacker needs to do O(2^24) work to crack the 3 bytes from the key. For the next 3 bytes it needs to do same, and so on. So the total complexity of the SEQ-ICV is O(4*2^24) = O(2^26), i.e. around 67 million tries. In my attacked perl script the cracking can be done after seeing around 50 packets with valid SEQ, ICV, SEQ-ICV triplets, and the main reason it requires 50 packets is that I try 10 packets before I am convinced that my guess for the 3 bytes is correct before moving to the next byte, so 4 * 10 == 40 would be the mimimum... The run time of my attack script is less than 20 seconds... And time to implement that script was around an hour, inventing the method to start attacking against it took less than the time to run the final script. I think it is pointless to try to invent new semi-cryptographic protection for the sequence numbers as it most likely will be trivially broken when someone starts to really look at in. I am no cryptographer, and even I could break last two tries, and even if you manage make method I cannot break, I am sure real cryptographers can break it in no time. If we want to use cryptographic strong hash/mac, we need to use real cryptographic strong hashes / macs, not try to invent something ourselves. And we already have cryptographic strong ICV there, so lets use that instead. (Yes, I know the script is not very pretty and it is a hack, and it uses rand() to generate random numbers, but as for this testing I just needed some random packets, so no cryptographically strong randomess was actually needed). --Vn2aEED1rw Content-Type: text/plain; name="song-crack.pl" Content-Disposition: inline; filename="song-crack.pl" Content-Transfer-Encoding: 7bit #!/usr/pkg/bin/perl -w # -*- perl -*- ###################################################################### # song-crack.pl -- Crack to draft-song-ipsecme-seq-icv # Copyright (c) 2013 Tero Kivinen # All Rights Reserved. ###################################################################### # Program: song-crack.pl # $Source: $ # Author : $Author: kivinen $ # # (C) Tero Kivinen 2013 # # Creation : 16:04 Oct 9 2013 kivinen # Last Modification : 17:34 Oct 9 2013 kivinen # Last check in : $Date: $ # Revision number : $Revision: $ # State : $State: Exp $ # Version : 1.35 # Edit time : 74 min # # Description : Crack draft-song-ipsecme-seq-icv-01 # # $Log: $ # # # ###################################################################### # initialization require 5.002; # Secret key we are trying to guess, this is only used to # calculate proper values for the SEQ-ICV $k = "RandomKey123"; ($k1, $k2, $k3) = unpack("NNN", $k); # Initial sequence number for packets, after this we just use # next sequence number. $seq = int(rand(0x10000)) * 0x10000 + int(rand(0x10000)); # How many packets and how long it takes to run this script. $packets = 0; $start = time(); # Internal state of the cracking, i.e. this is the key # we are trying now. $Crack::k1 = 0; $Crack::k2 = 0; $Crack::k3 = 0; # Packets we have already seen, every time we find new guess # for the key, we go through all of these and verify # the key works for them too. @Crack::seqs = (); @Crack::icv1 = (); @Crack::icv2 = (); @Crack::icv3 = (); @Crack::seq_icv = (); # Which byte we are trying to crack, and how many proper # packets we have already found for that. $Crack::byte = 0; $Crack::found = 0; # Limit how many packets we check before we assume this key is ok. # Note, that this code does not go back incrementing the earlier bytes # if we do not find key, so setting this too low will cause the # script not to find key. Setting this lower will require less packets. $Crack::limit = 10; # Loop until we have cracked the whole key. while ($Crack::byte < 4) { # Generate packet, i.e. genereate random ICV and calculate SEQ-ICV printf("Packet %d, finding byte %d\n", $seq, $Crack::byte); $icv = pack("n6", int(rand(0x10000)), int(rand(0x10000)), int(rand(0x10000)), int(rand(0x10000)), int(rand(0x10000)), int(rand(0x10000))); ($icv1, $icv2, $icv3) = unpack("NNN", $icv); $seq_icv = (((($seq + $icv1) & 0xffffffff) ^ $k1) + ((($seq + $icv2) & 0xffffffff) ^ $k2) + ((($seq + $icv3) & 0xffffffff) ^ $k3)) & 0xffffffff; printf("ICV = %s, seq_icv = %08x\n", unpack("H*", $icv), $seq_icv); # Give that SEQ, ICV, and SEQ-ICV to the cracking engine try_crack($seq, $icv1, $icv2, $icv3, $seq_icv); # Move to next packet $seq++; $packets++ } # Print out the results printf("Found key in %d packets, %d seconds\n", $packets, time() - $start); printf("Key = %s\n", pack("NNN", $Crack::k1, $Crack::k2, $Crack::k3)); exit(0); ###################################################################### # Try to find key that matches the SEQ, ICV, SEQ-ICV triplet given # in. sub try_crack { my($seq, $icv1, $icv2, $icv3, $seq_icv) = @_; my($seq_icv_val, $seq_icv_try, $mask, $inc, $mask2); # Check which byte we are cracking if ($Crack::byte == 0) { $mask = 0xff; $mask2 = 0xff; $inc = 1; } elsif ($Crack::byte == 1) { $mask = 0xffff; $mask2 = 0xff00; $inc = 0x100; } elsif ($Crack::byte == 2) { $mask = 0xffffff; $mask2 = 0xff0000; $inc = 0x10000; } elsif ($Crack::byte == 3) { $mask = 0xffffffff; $mask2 = 0xff000000; $inc = 0x1000000; } $seq_icv_val = $seq_icv & $mask; # Loop for possible keys until we find a hit. while (1) { # Calculate SEQ-ICV for our guessed key. $seq_icv_try = (((($seq + $icv1) & $mask) ^ ($Crack::k1 & $mask)) + ((($seq + $icv2) & $mask) ^ ($Crack::k2 & $mask)) + ((($seq + $icv3) & $mask) ^ ($Crack::k3 & $mask))) & $mask; # Check if it was a match. if ($seq_icv_val == $seq_icv_try) { # It was, check for the earlier packets. if (check_rest($mask)) { # They matched too, add the packet to the pool add_packet($seq, $icv1, $icv2, $icv3, $seq_icv); # Did we find enough packets that match our current key # if so move to next byte if ($Crack::found > $Crack::limit) { # Print out the current key before moving to next byte if ($Crack::byte == 0) { printf("Key = ***%c***%c***%c\n", $Crack::k1 & 0xff, $Crack::k2 & 0xff, $Crack::k3 & 0xff); } elsif ($Crack::byte == 1) { printf("Key = **%c%c**%c%c**%c%c\n", ($Crack::k1 >> 8) & 0xff, $Crack::k1 & 0xff, ($Crack::k2 >> 8) & 0xff, $Crack::k2 & 0xff, ($Crack::k3 >> 8) & 0xff, $Crack::k3 & 0xff); } elsif ($Crack::byte == 2) { printf("Key = *%c%c%c*%c%c%c*%c%c%c\n", ($Crack::k1 >> 16) & 0xff, ($Crack::k1 >> 8) & 0xff, $Crack::k1 & 0xff, ($Crack::k2 >> 16) & 0xff, ($Crack::k2 >> 8) & 0xff, $Crack::k2 & 0xff, ($Crack::k3 >> 16) & 0xff, ($Crack::k3 >> 8) & 0xff, $Crack::k3 & 0xff); } elsif ($Crack::byte == 3) { printf("Key = %c%c%c*%c%c%c*%c%c%c*\n", ($Crack::k1 >> 24) & 0xff, ($Crack::k1 >> 16) & 0xff, ($Crack::k1 >> 8) & 0xff, $Crack::k1 & 0xff, ($Crack::k2 >> 24) & 0xff, ($Crack::k2 >> 16) & 0xff, ($Crack::k2 >> 8) & 0xff, $Crack::k2 & 0xff, ($Crack::k3 >> 24) & 0xff, ($Crack::k3 >> 16) & 0xff, ($Crack::k3 >> 8) & 0xff, $Crack::k3 & 0xff); } $Crack::byte++; $Crack::found = 0; } # Found candidate key, move to next packet return; } } # This key was no match, increment key, and try again $Crack::k1 = ($Crack::k1 + $inc) & $mask; if (($Crack::k1 & $mask2) == 0) { $Crack::k2 = ($Crack::k2 + $inc) & $mask; if (($Crack::k2 & $mask2) == 0) { $Crack::k3 = ($Crack::k3 + $inc) & $mask; if (($Crack::k3 & $mask2) == 0) { die "Could not find key"; } } } } } ###################################################################### # Check that the earlier received packets match too. sub check_rest { my($mask) = @_; my($i, $seq_try); # Loop through all packets received before and check them for($i = 0; $i <= $#Crack::seqs; $i++) { $seq_try = (((($Crack::seqs[$i] + $Crack::icv1[$i]) & $mask) ^ ($Crack::k1 & $mask)) + ((($Crack::seqs[$i] + $Crack::icv2[$i]) & $mask) ^ ($Crack::k2 & $mask)) + ((($Crack::seqs[$i] + $Crack::icv3[$i]) & $mask) ^ ($Crack::k3 & $mask)) & $mask); # Check if it is match, if not return error, which # causes the try_crack to move to next key if (($Crack::seq_icv[$i] & $mask) != $seq_try) { $Crack::found = 0; return 0; } } # All matched, so mark this as found $Crack::found++; return 1; } ###################################################################### # Add packet to the pool to be checked. sub add_packet { my($seq, $icv1, $icv2, $icv3, $seq_icv) = @_; push(@Crack::seqs, $seq); push(@Crack::icv1, $icv1); push(@Crack::icv2, $icv2); push(@Crack::icv3, $icv3); push(@Crack::seq_icv, $seq_icv); } ###################################################################### # EOF ###################################################################### --Vn2aEED1rw Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- kivinen@iki.fi --Vn2aEED1rw-- From kivinen@iki.fi Wed Oct 9 07:49:50 2013 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 6C58211E8196 for ; Wed, 9 Oct 2013 07:49:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Mu2NIVlGMfB for ; Wed, 9 Oct 2013 07:49:50 -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 9C4D911E8195 for ; Wed, 9 Oct 2013 07:49:49 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r99Enkuh007092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 9 Oct 2013 17:49:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r99EnjQs006192; Wed, 9 Oct 2013 17:49:45 +0300 (EEST) 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: <21077.27913.340773.579438@fireball.kivinen.iki.fi> Date: Wed, 9 Oct 2013 17:49:45 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 12 min Subject: [IPsec] Comments to draft-mao-ipsecme-ad-vpn-protocol-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: Wed, 09 Oct 2013 14:49:50 -0000 I tried to read this before the interm meeting, but found out that it would require me to read it trough several times before I could really understand it. The basic architecture is simple, we have some trusted third party, ADS which stores all information and ADC devices talk to it and gets some information from there. What that information is and how it is used is not that clear, as it would require to understand what is in each of the payloads and how they are used, i.e. it would require some more time to try to decode what is done in each operation. One question is how is the trust between ADS and ADC creted, how it is protected, and how is it authenticated. As far as I can see from the draft, it says it is outside the scope, i.e. I assume it would need to be configured in ADCs manually. This also creates single point of failure, i.e. if the ADS goes down nothing really works. Old connections stay up, but creating new ones ends up problems. Also using the private-IP address as identity for the ADC might not be that good idea. In section 4 before going to the actual protocol exchanges it would be nice to have some description about the payloads involved. It is hard to understand what "Client Information Registration" does when you do not have any idea what is in the CIDHdr or CI. Adding bit more description in there explaining that for example CIDHdr contains the Client Private Address, which is used to identify the ADC in the messages. Also in the fixed header there is type field, but I have no idea what kind of message is containe for example in the Delete Request. I.e. is there CIHdr or SEssHdr there next? What is the meaning of it etc. As currently written the draft is quite hard to understand, and would most likely require several rereads to be able to really understand how it works. -- kivinen@iki.fi From ynir@checkpoint.com Wed Oct 9 07:53:35 2013 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 EE7AE21E809D for ; Wed, 9 Oct 2013 07:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.353 X-Spam-Level: X-Spam-Status: No, score=-10.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGJ2iAgJz8n3 for ; Wed, 9 Oct 2013 07:53:29 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 60AC821E8092 for ; Wed, 9 Oct 2013 07:53:28 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r99ErHS8013283; Wed, 9 Oct 2013 17:53:17 +0300 X-CheckPoint: {52556DDD-11-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Wed, 9 Oct 2013 17:53:13 +0300 From: Yoav Nir To: Michael Richardson Thread-Topic: [IPsec] Virtual Interim on two AD VPN drafts: Call-in details Thread-Index: AQHOxEF+Qg4YAGGy/E6P0bAass4tkJnsNYYAgAAC3ACAAAtkAA== Date: Wed, 9 Oct 2013 14:53:12 +0000 Message-ID: <415BAB82-3210-4780-8914-02C190F561A3@checkpoint.com> References: <317DC188-9889-43D7-9B42-73E6983D5D0F@vpnc.org> <7439.1381327338@sandelman.ca> <9695.1381327952@sandelman.ca> In-Reply-To: <9695.1381327952@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.130] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <62D21E146E66D047B244F86DAFA1A285@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Virtual Interim on two AD VPN drafts: Call-in details 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, 09 Oct 2013 14:53:35 -0000 On Oct 9, 2013, at 5:12 PM, Michael Richardson wrote: >=20 > Michael Richardson wrote: >>> The call-in details are: >>> Tele: +1 712-775-7400 >>> Code: 809604# >=20 > mcr> Two LD suppliers (entirely different phones) tell me that I can n= ot reach > mcr> this number from my line. >=20 > I wonder if this exchange has an inflated LD rate? > Nice if there was a SIP option to reach them.... how does that ENUM RR wo= rk > again :-) >=20 > mcr> I'm gonna try Google Talk now. >=20 > GoogleTalk connected. As does Skype From kivinen@iki.fi Wed Oct 9 08:08:26 2013 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 7B2DE21F9D4C for ; Wed, 9 Oct 2013 08:08:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPvRvvcFFXpq for ; Wed, 9 Oct 2013 08:08:05 -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 296F521F9D53 for ; Wed, 9 Oct 2013 08:07:46 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r99F7ddv027122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 Oct 2013 18:07:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r99F7cnC023687; Wed, 9 Oct 2013 18:07:38 +0300 (EEST) 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: <21077.28986.498227.592920@fireball.kivinen.iki.fi> Date: Wed, 9 Oct 2013 18:07:38 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <21077.17123.827427.858811@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Cc: "ipsec@ietf.org WG" , Valery Smyslov Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Wed, 09 Oct 2013 15:08:27 -0000 Paul Wouters writes: > On Wed, 9 Oct 2013, Tero Kivinen wrote: > > > For example the > > > > o Check message validity - in particular, check whether values of > > Fragment Number and Total Fragments in Encrypted Fragment Payload > > are valid. If not - message MUST be silently discarded. > > > > should be changed to say: > > > > o Check message validity - in particular, check whether values of > > Fragment Number (must be <= Total Fragments) and Total Fragments > > (must be >= previously seen Total Fragments for this message) in > > Encrypted Fragment Payload are valid. If not - message MUST be > > silently discarded. > > > > It should clearly say that if Total Fragments is less than previously > > seen then this fragment needs to be discarded. > > But you must only do that after the decryption/authentication of the > fragment or we are back at square one with an easy DoS this whole > mechanism was supposed to protect us from. We can drop the packets which have Total Fragments less than previously seen authenticated fragment. To drop packets in the queue, or update the total fragments value needs to be done only based on the authenticated packet, and the document already had those steps after ICV verification, so it already did that correctly. The document was just not really explaining what the message validity checks done in the first bullet point. -- kivinen@iki.fi From paul.hoffman@vpnc.org Wed Oct 9 08:12:18 2013 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 9C25421E8056 for ; Wed, 9 Oct 2013 08:12:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2AVvCjLLj8B for ; Wed, 9 Oct 2013 08:12:17 -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 D0F1E21F9AA7 for ; Wed, 9 Oct 2013 08:12:16 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r99FCF0X023479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 9 Oct 2013 08:12:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <141843C1-8CF5-4C53-8F9D-9B544EF2FE19@vpnc.org> Date: Wed, 9 Oct 2013 08:12:17 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [IPsec] Slides for DMVPN 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, 09 Oct 2013 15:12:18 -0000 https://www.dropbox.com/s/yn5z2n3284c0rii/draft-detienne-dmvpn-00.pdf From fdetienn@cisco.com Wed Oct 9 08:23:18 2013 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 5410511E816E for ; Wed, 9 Oct 2013 08:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7WzRAUyppmI for ; Wed, 9 Oct 2013 08:23:13 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6907611E80DC for ; Wed, 9 Oct 2013 08:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6613; q=dns/txt; s=iport; t=1381332190; x=1382541790; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WsA2sSUyBvzeNQsvUuibO14i319upxasmaWI0d9DiXo=; b=l1FDsGYGqN/4xzMAkEgBlxkPoh/SMEtADdJ88V+QRPBm2FunYus6H13r mt2jvLHOpsgqWWIaFRbdpLuc72+/eqxc/4ausoba/4Bc6sYvq4NXueG06 tcaOlMLy7yiV6A7um5UCwDYWbUCnmMo1O77Skld7l8T9ts7J1X40DE/Sq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAG10VVKtJV2Z/2dsb2JhbABRCYMHOFLBNoEdFnSCJQEBAQMBAQEBZAcLBQsCAQgYCiQnCyUCBAENBQiHeAYMuREEjgOBDwIxB4MfgQQDqgSDJIIq X-IronPort-AV: E=Sophos;i="4.90,1064,1371081600"; d="scan'208";a="270007877" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 09 Oct 2013 15:23:09 +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 r99FN9Y6031798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 15:23:09 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.176]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 10:23:09 -0500 From: "Frederic Detienne (fdetienn)" To: "Manish Kumar (manishkr)" , Yoav Nir Thread-Topic: [IPsec] NUDGE: Reviewing the AD VPN drafts Thread-Index: AQHOv4q3wJGMGhH1F0e56liwS8HiOZniE4+AgAfLtwCAAvxdAA== Date: Wed, 9 Oct 2013 15:23:08 +0000 Message-ID: <1A87A395651F8F439A0C9D8FE20EB0F529F030B3@xmb-aln-x06.cisco.com> References: <68EC0A9FF2689047993640F410CB97E4185A76CE@xmb-rcd-x05.cisco.com> In-Reply-To: <68EC0A9FF2689047993640F410CB97E4185A76CE@xmb-rcd-x05.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.74.179] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6C107A2C1489B142AF25A4DD3AF61BC8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" , Paul Hoffman Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 09 Oct 2013 15:23:18 -0000 Hi Yoav, Thanks indeed for your comments! Please find additional [Fred] comments inl= ine. On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) wrot= e: > Hi Yoav, >=20 > Thanks for your comments. I would try adding clarity to some of these > inline [Manish] to supplement what Mike said. >=20 > Manish >=20 >=20 > On 03/10/13 12:14 AM, "Yoav Nir" wrote: >=20 >> Hi >>=20 >> I have read the DM-VPN draft. I would not call my reading a review, as i= t >> was quite superficial, but here's some thoughts: >>=20 >> - I have to admit that I'm still having trouble wrapping my head around >> some of the concepts. I understand domain-based and route-pased VPNs, as >> well as IPsec and GRE tunnels. But I haven't thought of all the VPN >> endpoints as actually being on the same network. In fact I always though= t >> of VPN as an abstract concept or as a bunch of tunnels, not as a real >> network. Having said that, I'm still trying to get used to the idea of >> NHRP being used for discovery (and to the idea of NHRP itself). To my >> mind a VPN is not an NBMA, but that does not mean an NBMA cannot serve a= s >> a good model for a VPN. >=20 > [Manish]: What the applications running over the VPN see a VPN as (NBMA o= r > otherwise), depends a lot on the services provided on the VPN and the > draft doesn't preclude any possibilities that way. > RFC 4301 already prescribes the arms and ammunitions needed to protect IP > packets (when used in connection with GRE can be used to protect IP > multicast as well as non-IP packets) over untrusted networks. Also, as > appropriately noted in the requirements document, 4301 is silent on the > way the IPSec databases are populated. So the problem is essentially of > discovery and resolution. The discovery can be left to the routing > protocol but the resolution would still be needed unless IGPs are > multi-protocol, which they typically aren't. Even if they were, this woul= d > need a next-hop preservation which won't scale. So, essentially DMVPN > picks up an appropriate address resolution protocol in NHRP which is > enhanced to support both discovery and resolution. This is combined with > GRE to make sure IP multicast and non-IP packets can be seamlessly(withou= t > changing any other layer/protocol) carried across the same tunnel and als= o > to simplify the SPDs. [Fred] I would add that any forwarding database is good as long as it meets= the security requirements of the administrator. Routing tables are used fo= r the description but policy routing can be used too=85 VRF's or routing co= ntext are frequently used in practice as well. There are not "pure" routing= tables anymore. When it comes to L2 forwarding, the SPD today does not even fit anymore and= a total revamp would be necessary. By decoupling the output tunnel selection (or next-hop selection) from the= IPsec policy, we can take advantage of various forwarding policy engines. >> - I like how the process described in section 4.3 to 4.6 quickly >> converges. If host a behind gateway A sends packets to host e behind >> gateway E, and the packets travel though the tunnels AB, BC, CD, and DE, >> then the discovery process might go through several hops, but the next >> tunnel to be set up is AE. There is no case of setting up AC or AD. >> - Reading section 4.8, I see that within a single DM-VPN, there is a >> natural progression from hub&spoke to mesh. There doesn't seem to be a >> place for policy on whether a shortcut should or should not be >> established. The resolution request is forwarded until the egress node. >> So if, for example, you have two government agencies, each with its own >> set of gateways, and two gateways (one belonging to each agency) have a >> tunnel between them, there are two possible configurations: a single >> DM-VPN, in which case they become a mesh, or two DM-VPNs, so that the >> interdomain tunnel endpoints are egress nodes on their respective >> DM-VPNs. Is there a way to implement a policy so that some shortcuts are >> created between those other gateways? >> - Section 4.10 seems to be missing something. Suppose gateway A is >> forwarding traffic to gateway B, and receives an Indirection >> notification. So A sends a Resolution request. After a while, it receive= s >> a Resolution reply with TunS2 and PubS2 addresses. So now A should open = a >> tunnel with TunS2 (right? I'm not clear about the fields). So section >> 4.10 says that authentication between these two nodes will be done using >> certificates. Considering that A has only just heard of TunS2's >> existence, what fields are there going to be in the certificate that wil= l >> let A know that this is indeed TunS2? While a single domain might have >> some convention for this, AD-VPN is supposed to be good for multiple >> administrative domains, so there should be some rule about this. [Fred] We link the tunnel to an IKE profile. This IKE profile turns contai= ns the identity, identity filter, certificate and certificate filter to sen= d to and to accept from the remote peer. So we can create IKE profiles for = each DMVPN and send or accept specific certs. Typically, O or OU fields are= used. regards, fred >> - The same section hints at using certificate fields for filtering. This >> sounds weird. Suppose two gateways learn of each other through the >> resolution process. Now they try to connect, only to find out that the >> certificate fields do not allow them to connect. So we've gone through a= n >> entire IKE handshake just to discover that policy prohibits forming this >> tunnel? And because caches expire, the gateways will try again and again >> to form this tunnel, all the time failing on authorization. >=20 > [Manish]: Iff routing and NHRP policies(in general, all upper layer > policies) allow the shortcut, IKE proceeds till Auth the first time and > fails; this can be conveyed back to the upper layer (NHRP) with an > appropriate error code, which sends a NACK resolution reply. The NACK > serves to stop further resolutions either permanently or for an interval > either configured or communicated by the peer. >=20 >>=20 >>=20 >> Yoav >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Wed Oct 9 09:14:46 2013 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 B973E21F9ED4 for ; Wed, 9 Oct 2013 09:14:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8XP4v+9zdWk for ; Wed, 9 Oct 2013 09:14:46 -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 42CD611E81BA for ; Wed, 9 Oct 2013 09:14:43 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r99GEd9M025164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 9 Oct 2013 19:14:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r99GEcuP015102; Wed, 9 Oct 2013 19:14:38 +0300 (EEST) 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: <21077.33006.734392.994194@fireball.kivinen.iki.fi> Date: Wed, 9 Oct 2013 19:14:38 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 8 min Subject: [IPsec] Update to RFC4307 too? 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, 09 Oct 2013 16:14:46 -0000 While we are updating the algorithm requirements for the ESP and AH, I think we should also update the RFC4307 too at the same time, as a separate document. I think the changes we would like to do there are: Downgrade Diffie-Hellman group 2 (1024-bits) from MUST- to SHOULD. Upgrade Diffie-Hellman group 14 (2048-bits) from SHOULD+ to MUST. Downgrade ENCR_3DES from MUST- to MAY Fix ENCR_NULL from MAY to MUST NOT (already MUST NOT in errata) Upgrade ENCR_AES_CBC from SHOULD+ to MUST Fix PRF_AES128_CBC to PRF_AES128_XCBC and downgrade it from SHOULD+ to SHOULD. Downgrade AUTH_AES_XCBC_96 from SHOULD+ to SHOULD. Then we might want to think whether we want to add new algorithms, i.e. "AES_GCM with a 8/12/16 octect ICV", PRF_HMAC_SHA2_256/384/512, or AUTH_HMAC_SHA2_256_128/384_192/512_256. In all of those I think we might want to pick one length and make that SHOULD... -- kivinen@iki.fi From paul.hoffman@vpnc.org Wed Oct 9 10:40:15 2013 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 323FF21E814A for ; Wed, 9 Oct 2013 10:40:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qmek3tGo1JiV for ; Wed, 9 Oct 2013 10:40:14 -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 879FF21E8149 for ; Wed, 9 Oct 2013 10:40:14 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r99HeAOU028436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 9 Oct 2013 10:40:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <46722366-E9A5-41CB-9E88-D9CA7C3E2629@vpnc.org> Date: Wed, 9 Oct 2013 10:40:10 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [IPsec] Minutes from the Virtual Interim WG meeting, 2013-10-09 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, 09 Oct 2013 17:40:15 -0000 Are at = http://www.ietf.org/proceedings/interim/2013/10/09/ipsecme/minutes/minutes= -interim-2013-ipsecme-2 And a recording is at = http://www.vpnc.org/ipsecme-virtual-interim-2013-10-09.mp3 Participants: please let me know if I messed up any of the notes Everyone: if you want to comment on anything in the presentations, start = a new mailing list thread with a useful Subject: line; don't reply to = this message. --Paul Hoffman= From svanru@gmail.com Wed Oct 9 22:34:16 2013 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 5BF8421E8284 for ; Wed, 9 Oct 2013 22:34:16 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXUfks19oSD8 for ; Wed, 9 Oct 2013 22:34:16 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9B40A21E8283 for ; Wed, 9 Oct 2013 22:34:15 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id es20so1631868lab.10 for ; Wed, 09 Oct 2013 22:34:14 -0700 (PDT) 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; bh=4V2FeQARoHNDzilyZX1GP/tZHqSF8gFDCpa1jWM9yKw=; b=fajse/BjvwsBXOtwVmA6SnsKEKene5bGGcXdu08cnoKAlQc1JhJCVmVw0kER1KMNOZ Fiq46JzV+kLrBV3Vd6Z/iRVAp9m0FsbjisTfg8mTBhIxy5TPZMl6Wms9+frhzrsMQidg ZO20fyUnZvNkoVrPtrMjkZ4LJQfSp7lNXeVPx9rD66SA8/83ET65wSjpv9ou8c9s4oXa TM+xlaSIXjjDwj/gftfQL6sb3mK2tUMuBtysLe8d3kR/soJxVi7/4GvTyb+vNsgcw+Hg KQI3md6odOOEI4ck0lmCGzdvORYsB28qvyqN/3LV07vb3jzsocvm3F9muaXxZZGEkNdc LriQ== X-Received: by 10.112.149.197 with SMTP id uc5mr10305568lbb.19.1381383254622; Wed, 09 Oct 2013 22:34:14 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id oc1sm28559128lbb.3.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 09 Oct 2013 22:34:13 -0700 (PDT) Message-ID: <1B20E03AB216428AA7F16B898AA49FFD@buildpc> From: "Valery Smyslov" To: "Paul Wouters" References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> Date: Thu, 10 Oct 2013 09:34:20 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Thu, 10 Oct 2013 05:34:16 -0000 >> I also think that PMTU discovery isn't very useful for IKE. >> That's why it is MAY. > > That does not help implementors who still have to implement the MAY's. > if even you as a document author does not think it is veru usefil, > then I think it should just not be in the document. Sorry, I wasn't very clear. By "isn't very useful" I meant that it is not useful for the usual PMTU discovery goal in TCP - to find _maximum_ IP datagram size that is not fragmented by IP level. In IKE its the goal is different - to find _some_reasonable_ IP datagram size that is not fragmented by IP. If we have the size that is guaranteed to not be fragmented, no PMTU discovery will be needed. As far as I understand, for IPv6 it is 1280 bytes. But as far as I know, there's no such value for IPv4. If we mandate (or recommend) using really small value e.g. 128 bytes, than the perfomance will suffer badly, so it it not a good option. I'm especially worring about network I'm not familiar with - mobile networks or other constrained environments. It would be great if some experts in such networks could clarify this. From svanru@gmail.com Wed Oct 9 22:44:44 2013 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 C428E21E8284 for ; Wed, 9 Oct 2013 22:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUqqQL5lgtJL for ; Wed, 9 Oct 2013 22:44:44 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4368F11E8132 for ; Wed, 9 Oct 2013 22:44:42 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id er20so1604059lab.35 for ; Wed, 09 Oct 2013 22:44:41 -0700 (PDT) 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; bh=6hOPusNEKAU2UHVUhbdO5IAyPqda/80cZb41QZuidmo=; b=igQvDFsojkxR2nmv+hCz3hbqwWdUAMEAW6A8gUy3yDoiZLKjtdSNPd0x+m/qJ93d8D M6or+yT9pwMclDqVAs65ubahTcLn9lTW6F1HkFKoTdfnUIiGNwd12kIP3vF87HGezE65 WwUvZzHSWw58Bf/QItB9WVlSTJovUiZ3t5Rlmykj6B4PaLIz0R1LxOhc48ZWwkVKOGiL S+vhSIsaVsP8kE2pMKACU3UoyPhQeo7eNzb+IxQz89/2NitwvG1R9gss1+kvVoLFkxPC GeffosJSX3GAWHjAqkOxfcBFrC6aeMP0QRVgydP2AIeSMj4h3G7u64WN7X7k09AauXmc VyVw== X-Received: by 10.152.87.143 with SMTP id ay15mr9860426lab.2.1381383881102; Wed, 09 Oct 2013 22:44:41 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id f17sm28568105lbo.12.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 09 Oct 2013 22:44:40 -0700 (PDT) Message-ID: <270FB1A1195F4F17B8BCCE1395DBB839@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com><44D6A1836A274C98907D95D59E530FE6@buildpc><524EC6D8.9040006@gmail.com><8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <21077.17123.827427.858811@fireball.kivinen.iki.fi> Date: Thu, 10 Oct 2013 09:44:47 +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, Paul Wouters Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-fragmentation-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: Thu, 10 Oct 2013 05:44:44 -0000 Hi Tero, > Valery Smyslov writes: >> There is no field "id" in IKEv2 Fragmentation Payload - just Fragment >> Number >> and Total Fragments. But Total Fragments field plays a dual role if >> peer uses PMTU discovery - i.e. tries several fragment sizes. >> In this case Total Fragments allows to distinguish between fragments from >> different sets (assuming that trying smaller fragment size results in >> increasing number of fragments). > > This was the thing that confiused me when reading the document. The > section 2.5 should explain the Total Fragments much better. I.e. > change the definition something like: > > o Total Fragments (2 octets) - number of fragments original message > was divided into. If original message is resent with different > fragmentation boundaries this value MUST be larger than the > previously used Total Fragments value, i.e the responder will > use this to detect whether the incoming message belongs to the > group of packets fragmented in same way. This field MUST NOT be > zero. > > Or something like that. OK. > Also I do not understand why the Fragment Number and Total Fragments > start from 1. I think it would be more logical to have first fragment > be 0, second 1, and the Total Fragments would be The Last Fragment# > field. That way we do not need to have special check that fragment > needs to be ignored if Fragment Number or Total Fragments are 0. That's a matter of taste. Actually, I wanted to leave one special value - zero, just in case the protocol needs to be extended in the future. I have currently no idea how it can be extended (if ever), but anyway it is a good practice in protocol design to leave this possibility. > In general I think the sending and receiving rules should be explained > a bit more. > > For example the > > o Check message validity - in particular, check whether values of > Fragment Number and Total Fragments in Encrypted Fragment Payload > are valid. If not - message MUST be silently discarded. > > should be changed to say: > > o Check message validity - in particular, check whether values of > Fragment Number (must be <= Total Fragments) and Total Fragments > (must be >= previously seen Total Fragments for this message) in > Encrypted Fragment Payload are valid. If not - message MUST be > silently discarded. OK. > It should clearly say that if Total Fragments is less than previously > seen then this fragment needs to be discarded. > > Now when I am reading th text several times through I see that all the > required things are there, but when I was reading it first time > through it was really hard to parse what is going on, and especially > as I missed the dual role of the Total Fragments I got confused. > > It might be enough to just add more text in the Total Fragments > description, clearly stating that it has dual role, i.e. telling what > is the max fragment number of this message, and to separate the > different fragmentation boundaries. My text above does not yet > properly describe that either, so some better text is needed. OK, I'll try to explain in more details. Thanks, Valery. From yaronf.ietf@gmail.com Wed Oct 9 23:00:14 2013 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 90E7D21E8283 for ; Wed, 9 Oct 2013 23:00:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkYUI-JbHhE7 for ; Wed, 9 Oct 2013 23:00:14 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AF8F721E80DB for ; Wed, 9 Oct 2013 23:00:13 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u56so1968935wes.33 for ; Wed, 09 Oct 2013 23:00:12 -0700 (PDT) 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=aDyX5FbIlFqq/jcRQrVMpG7Z/54bD/BLb1oZdhQIVlE=; b=zDYZ+p+NE0bbrbjfP/2esHsqBeUIdn3khJeI9qtN6pWsM3uLKWAOyORL8/jsEcbuq6 M2cjQCvQ+fF24mAPCgS7OfZsuzqIrCcEcGkEQy0s8zbUOb/U22aZT2JJcU3fIkkI49hO WTo/qyS4bZBsThFcpWdB4QaPTHf5QFub8u6Wi5/3S6NdEb1JuPMAbKnjVLw41lNPX0q6 woBu2bsAi/QsdOCkg07TXKn2tBvppH3rA0PKszaenrqsA1qrj+UY2iFMztiB0ivyBLqL 4H2d5sf2SQA+tGpW2hdnlN9y1qaBaITwiKL30rUYm8OrS3MBIkC7iAdFrjLKEVtF4FU4 SkRw== X-Received: by 10.195.13.164 with SMTP id ez4mr10415437wjd.11.1381384812665; Wed, 09 Oct 2013 23:00:12 -0700 (PDT) Received: from [10.0.0.8] ([109.65.223.20]) by mx.google.com with ESMTPSA id jf2sm22093641wic.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Oct 2013 23:00:12 -0700 (PDT) Message-ID: <5256426B.4030707@gmail.com> Date: Thu, 10 Oct 2013 09:00:11 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Valery Smyslov , Paul Wouters References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <1B20E03AB216428AA7F16B898AA49FFD@buildpc> In-Reply-To: <1B20E03AB216428AA7F16B898AA49FFD@buildpc> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Thu, 10 Oct 2013 06:00:14 -0000 >>> I also think that PMTU discovery isn't very useful for IKE. >>> That's why it is MAY. >> >> That does not help implementors who still have to implement the MAY's. >> if even you as a document author does not think it is veru usefil, >> then I think it should just not be in the document. > > Sorry, I wasn't very clear. By "isn't very useful" I meant that it is > not useful > for the usual PMTU discovery goal in TCP - to find _maximum_ IP datagram > size that is not fragmented by IP level. In IKE its the goal is different - > to find _some_reasonable_ IP datagram size that is not fragmented by IP. > > If we have the size that is guaranteed to not be fragmented, > no PMTU discovery will be needed. As far as I understand, for IPv6 > it is 1280 bytes. But as far as I know, there's no such value for IPv4. > If we mandate (or recommend) using really small value e.g. 128 bytes, > than the perfomance will suffer badly, so it it not a good option. > I'm especially worring about network I'm not familiar with - > mobile networks or other constrained environments. > It would be great if some experts in such networks could clarify this. > I'm even more worried that if we use small fragments, reliability will deteriorate. Because we do not have per-packet acknowledgement, and so if any fragment is dropped, the whole message must be resent. This is probably a greater risk in mobile networks. From svanru@gmail.com Wed Oct 9 23:10:16 2013 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 91F9311E8121 for ; Wed, 9 Oct 2013 23:10:16 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwt77eiEY-dl for ; Wed, 9 Oct 2013 23:10:16 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id DFD9C11E8133 for ; Wed, 9 Oct 2013 23:10:11 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id y6so1691467lbh.35 for ; Wed, 09 Oct 2013 23:10:04 -0700 (PDT) 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; bh=Zrjxdr8DHn9oZXIKxpSrGLSJSYRCI8zndKrC6ARioKA=; b=KpMAVmvbmBPDl+8kTqGfGw1pNBs2iiBpt4BGnQd6GfrtFmKUlCkmniZRmBMnjr+dcN OwEoa8MS1GGKDAqfjvvNs6BwqeyZXdmgeI2niTTHWjC8D2nUtBRobzCP5XkeRV71xz1r TLRSPtirda2A0lYw1AtOtNohscnbko2yC9x+GauNW3W7/4fGJzJs9v9G5BYDVMOesbq9 N7kG5dOJqHddZnIYLzKODFgz6GOevvR0HiBRqK48oBVAB+kpwSIPYH/yP9Iz5eznzhl8 jTYi8IvNcJt+xBt3kQ//ITCYYmbXAJb/h/itZjTh/c/SUtzj+XJyolc725OS+mz9phpm IgXg== X-Received: by 10.152.8.115 with SMTP id q19mr9988296laa.16.1381385404831; Wed, 09 Oct 2013 23:10:04 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id mr1sm28627707lbc.16.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 09 Oct 2013 23:10:04 -0700 (PDT) Message-ID: <9371D0D218044FE79F26DFC1637FA821@buildpc> From: "Valery Smyslov" To: "Paul Wouters" , "Tero Kivinen" References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <21077.17123.827427.858811@fireball.kivinen.iki.fi> Date: Thu, 10 Oct 2013 10:10:10 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Thu, 10 Oct 2013 06:10:16 -0000 Hi Paul, >> o Check message validity - in particular, check whether values of >> Fragment Number and Total Fragments in Encrypted Fragment Payload >> are valid. If not - message MUST be silently discarded. >> >> should be changed to say: >> >> o Check message validity - in particular, check whether values of >> Fragment Number (must be <= Total Fragments) and Total Fragments >> (must be >= previously seen Total Fragments for this message) in >> Encrypted Fragment Payload are valid. If not - message MUST be >> silently discarded. >> >> It should clearly say that if Total Fragments is less than previously >> seen then this fragment needs to be discarded. > > But you must only do that after the decryption/authentication of the > fragment or we are back at square one with an easy DoS this whole > mechanism was supposed to protect us from. > > Which of course means an attacker can just send crap faster that you can > verify it is crap after performing crypto on the fragment. Not necessary. It depends on the state receiver currently is in. When you receive very first fragment and start reassembly you remember its Total Fragments field (of course after you validate message). After that you have the following possibilities. 1. You receive fragment with the same Total Fragments.You continue reassembling, adding this fragment to the queue, or discarding it if it is a duplicate packet 2. You receive fragment with the smaller Total Fragments. It may either be a late packet from the previous set of fragments (larger in size) that accidently reach us, or it may be attack packet, or it may be packet from broken peer. In any case it is safe to discard it without any verification. 3. You receive fragment with greater Total Fragments. In this case, if you already successfully reassembled message and send a response, it most probably means that response didn't reach peer. In this case it is safe to retransmit response without any verification of fragment authenticity, it won't hurt peer even if it was faked fragment. You may rate limit such responses or you may verify fragment before - as you wish. And if you support PMTU discovery, you may refragment response into smaller fragments, but in this case it is better to verify fragment before, as refragmentation cost is not zero. If you still in the process of reassembling, than yes, you need to verify fragment and, if it is valid, discard all received so far fragments and start reassembling over, as it becomes clear that peer decreased fragmen size and retransmits new set of fragments, so its pointless for you to wait for the rest of fragments from previous set. From svanru@gmail.com Wed Oct 9 23:12:58 2013 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 7CD0811E8132 for ; Wed, 9 Oct 2013 23:12:58 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bp8A4XRa6Hj for ; Wed, 9 Oct 2013 23:12:58 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C02C511E8135 for ; Wed, 9 Oct 2013 23:12:55 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id w6so1676250lbh.33 for ; Wed, 09 Oct 2013 23:12:54 -0700 (PDT) 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; bh=CR5uf9Bn8TXjqfyrz3AHuH297locY1+bBuv73PfPbtI=; b=i/g3mIitRS62mJzX9osnct1pENWtPnegigS2XifO3PpV/8WRt77b/TckBVOLJhwnlM IOaUXWGVfR5/zN/7ElhYHsAn0IswSJS4q2vG6qc3UBRimbjShcJNL3IGjHnoFkcYUyPI xGz1yf/hbgF6RbJFuzMLe5ygTPEQLI7tzL+vidTLXOSvWfwXnwOsMkvaTQXp+ObXw2vX HvfImZ5WFBtQQpRqjnhqfE1SrRVRABJhCNp6QvrjViujb3Fdzk/35Zq0zMZC7QRnp2+s M0lelocwFbVS+PtWPWyR/4skC7NTblOPmXzJAUbGfgsdZTMg8lXNnebUyVotRAE0SjtN E37Q== X-Received: by 10.152.45.106 with SMTP id l10mr10038272lam.12.1381385574842; Wed, 09 Oct 2013 23:12:54 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id k6sm38637021lae.9.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 09 Oct 2013 23:12:54 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yaron Sheffer" , "Paul Wouters" References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <1B20E03AB216428AA7F16B898AA49FFD@buildpc> <5256426B.4030707@gmail.com> Date: Thu, 10 Oct 2013 10:13:01 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Thu, 10 Oct 2013 06:12:58 -0000 >> Sorry, I wasn't very clear. By "isn't very useful" I meant that it is >> not useful >> for the usual PMTU discovery goal in TCP - to find _maximum_ IP datagram >> size that is not fragmented by IP level. In IKE its the goal is >> different - >> to find _some_reasonable_ IP datagram size that is not fragmented by IP. >> >> If we have the size that is guaranteed to not be fragmented, >> no PMTU discovery will be needed. As far as I understand, for IPv6 >> it is 1280 bytes. But as far as I know, there's no such value for IPv4. >> If we mandate (or recommend) using really small value e.g. 128 bytes, >> than the perfomance will suffer badly, so it it not a good option. >> I'm especially worring about network I'm not familiar with - >> mobile networks or other constrained environments. >> It would be great if some experts in such networks could clarify this. >> > I'm even more worried that if we use small fragments, reliability will > deteriorate. Because we do not have per-packet acknowledgement, and so if > any fragment is dropped, the whole message must be resent. This is > probably a greater risk in mobile networks. Yes, a good point. From kivinen@iki.fi Thu Oct 10 05:59:56 2013 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 36A3411E8165 for ; Thu, 10 Oct 2013 05:59:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Os363DmFCLQW for ; Thu, 10 Oct 2013 05:59:54 -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 2D81A21E8103 for ; Thu, 10 Oct 2013 05:59:31 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9ACxLxB007316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 Oct 2013 15:59:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9ACxKL2010598; Thu, 10 Oct 2013 15:59:20 +0300 (EEST) 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: <21078.42152.502994.298696@fireball.kivinen.iki.fi> Date: Thu, 10 Oct 2013 15:59:20 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <5256426B.4030707@gmail.com> References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <1B20E03AB216428AA7F16B898AA49FFD@buildpc> <5256426B.4030707@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min Cc: ipsec@ietf.org, Valery Smyslov , Paul Wouters Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Thu, 10 Oct 2013 12:59:56 -0000 Yaron Sheffer writes: > I'm even more worried that if we use small fragments, reliability will > deteriorate. Because we do not have per-packet acknowledgement, and so > if any fragment is dropped, the whole message must be resent. This is > probably a greater risk in mobile networks. The fix there is to use IP level fragmentation... And only switch to use small IKEv2 level fragmented packets if that does not work. This whole protocol is only needed on the broken networks, so it does not matter if it is very suboptimal, as we can always say that if you enable fragmentation support on your devices, things will work better. -- kivinen@iki.fi From paul@cypherpunks.ca Fri Oct 11 11:49:22 2013 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 7BB5F11E8199 for ; Fri, 11 Oct 2013 11:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4Fm2acI+MLD for ; Fri, 11 Oct 2013 11:49:01 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id B0D9111E8188 for ; Fri, 11 Oct 2013 11:49:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cxJ9555vcz4Fd; Fri, 11 Oct 2013 14:48:57 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id is6lWH1gYNr3; Fri, 11 Oct 2013 14:48:56 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Fri, 11 Oct 2013 14:48:56 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 7E408800A9; Fri, 11 Oct 2013 14:48:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7135D80096; Fri, 11 Oct 2013 14:48:57 -0400 (EDT) Date: Fri, 11 Oct 2013 14:48:57 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: <21077.33006.734392.994194@fireball.kivinen.iki.fi> Message-ID: References: <21077.33006.734392.994194@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Update to RFC4307 too? 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, 11 Oct 2013 18:49:22 -0000 On Wed, 9 Oct 2013, Tero Kivinen wrote: > I think the changes we would like to do there are: > > Downgrade Diffie-Hellman group 2 (1024-bits) from MUST- to SHOULD. Actually, 4307 states: 3.1.2. Diffie-Hellman Groups There are several Modular Exponential (MODP) groups that are defined for use in IKEv2. They are defined in both the [IKEv2] base document and in the MODP extensions document. They are identified by group number. Any groups not listed here are considered as "MAY be implemented". Group Number Bit Length Status Defined 2 1024 MODP Group MUST- [RFC2409] 14 2048 MODP Group SHOULD+ [RFC3526] which seems to imply 768 MODP group is "MAY". Which is confirmed in RFC 4109. So I think we should also update 768 MODP group to MUST NOT. > Downgrade ENCR_3DES from MUST- to MAY I'm not sure how I feel about that. There are still not many alternatives to AES, and I think having 3DES in there is good. Yes it is slow, but I don't think it has been concluded to be weak or insecure. > Then we might want to think whether we want to add new algorithms, > i.e. "AES_GCM with a 8/12/16 octect ICV", PRF_HMAC_SHA2_256/384/512, > or AUTH_HMAC_SHA2_256_128/384_192/512_256. In all of those I think we > might want to pick one length and make that SHOULD... Sounds good. Paul From ynir@checkpoint.com Fri Oct 11 13:02:14 2013 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 90CDD21F9ACA for ; Fri, 11 Oct 2013 13:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.886 X-Spam-Level: X-Spam-Status: No, score=-9.886 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_BACKHAIR_24=1, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRRfdcr00yIN for ; Fri, 11 Oct 2013 13:02:06 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E092D21F9C05 for ; Fri, 11 Oct 2013 13:01:52 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9BK1bSG031369; Fri, 11 Oct 2013 23:01:42 +0300 X-CheckPoint: {52585921-B-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Fri, 11 Oct 2013 23:01:32 +0300 From: Yoav Nir To: Tero Kivinen Thread-Topic: [IPsec] Comments to draft-nir-ipsecme-cafr-02 Thread-Index: AQHOxOA21gG2CqD9LUuJ2TGQW86dYJnvvVYA Date: Fri, 11 Oct 2013 20:01:31 +0000 Message-ID: <93B6E0AE-A4D6-458A-A561-B7AE545A1670@checkpoint.com> References: <21077.14759.253612.481464@fireball.kivinen.iki.fi> In-Reply-To: <21077.14759.253612.481464@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.12] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-ID: <2BD4AD2D3DB96C4EB992965A3FE07D60@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] Comments to draft-nir-ipsecme-cafr-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: Fri, 11 Oct 2013 20:02:14 -0000 On Oct 9, 2013, at 2:10 PM, Tero Kivinen wrote: > In section "2.2. Verifying the HAND_OVER_CHILD_SAS Notification" the > document lists operations which needs to be done when handling the > notification. The process seems otherwise quite good, expect the error > handling seems to be bit drastic. >=20 > It currently says that if the authenticated identites are different > then other end replies with INVALID_SYNTAX error message: >=20 > ---------------------------------------------------------------------- > 2.2. Verifying the HAND_OVER_CHILD_SAS Notification > ... > o The authenticated identities of both sides under the new IKE SA > are the same as those under the old IKE SA. If the authenticated > identity of one peer differs from the authenticated identity that > it had in the previous IKE SA, the other side MUST respond with an > INVALID_SYNTAX notification. > ... > ---------------------------------------------------------------------- >=20 > From RFC5996, the INVALID_SYNTAX processing is described as following: >=20 > ---------------------------------------------------------------------- > 2.21.3. Error Handling after IKE SA is Authenticated > ... > If a peer parsing a request notices that it is badly formatted (after > it has passed the message authentication code checks and window > checks) and it returns an INVALID_SYNTAX notification, then this > error notification is considered fatal in both peers, meaning that > the IKE SA is deleted without needing an explicit Delete payload. > ---------------------------------------------------------------------- >=20 > I.e. the INVALID_SYNTAX notification is considered fatal in both > peers, meaning that IKE SA is deleted. In this case this will cause > the OLD IKE SA to be deleted. I do not think we want to be that to > happen. Perhaps something less fatal error message would be better as > this is not error cases listed in the RFC5996: "message that was > received was invalid because some type, length, or value was out of > range or because the request was rejected for policy reasons." (Ok, it > could be considered to be rejected because policy reasons). >=20 > As we are moving CHILD SAs, perhaps we could consider this as normal > "Generic Child SA error" and use NO_PROPOSAL_CHOSEN.=20 Deleting the old IKE SA is fine, as we're only transferring the child SAs w= hen we're ready to delete the old IKE SA. See section 3. NO_PROPOSAL_CHOSEN= is specifically about crypto-suites, so I wouldn't use that. Perhaps INVAL= ID_IKE_SPI, because that IKE SPI in the notify payload is invalid. But INVA= LID_IKE_SPI in RFC 5996 is specifically supposed to be outside of IKE, and = refers to the IKE SPI field of the packet, not the data field of a notifica= tion payload. So either we need a specific error notification, or decide to= send no notification. If the responder does not repeat the notification, t= he child SAs are not transferred. The initiator is not told whether this wa= s because of mismatched identities, a policy issue or some other reason, bu= t I'm not sure that is really needed.=20 > Also in the end of the section 2.2 it says: >=20 > ---------------------------------------------------------------------- > If the Initiator has sent the notification, but the notification from > the Responder does not match the IKE SPIs in the Initiator's > notification, the Initiator MUST send a SYNTAX_ERROR notification and > MUST NOT transfer the Child SAs. > ---------------------------------------------------------------------- >=20 > but there is no SYNTAX_ERROR error message in the IKEv2. This on the > other hand is clearly fatal error, as it indicates that the responder > has somehow corrupted its state, or there is implementation bug there, > if it cannot copy SPI from the request to the reply properly. On the > other hand I see no reason why the reply should include the SPI it > all. It would be better that initiator just sends the notify with the > SPI, and responder replies with the notify and does not include SPI at > all (i.e. its notify data would be empty). The SPI in the responder > message does not have any meaning or use. I agree that the data is superfluous, but it's easier for implementations t= o have just one variant of this message. > In section 7 Security Considerations I can see the attack that can > happen if the authenticated identities are not same. I.e. if host uses > authenticated identities also outside the IPsec. For example the host > might export the authenticated identities to the nfs-server, and > nfs-server could use that to verify what kind of operations the user > can do. In that case attacker might create IKE SA and Child SA to > nfs-server of the server, and then move the Child SA to another users > IKE SA, and then start doing nfs-requests. Now when nfs-server asks > from the IPsec engine who is on the other end of the protected IPsec > tunnel the IPsec engine would respond wrong users... >=20 > As long as the IPsec is mostly used for VPNs this kind of setups are > not used, but if host to host IPsec ever comes reality this kind of > setups might happen, so I think that check is very important=85 There are some VPN products that export the IP<-->User identity mapping to = other network devices such as firewalls, servers and routers. Even without = this, if one peer can "transfer" the SA to the IKE SA of another peer, the = original owner still has the keys (so old peer can use the SA, while new pe= er cannot, despite the "transfer"). All actions done by the old peer now, w= ill be logged as if they had been done by the new peer. Yoav From Johannes.Merkle@secunet.com Mon Oct 14 01:24:45 2013 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 A0AD621E80C4 for ; Mon, 14 Oct 2013 01:24:45 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-4BIqtAjW2h for ; Mon, 14 Oct 2013 01:24:40 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 98E0521F9DA1 for ; Mon, 14 Oct 2013 01:24:36 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id C45051A0071; Mon, 14 Oct 2013 10:24:32 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7Hcjblp2egwn; Mon, 14 Oct 2013 10:24:31 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 996891A006C; Mon, 14 Oct 2013 10:24:31 +0200 (CEST) Received: from [172.16.40.201] ([172.16.40.201]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Oct 2013 10:24:31 +0200 Message-ID: <525BAA3F.4070204@secunet.com> Date: Mon, 14 Oct 2013 10:24:31 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "ipsec@ietf.org WG" , kivinen@iki.fi X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2013 08:24:31.0824 (UTC) FILETIME=[CEBA4500:01CEC8B6] Subject: [IPsec] Moving forward with draft-kivinen-ipsecme-signature-auth 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, 14 Oct 2013 08:24:45 -0000 draft-kivinen-ipsecme-signature-auth-01 is about to expire. Given the current discussions on potential backdoors in NIST curves (don't want to participate in these conspiracy theories though), signature algorithm flexibility may be even more desirable. Can we move forward with that draft? I am not sure if there have been considerable comments or objections. Johannes From ynir@checkpoint.com Mon Oct 14 02:05:56 2013 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 3622821E80B7 for ; Mon, 14 Oct 2013 02:05:56 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9BZp-vH7QeN for ; Mon, 14 Oct 2013 02:05:50 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B5AD221E8088 for ; Mon, 14 Oct 2013 02:05:49 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9E95UYF016684; Mon, 14 Oct 2013 12:05:30 +0300 X-CheckPoint: {525BB3CD-1A-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Mon, 14 Oct 2013 12:05:22 +0300 From: Yoav Nir To: Johannes Merkle Thread-Topic: [IPsec] Moving forward with draft-kivinen-ipsecme-signature-auth Thread-Index: AQHOyLbdECChwNaWCUKxjIAThM1TtJnztVaA Date: Mon, 14 Oct 2013 09:05:22 +0000 Message-ID: <224E3077-9CF2-4517-BD0F-F73811436CE4@checkpoint.com> References: <525BAA3F.4070204@secunet.com> In-Reply-To: <525BAA3F.4070204@secunet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <155D6FBA0EC50D459810FC95B32EADD2@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" , "" Subject: Re: [IPsec] Moving forward with draft-kivinen-ipsecme-signature-auth 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, 14 Oct 2013 09:05:56 -0000 I agree. We should either adopt it in the WG or ask Sean to publish this as= an individual submission. Yoav On Oct 14, 2013, at 11:24 AM, Johannes Merkle = wrote: > draft-kivinen-ipsecme-signature-auth-01 is about to expire. Given the cur= rent discussions on potential backdoors in NIST > curves (don't want to participate in these conspiracy theories though), s= ignature algorithm flexibility may be even more > desirable. >=20 > Can we move forward with that draft? I am not sure if there have been con= siderable comments or objections. >=20 > Johannes > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Mon Oct 14 05:55:57 2013 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 A90F611E8127 for ; Mon, 14 Oct 2013 05:55:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f73ZWDIQTGEx for ; Mon, 14 Oct 2013 05:55:57 -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 378D111E8182 for ; Mon, 14 Oct 2013 05:55:53 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9ECtjmL019914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Oct 2013 15:55:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9ECthWY029267; Mon, 14 Oct 2013 15:55:43 +0300 (EEST) 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: <21083.59855.598348.506862@fireball.kivinen.iki.fi> Date: Mon, 14 Oct 2013 15:55:43 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <21077.33006.734392.994194@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 9 min Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Update to RFC4307 too? 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, 14 Oct 2013 12:55:57 -0000 Paul Wouters writes: > which seems to imply 768 MODP group is "MAY". Which is confirmed in RFC > 4109. So I think we should also update 768 MODP group to MUST NOT. I agree on that. I thought we deprecated that already in the RFC4306 by saying: ---------------------------------------------------------------------- Appendix B: Diffie-Hellman Groups ... The strength supplied by group one may not be sufficient for the mandatory-to-implement encryption algorithm and is here for historic reasons. ... ---------------------------------------------------------------------- but it might be better to say MUST NOT explictly. > > Downgrade ENCR_3DES from MUST- to MAY > > I'm not sure how I feel about that. There are still not many > alternatives to AES, and I think having 3DES in there is good. Yes it is > slow, but I don't think it has been concluded to be weak or insecure. I think we need to downgrade it from MUST to something else anyways, as small implementations which do have hardware support for AES, might not want to add implementation for 3DES at all. You can still implement and use it, it just would not be mandatory to implement algorithm anymore. I.e. if you need to pick one algoritm I think AES is better than 3DES. If you want to implement 2 algorithms then implementing both AES and 3DES is ok. We could also make it SHOULD- instead of MAY, but I think MAY is still better. Note to others: the main problem with 3DES (i.e. the too long block length) is not relevant here as we are talking about the encryption algorithm protecting key management messages, where the number of actual bytes transmitted are going to be quite low compared to the block length restrictions from 3DES. There is mandatory requirement to rekey after 2^32 IKEv2 messages has been transmitted anyways, but in general the amount of messages transmitted is between 2 -- 10000. -- kivinen@iki.fi From kivinen@iki.fi Mon Oct 14 06:11:04 2013 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 952DA21F9B8A for ; Mon, 14 Oct 2013 06:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.099 X-Spam-Level: X-Spam-Status: No, score=-102.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_24=1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue0RbktOMHA6 for ; Mon, 14 Oct 2013 06:11:02 -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 7563811E8184 for ; Mon, 14 Oct 2013 06:10:54 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9EDAhd3002807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Oct 2013 16:10:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9EDAh4N020627; Mon, 14 Oct 2013 16:10:43 +0300 (EEST) 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=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21083.60755.141769.321447@fireball.kivinen.iki.fi> Date: Mon, 14 Oct 2013 16:10:43 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <93B6E0AE-A4D6-458A-A561-B7AE545A1670@checkpoint.com> References: <21077.14759.253612.481464@fireball.kivinen.iki.fi> <93B6E0AE-A4D6-458A-A561-B7AE545A1670@checkpoint.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 14 min Cc: "" Subject: Re: [IPsec] Comments to draft-nir-ipsecme-cafr-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: Mon, 14 Oct 2013 13:11:04 -0000 Yoav Nir writes: > > I.e. the INVALID=5FSYNTAX notification is considered fatal in both > > peers, meaning that IKE SA is deleted. In this case this will cause= > > the OLD IKE SA to be deleted. I do not think we want to be that to > > happen. Perhaps something less fatal error message would be better = as > > this is not error cases listed in the RFC5996: "message that was > > received was invalid because some type, length, or value was out of= > > range or because the request was rejected for policy reasons." (Ok,= it > > could be considered to be rejected because policy reasons). > >=20 > > As we are moving CHILD SAs, perhaps we could consider this as norma= l > > "Generic Child SA error" and use NO=5FPROPOSAL=5FCHOSEN.=20 >=20 > Deleting the old IKE SA is fine, as we're only transferring the > child SAs when we're ready to delete the old IKE SA. See section 3. Yes, but usually when you have error cases which might happen in normal case that kind of fatal processing of the error is bit drastic. Anyways if you think the deletion of old IKE SA (and all Child SAs in it, which did not get transferred), then I think it would be better to explictly mention it here. I.e. any errors happening during the handing over Child SAs will cause old IKE SA and all Child SAs to be deleted without explicit delete notification.=20 > NO=5FPROPOSAL=5FCHOSEN is specifically about crypto-suites, so I > wouldn't use that. NO=5FPROPOSAL=5FCHOSEN is also used as "Generic" Child SA error when Ch= ild SA cannot be created for some other reason. When trying to handing Child SAs from one IKE SA to another, and that fails because Child SAs cannot be created in the new IKE SA because of the policy reasons (i.e. not same authenticated identity), I would consider that as case where Child SA cannot be created, or in this case handed over. See RFC5996 section 3.10.1 description of NO=5FPROPOSAL=5FCHOSEN and th= e second last sentence there. > Perhaps INVALID=5FIKE=5FSPI, because that IKE SPI in > the notify payload is invalid. But INVALID=5FIKE=5FSPI in RFC 5996 is= > specifically supposed to be outside of IKE, and refers to the IKE > SPI field of the packet, not the data field of a notification > payload. INVALID=5FIKE=5FSPI cannot be used, it has very specific meanings and w= e cannot change that.=20 > So either we need a specific error notification, or decide > to send no notification. If the responder does not repeat the > notification, the child SAs are not transferred. The initiator is > not told whether this was because of mismatched identities, a policy > issue or some other reason, but I'm not sure that is really needed. =20= That would be one option too, i.e. if no confirmation comes back, then no SAs were moved. > > Also in the end of the section 2.2 it says: > >=20 > > -------------------------------------------------------------------= --- > > If the Initiator has sent the notification, but the notification = from > > the Responder does not match the IKE SPIs in the Initiator's > > notification, the Initiator MUST send a SYNTAX=5FERROR notificati= on and > > MUST NOT transfer the Child SAs. > > -------------------------------------------------------------------= --- > >=20 > > but there is no SYNTAX=5FERROR error message in the IKEv2. This on = the > > other hand is clearly fatal error, as it indicates that the respond= er > > has somehow corrupted its state, or there is implementation bug the= re, > > if it cannot copy SPI from the request to the reply properly. On th= e > > other hand I see no reason why the reply should include the SPI it > > all. It would be better that initiator just sends the notify with t= he > > SPI, and responder replies with the notify and does not include SPI= at > > all (i.e. its notify data would be empty). The SPI in the responder= > > message does not have any meaning or use. >=20 > I agree that the data is superfluous, but it's easier for > implementations to have just one variant of this message. I actually disagree on that. Having two ways of parsing / generating this message is about same complexity than having one way of parsing / generating and then special error code checks for checkking that the useless values sent by the other end are correct. But what is more complex and what is required by this specification is that the initiator MUST then be able to initiate completely new informational exchange and send INVALID=5FSYNTAX notification which will cause the both ends to delete the IKE SA. Currently we have avoided the cases where there is errors happening in the initiator when he is processing the responders reply, and where he would need to send separate informational exchange to indicate that. Note, that there is no way for example the responder to know why the initiator is sending him that INVALID=5FSYNTAX message. Eliminating the data from the reply will also eliminate the useless checks, and will also eliminate the need to generate new informational exchanges to send fatal error messages.=20 >=20 > > In section 7 Security Considerations I can see the attack that can > > happen if the authenticated identities are not same. I.e. if host u= ses > > authenticated identities also outside the IPsec. For example the ho= st > > might export the authenticated identities to the nfs-server, and > > nfs-server could use that to verify what kind of operations the use= r > > can do. In that case attacker might create IKE SA and Child SA to > > nfs-server of the server, and then move the Child SA to another use= rs > > IKE SA, and then start doing nfs-requests. Now when nfs-server asks= > > from the IPsec engine who is on the other end of the protected IPse= c > > tunnel the IPsec engine would respond wrong users... > >=20 > > As long as the IPsec is mostly used for VPNs this kind of setups ar= e > > not used, but if host to host IPsec ever comes reality this kind of= > > setups might happen, so I think that check is very important=E2=80=A6= >=20 > There are some VPN products that export the IP<-->User identity > mapping to other network devices such as firewalls, servers and > routers. Even without this, if one peer can "transfer" the SA to the > IKE SA of another peer, the original owner still has the keys (so > old peer can use the SA, while new peer cannot, despite the > "transfer"). All actions done by the old peer now, will be logged as > if they had been done by the new peer.=20 Yep, and because of this I think this check is very important, and should be explained bit more in the draft, i.e. not just say that "we cannot think of any attack that would exploit this." --=20 kivinen@iki.fi From paul.hoffman@vpnc.org Mon Oct 14 14:23:40 2013 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 8640221F9C42 for ; Mon, 14 Oct 2013 14:23:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFAAH6jz7-IT for ; Mon, 14 Oct 2013 14:23:40 -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 AC73F21E8138 for ; Mon, 14 Oct 2013 14:23:39 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r9ELNa3m059755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 14 Oct 2013 14:23:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: <224E3077-9CF2-4517-BD0F-F73811436CE4@checkpoint.com> Date: Mon, 14 Oct 2013 14:23:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <525BAA3F.4070204@secunet.com> <224E3077-9CF2-4517-BD0F-F73811436CE4@checkpoint.com> To: "ipsec@ietf.org WG" X-Mailer: Apple Mail (2.1510) Subject: Re: [IPsec] Moving forward with draft-kivinen-ipsecme-signature-auth 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, 14 Oct 2013 21:23:40 -0000 On Oct 14, 2013, at 2:05 AM, Yoav Nir wrote: > I agree. We should either adopt it in the WG or ask Sean to publish = this as an individual submission. The latter. We have spoken of this a number of times. --Paul Hoffman= From ynir@checkpoint.com Mon Oct 14 23:51:31 2013 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 EF49721F8BE6 for ; Mon, 14 Oct 2013 23:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.393 X-Spam-Level: X-Spam-Status: No, score=-10.393 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6+QNX0IA32e for ; Mon, 14 Oct 2013 23:51:26 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D3C9511E810A for ; Mon, 14 Oct 2013 23:51:16 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9F6pBVw032520 for ; Tue, 15 Oct 2013 09:51:11 +0300 X-CheckPoint: {525CE5C4-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Tue, 15 Oct 2013 09:51:02 +0300 From: Yoav Nir To: " WG" Thread-Topic: New Version Notification for draft-nir-ipsecme-cafr-03.txt Thread-Index: AQHOyXKnpQJyNVbGpUOUx3xB3645Yg== Date: Tue, 15 Oct 2013 06:51:02 +0000 Message-ID: References: <20131015064906.2100.68545.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.205] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_ADD1110F6F9B4AC487A8AECE7B2863ADcheckpointcom_" MIME-Version: 1.0 Subject: [IPsec] Fwd: New Version Notification for draft-nir-ipsecme-cafr-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: Tue, 15 Oct 2013 06:51:31 -0000 --_000_ADD1110F6F9B4AC487A8AECE7B2863ADcheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Third version of this draft, now including Tero's comments. Begin forwarded message: From: > Subject: New Version Notification for draft-nir-ipsecme-cafr-03.txt Date: October 15, 2013 9:49:06 AM GMT+03:00 To: Yoav Nir > A new version of I-D, draft-nir-ipsecme-cafr-03.txt has been successfully submitted by Yoav Nir and posted to the IETF repository. Filename: draft-nir-ipsecme-cafr Revision: 03 Title: Handing Over Child SAs Following Re-Authentication in IKEv2 Creation date: 2013-10-15 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-cafr= -03.txt Status: http://datatracker.ietf.org/doc/draft-nir-ipsecme-cafr Htmlized: http://tools.ietf.org/html/draft-nir-ipsecme-cafr-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-nir-ipsecme-cafr-= 03 Abstract: This document describes an extension to the IKEv2 protocol whereby Child SAs are moved to the new IKE SA following re-authentication. This allows for a smoother transition with no loss of connectivity. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_ADD1110F6F9B4AC487A8AECE7B2863ADcheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <736EB990B416B5409E0A13CECA1D279F@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Third version of this draft, now including Tero's comments.

Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Subject: Ne= w Version Notification for draft-nir-ipsecme-cafr-03.txt
Date: Octob= er 15, 2013 9:49:06 AM GMT+03:00
To: Yoav = Nir <ynir@checkpoint.com><= br>


A new version of I-D, draft-nir-ipsecme-cafr-03.txt
has been successfully submitted by Yoav Nir and posted to the
IETF repository.

Filename: d= raft-nir-ipsecme-cafr
Revision: 0= 3
Title: Handing Over Ch= ild SAs Following Re-Authentication in IKEv2
Creation date: 2013-10-15
Group: Individual Subm= ission
Number of pages: 7
URL:            &nbs= p;http://www.ietf.org/internet-drafts/draft-nir-ipsecme-cafr-03.txt<= br> Status:          http://datatracker.ie= tf.org/doc/draft-nir-ipsecme-cafr
Htmlized:        http://tools.ietf.org/html/draft-= nir-ipsecme-cafr-03
Diff:            http:= //www.ietf.org/rfcdiff?url2=3Ddraft-nir-ipsecme-cafr-03

Abstract:
  This document describes an extension to the IKEv2 protocol wher= eby
  Child SAs are moved to the new IKE SA following re-authenticati= on.
  This allows for a smoother transition with no loss of connectiv= ity.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--_000_ADD1110F6F9B4AC487A8AECE7B2863ADcheckpointcom_-- From praveenys@juniper.net Tue Oct 15 09:06:14 2013 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 ADF4221E80C9 for ; Tue, 15 Oct 2013 09:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yR5wXLDqXGF for ; Tue, 15 Oct 2013 09:06:09 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id BA21521F9D65 for ; Tue, 15 Oct 2013 09:06:08 -0700 (PDT) Received: from mail159-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.22; Tue, 15 Oct 2013 16:06:07 +0000 Received: from mail159-tx2 (localhost [127.0.0.1]) by mail159-tx2-R.bigfish.com (Postfix) with ESMTP id ED55410008A; Tue, 15 Oct 2013 16:06:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail159-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=praveenys@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(24454002)(479174003)(377454003)(164054003)(189002)(199002)(76176001)(15975445006)(36756003)(77096001)(56816003)(54316002)(81542001)(56776001)(47736001)(81816001)(47976001)(49866001)(50986001)(4396001)(76786001)(76796001)(83506001)(59766001)(77982001)(63696002)(83072001)(53806001)(54356001)(51856001)(81686001)(46102001)(79102001)(85306002)(81342001)(69226001)(74706001)(80022001)(31966008)(74876001)(80976001)(76482001)(19580395003)(65816001)(74366001)(74662001)(74502001)(47446002)(19580405001)(83322001)(66066001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB153; H:BN1PR05MB153.namprd05.prod.outlook.com; CLIP:66.129.224.51; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail159-tx2 (localhost.localdomain [127.0.0.1]) by mail159-tx2 (MessageSwitch) id 1381853166475008_27798; Tue, 15 Oct 2013 16:06:06 +0000 (UTC) Received: from TX2EHSMHS011.bigfish.com (unknown [10.9.14.238]) by mail159-tx2.bigfish.com (Postfix) with ESMTP id 6BEF82004E; Tue, 15 Oct 2013 16:06:06 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS011.bigfish.com (10.9.99.111) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 15 Oct 2013 16:06:06 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 15 Oct 2013 16:06:04 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) by BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 15 Oct 2013 16:06:03 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com ([169.254.12.178]) by BN1PR05MB153.namprd05.prod.outlook.com ([169.254.12.186]) with mapi id 15.00.0785.001; Tue, 15 Oct 2013 16:06:03 +0000 From: Praveen Sathyanarayan To: "Frederic Detienne (fdetienn)" , "Manish Kumar (manishkr)" , Yoav Nir Thread-Topic: [IPsec] NUDGE: Reviewing the AD VPN drafts Thread-Index: AQHOv4rKfHQt0E+F/ku7uiacucYlkJnhv72AgAfLtwCAAvxgAIAJBJ4A Date: Tue, 15 Oct 2013 16:06:03 +0000 Message-ID: In-Reply-To: <1A87A395651F8F439A0C9D8FE20EB0F529F030B3@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [66.129.224.51] x-forefront-prvs: 00003DBFE7 Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "ipsec@ietf.org WG" , Paul Hoffman Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 15 Oct 2013 16:06:14 -0000 Are there any other detail that are not part of this draft, that is required for interoperating with existing DMVPN solution? And, is there any other feature that DMVPN supports today (and not required for interoperability) that is not part of this draft? Thanks, Praveen On 10/9/13 8:23 AM, "Frederic Detienne (fdetienn)" wrote: Hi Yoav, Thanks indeed for your comments! Please find additional [Fred] comments inline. On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) wrote: > Hi Yoav, >=20 > Thanks for your comments. I would try adding clarity to some of these > inline [Manish] to supplement what Mike said. >=20 > Manish >=20 >=20 > On 03/10/13 12:14 AM, "Yoav Nir" wrote: >=20 >> Hi >>=20 >> I have read the DM-VPN draft. I would not call my reading a review, as >>it >> was quite superficial, but here's some thoughts: >>=20 >> - I have to admit that I'm still having trouble wrapping my head around >> some of the concepts. I understand domain-based and route-pased VPNs, as >> well as IPsec and GRE tunnels. But I haven't thought of all the VPN >> endpoints as actually being on the same network. In fact I always >>thought >> of VPN as an abstract concept or as a bunch of tunnels, not as a real >> network. Having said that, I'm still trying to get used to the idea of >> NHRP being used for discovery (and to the idea of NHRP itself). To my >> mind a VPN is not an NBMA, but that does not mean an NBMA cannot serve >>as >> a good model for a VPN. >=20 > [Manish]: What the applications running over the VPN see a VPN as (NBMA >or > otherwise), depends a lot on the services provided on the VPN and the > draft doesn't preclude any possibilities that way. > RFC 4301 already prescribes the arms and ammunitions needed to protect IP > packets (when used in connection with GRE can be used to protect IP > multicast as well as non-IP packets) over untrusted networks. Also, as > appropriately noted in the requirements document, 4301 is silent on the > way the IPSec databases are populated. So the problem is essentially of > discovery and resolution. The discovery can be left to the routing > protocol but the resolution would still be needed unless IGPs are > multi-protocol, which they typically aren't. Even if they were, this >would > need a next-hop preservation which won't scale. So, essentially DMVPN > picks up an appropriate address resolution protocol in NHRP which is > enhanced to support both discovery and resolution. This is combined with > GRE to make sure IP multicast and non-IP packets can be >seamlessly(without > changing any other layer/protocol) carried across the same tunnel and >also > to simplify the SPDs. [Fred] I would add that any forwarding database is good as long as it meets the security requirements of the administrator. Routing tables are used for the description but policy routing can be used too=8A VRF's or routing context are frequently used in practice as well. There are not "pure" routing tables anymore. When it comes to L2 forwarding, the SPD today does not even fit anymore and a total revamp would be necessary. By decoupling the output tunnel selection (or next-hop selection) from the IPsec policy, we can take advantage of various forwarding policy engines. >> - I like how the process described in section 4.3 to 4.6 quickly >> converges. If host a behind gateway A sends packets to host e behind >> gateway E, and the packets travel though the tunnels AB, BC, CD, and DE, >> then the discovery process might go through several hops, but the next >> tunnel to be set up is AE. There is no case of setting up AC or AD. >> - Reading section 4.8, I see that within a single DM-VPN, there is a >> natural progression from hub&spoke to mesh. There doesn't seem to be a >> place for policy on whether a shortcut should or should not be >> established. The resolution request is forwarded until the egress node. >> So if, for example, you have two government agencies, each with its own >> set of gateways, and two gateways (one belonging to each agency) have a >> tunnel between them, there are two possible configurations: a single >> DM-VPN, in which case they become a mesh, or two DM-VPNs, so that the >> interdomain tunnel endpoints are egress nodes on their respective >> DM-VPNs. Is there a way to implement a policy so that some shortcuts are >> created between those other gateways? >> - Section 4.10 seems to be missing something. Suppose gateway A is >> forwarding traffic to gateway B, and receives an Indirection >> notification. So A sends a Resolution request. After a while, it >>receives >> a Resolution reply with TunS2 and PubS2 addresses. So now A should open >>a >> tunnel with TunS2 (right? I'm not clear about the fields). So section >> 4.10 says that authentication between these two nodes will be done using >> certificates. Considering that A has only just heard of TunS2's >> existence, what fields are there going to be in the certificate that >>will >> let A know that this is indeed TunS2? While a single domain might have >> some convention for this, AD-VPN is supposed to be good for multiple >> administrative domains, so there should be some rule about this. [Fred] We link the tunnel to an IKE profile. This IKE profile turns contains the identity, identity filter, certificate and certificate filter to send to and to accept from the remote peer. So we can create IKE profiles for each DMVPN and send or accept specific certs. Typically, O or OU fields are used. regards, fred >> - The same section hints at using certificate fields for filtering. This >> sounds weird. Suppose two gateways learn of each other through the >> resolution process. Now they try to connect, only to find out that the >> certificate fields do not allow them to connect. So we've gone through >>an >> entire IKE handshake just to discover that policy prohibits forming this >> tunnel? And because caches expire, the gateways will try again and again >> to form this tunnel, all the time failing on authorization. >=20 > [Manish]: Iff routing and NHRP policies(in general, all upper layer > policies) allow the shortcut, IKE proceeds till Auth the first time and > fails; this can be conveyed back to the upper layer (NHRP) with an > appropriate error code, which sends a NACK resolution reply. The NACK > serves to stop further resolutions either permanently or for an interval > either configured or communicated by the peer. >=20 >>=20 >>=20 >> Yoav >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > 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 fdetienn@cisco.com Tue Oct 15 09:57:27 2013 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 0836B21E80C4 for ; Tue, 15 Oct 2013 09:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9Y0X013a5Eb for ; Tue, 15 Oct 2013 09:57:22 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 05ACC21E8064 for ; Tue, 15 Oct 2013 09:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7610; q=dns/txt; s=iport; t=1381856220; x=1383065820; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZhpZlWpMdlt2COx3Lgonn6s3LXiEwKDDamW7uf/Zlf0=; b=efBvPrcN3H6okYjCn02olE0Po6iSEKMqiv8qlwPdW54MyS4sNGccMB2D Vv/fCxGIBANBD5QiTMwrmQvaO4JB5Oe8wsK+yFmacMrkIi0tHj679Dw3s Ij6vQeFjEeYGLfY02YTvfIIiUoQJbDGUw6d3dpefABfc+fczxURYYLUls I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAHZzXVKtJXG+/2dsb2JhbABRCYMHOFLCKYEjFnSCJQEBAQMBAQEBZAcLBQsCAQgYCiQnCyUCBA4FCBOHZQYMvVgEjgiBDwIxB4MfgQYDqgaDJIIp X-IronPort-AV: E=Sophos;i="4.93,500,1378857600"; d="scan'208";a="272409583" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 15 Oct 2013 16:56:59 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9FGuxGr028301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 16:56:59 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.176]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 11:56:58 -0500 From: "Frederic Detienne (fdetienn)" To: Praveen Sathyanarayan Thread-Topic: [IPsec] NUDGE: Reviewing the AD VPN drafts Thread-Index: AQHOv4q3wJGMGhH1F0e56liwS8HiOZniE4+AgAfLtwCAAvxdAIAJef2AgAAOOgA= Date: Tue, 15 Oct 2013 16:56:58 +0000 Message-ID: <1A87A395651F8F439A0C9D8FE20EB0F529F201A0@xmb-aln-x06.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.25.58] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5BAA7C1103E74F4AA617EF3034630728@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" , Yoav Nir , "Manish Kumar \(manishkr\)" , Paul Hoffman Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 15 Oct 2013 16:57:27 -0000 On 15 Oct 2013, at 18:06, Praveen Sathyanarayan wro= te: >=20 > Are there any other detail that are not part of this draft, that is > required for interoperating with existing DMVPN solution? I think the draft is exhaustive. > And, is there > any other feature that DMVPN supports today (and not required for > interoperability) that is not part of this draft? yes. Not sure how much more you want to know... regards, fred > Thanks, > Praveen >=20 >=20 > On 10/9/13 8:23 AM, "Frederic Detienne (fdetienn)" > wrote: >=20 > Hi Yoav, >=20 > Thanks indeed for your comments! Please find additional [Fred] comments > inline. >=20 > On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) > wrote: >=20 >> Hi Yoav, >>=20 >> Thanks for your comments. I would try adding clarity to some of these >> inline [Manish] to supplement what Mike said. >>=20 >> Manish >>=20 >>=20 >> On 03/10/13 12:14 AM, "Yoav Nir" wrote: >>=20 >>> Hi >>>=20 >>> I have read the DM-VPN draft. I would not call my reading a review, as >>> it >>> was quite superficial, but here's some thoughts: >>>=20 >>> - I have to admit that I'm still having trouble wrapping my head around >>> some of the concepts. I understand domain-based and route-pased VPNs, a= s >>> well as IPsec and GRE tunnels. But I haven't thought of all the VPN >>> endpoints as actually being on the same network. In fact I always >>> thought >>> of VPN as an abstract concept or as a bunch of tunnels, not as a real >>> network. Having said that, I'm still trying to get used to the idea of >>> NHRP being used for discovery (and to the idea of NHRP itself). To my >>> mind a VPN is not an NBMA, but that does not mean an NBMA cannot serve >>> as >>> a good model for a VPN. >>=20 >> [Manish]: What the applications running over the VPN see a VPN as (NBMA >> or >> otherwise), depends a lot on the services provided on the VPN and the >> draft doesn't preclude any possibilities that way. >> RFC 4301 already prescribes the arms and ammunitions needed to protect I= P >> packets (when used in connection with GRE can be used to protect IP >> multicast as well as non-IP packets) over untrusted networks. Also, as >> appropriately noted in the requirements document, 4301 is silent on the >> way the IPSec databases are populated. So the problem is essentially of >> discovery and resolution. The discovery can be left to the routing >> protocol but the resolution would still be needed unless IGPs are >> multi-protocol, which they typically aren't. Even if they were, this >> would >> need a next-hop preservation which won't scale. So, essentially DMVPN >> picks up an appropriate address resolution protocol in NHRP which is >> enhanced to support both discovery and resolution. This is combined with >> GRE to make sure IP multicast and non-IP packets can be >> seamlessly(without >> changing any other layer/protocol) carried across the same tunnel and >> also >> to simplify the SPDs. >=20 > [Fred] I would add that any forwarding database is good as long as it > meets the security requirements of the administrator. Routing tables are > used for the description but policy routing can be used too=8A VRF's or > routing context are frequently used in practice as well. There are not > "pure" routing tables anymore. >=20 > When it comes to L2 forwarding, the SPD today does not even fit anymore > and a total revamp would be necessary. >=20 > By decoupling the output tunnel selection (or next-hop selection) from > the IPsec policy, we can take advantage of various forwarding policy > engines. >=20 >=20 >>> - I like how the process described in section 4.3 to 4.6 quickly >>> converges. If host a behind gateway A sends packets to host e behind >>> gateway E, and the packets travel though the tunnels AB, BC, CD, and DE= , >>> then the discovery process might go through several hops, but the next >>> tunnel to be set up is AE. There is no case of setting up AC or AD. >=20 >>> - Reading section 4.8, I see that within a single DM-VPN, there is a >>> natural progression from hub&spoke to mesh. There doesn't seem to be a >>> place for policy on whether a shortcut should or should not be >>> established. The resolution request is forwarded until the egress node. >>> So if, for example, you have two government agencies, each with its own >>> set of gateways, and two gateways (one belonging to each agency) have a >>> tunnel between them, there are two possible configurations: a single >>> DM-VPN, in which case they become a mesh, or two DM-VPNs, so that the >>> interdomain tunnel endpoints are egress nodes on their respective >>> DM-VPNs. Is there a way to implement a policy so that some shortcuts ar= e >>> created between those other gateways? >=20 >>> - Section 4.10 seems to be missing something. Suppose gateway A is >>> forwarding traffic to gateway B, and receives an Indirection >>> notification. So A sends a Resolution request. After a while, it >>> receives >>> a Resolution reply with TunS2 and PubS2 addresses. So now A should open >>> a >>> tunnel with TunS2 (right? I'm not clear about the fields). So section >>> 4.10 says that authentication between these two nodes will be done usin= g >>> certificates. Considering that A has only just heard of TunS2's >>> existence, what fields are there going to be in the certificate that >>> will >>> let A know that this is indeed TunS2? While a single domain might have >>> some convention for this, AD-VPN is supposed to be good for multiple >>> administrative domains, so there should be some rule about this. >=20 >=20 > [Fred] We link the tunnel to an IKE profile. This IKE profile turns > contains the identity, identity filter, certificate and certificate filte= r > to send to and to accept from the remote peer. So we can create IKE > profiles for each DMVPN and send or accept specific certs. Typically, O o= r > OU fields are used. >=20 > regards, >=20 > fred >=20 >>> - The same section hints at using certificate fields for filtering. Thi= s >>> sounds weird. Suppose two gateways learn of each other through the >>> resolution process. Now they try to connect, only to find out that the >>> certificate fields do not allow them to connect. So we've gone through >>> an >>> entire IKE handshake just to discover that policy prohibits forming thi= s >>> tunnel? And because caches expire, the gateways will try again and agai= n >>> to form this tunnel, all the time failing on authorization. >>=20 >> [Manish]: Iff routing and NHRP policies(in general, all upper layer >> policies) allow the shortcut, IKE proceeds till Auth the first time and >> fails; this can be conveyed back to the upper layer (NHRP) with an >> appropriate error code, which sends a NACK resolution reply. The NACK >> serves to stop further resolutions either permanently or for an interval >> either configured or communicated by the peer. >>=20 >>>=20 >>>=20 >>> Yoav >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 >=20 >=20 From praveenys@juniper.net Tue Oct 15 11:06:01 2013 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 BF2D711E81E0 for ; Tue, 15 Oct 2013 11:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvYP84CNLnhJ for ; Tue, 15 Oct 2013 11:05:55 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6DF21F9D87 for ; Tue, 15 Oct 2013 11:05:46 -0700 (PDT) Received: from mail51-co1-R.bigfish.com (10.243.78.253) by CO1EHSOBE023.bigfish.com (10.243.66.86) with Microsoft SMTP Server id 14.1.225.22; Tue, 15 Oct 2013 18:05:44 +0000 Received: from mail51-co1 (localhost [127.0.0.1]) by mail51-co1-R.bigfish.com (Postfix) with ESMTP id B99801C00AF; Tue, 15 Oct 2013 18:05:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h186068h8275bh8275dhz2fh2a8h839he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail51-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=praveenys@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(51704005)(164054003)(24454002)(377454003)(479174003)(63696002)(76796001)(76786001)(81816001)(19580395003)(83072001)(79102001)(56816003)(46102001)(81686001)(15975445006)(77096001)(74366001)(66066001)(4396001)(80976001)(65816001)(80022001)(74706001)(74876001)(47736001)(49866001)(50986001)(47976001)(36756003)(54356001)(53806001)(77982001)(59766001)(85306002)(76176001)(51856001)(83506001)(69226001)(74502001)(47446002)(31966008)(74662001)(83322001)(81542001)(19580405001)(81342001)(56776001)(54316002)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB155; H:BN1PR05MB153.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail51-co1 (localhost.localdomain [127.0.0.1]) by mail51-co1 (MessageSwitch) id 1381860342939813_4958; Tue, 15 Oct 2013 18:05:42 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.241]) by mail51-co1.bigfish.com (Postfix) with ESMTP id D7125C004B; Tue, 15 Oct 2013 18:05:42 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 15 Oct 2013 18:05:42 +0000 Received: from BN1PR05MB155.namprd05.prod.outlook.com (10.255.205.17) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 15 Oct 2013 18:05:41 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) by BN1PR05MB155.namprd05.prod.outlook.com (10.255.205.17) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 15 Oct 2013 18:05:40 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com ([169.254.12.178]) by BN1PR05MB153.namprd05.prod.outlook.com ([169.254.12.186]) with mapi id 15.00.0785.001; Tue, 15 Oct 2013 18:05:39 +0000 From: Praveen Sathyanarayan To: "Frederic Detienne (fdetienn)" Thread-Topic: [IPsec] NUDGE: Reviewing the AD VPN drafts Thread-Index: AQHOv4rKfHQt0E+F/ku7uiacucYlkJnhv72AgAfLtwCAAvxgAIAJBJ4AgACDlwD//53UAA== Date: Tue, 15 Oct 2013 18:05:39 +0000 Message-ID: In-Reply-To: <1A87A395651F8F439A0C9D8FE20EB0F529F201A0@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [66.129.224.36] x-forefront-prvs: 00003DBFE7 Content-Type: text/plain; charset="iso-8859-2" Content-ID: <58EA6DD20EE4FE4F94DCEC1A678C6495@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "ipsec@ietf.org WG" , Yoav Nir , "Manish Kumar \(manishkr\)" , Paul Hoffman Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 15 Oct 2013 18:06:01 -0000 >=20 > Are there any other detail that are not part of this draft, that is > required for interoperating with existing DMVPN solution? I think the draft is exhaustive. [PRAVEEN] Thanks. Good to know. I can think of, handling of NAT in DMVPN (looks like there is some special mechanism). And are there anything specific changes to routing protocols to support on NBMA network? Description on policy based routing requirement for policing traffic. > And, is there > any other feature that DMVPN supports today (and not required for > interoperability) that is not part of this draft? yes. Not sure how much more you want to know... [PRAVEEN] Yes means there are features that are related to DMVPN, that are not described in the current draft? Thanks, Praveen > Thanks, > Praveen >=20 >=20 > On 10/9/13 8:23 AM, "Frederic Detienne (fdetienn)" > wrote: >=20 > Hi Yoav, >=20 > Thanks indeed for your comments! Please find additional [Fred] comments > inline. >=20 > On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) > wrote: >=20 >> Hi Yoav, >>=20 >> Thanks for your comments. I would try adding clarity to some of these >> inline [Manish] to supplement what Mike said. >>=20 >> Manish >>=20 >>=20 >> On 03/10/13 12:14 AM, "Yoav Nir" wrote: >>=20 >>> Hi >>>=20 >>> I have read the DM-VPN draft. I would not call my reading a review, as >>> it >>> was quite superficial, but here's some thoughts: >>>=20 >>> - I have to admit that I'm still having trouble wrapping my head around >>> some of the concepts. I understand domain-based and route-pased VPNs, >>>as >>> well as IPsec and GRE tunnels. But I haven't thought of all the VPN >>> endpoints as actually being on the same network. In fact I always >>> thought >>> of VPN as an abstract concept or as a bunch of tunnels, not as a real >>> network. Having said that, I'm still trying to get used to the idea of >>> NHRP being used for discovery (and to the idea of NHRP itself). To my >>> mind a VPN is not an NBMA, but that does not mean an NBMA cannot serve >>> as >>> a good model for a VPN. >>=20 >> [Manish]: What the applications running over the VPN see a VPN as (NBMA >> or >> otherwise), depends a lot on the services provided on the VPN and the >> draft doesn't preclude any possibilities that way. >> RFC 4301 already prescribes the arms and ammunitions needed to protect >>IP >> packets (when used in connection with GRE can be used to protect IP >> multicast as well as non-IP packets) over untrusted networks. Also, as >> appropriately noted in the requirements document, 4301 is silent on the >> way the IPSec databases are populated. So the problem is essentially of >> discovery and resolution. The discovery can be left to the routing >> protocol but the resolution would still be needed unless IGPs are >> multi-protocol, which they typically aren't. Even if they were, this >> would >> need a next-hop preservation which won't scale. So, essentially DMVPN >> picks up an appropriate address resolution protocol in NHRP which is >> enhanced to support both discovery and resolution. This is combined with >> GRE to make sure IP multicast and non-IP packets can be >> seamlessly(without >> changing any other layer/protocol) carried across the same tunnel and >> also >> to simplify the SPDs. >=20 > [Fred] I would add that any forwarding database is good as long as it > meets the security requirements of the administrator. Routing tables are > used for the description but policy routing can be used too=A9 VRF's or > routing context are frequently used in practice as well. There are not > "pure" routing tables anymore. >=20 > When it comes to L2 forwarding, the SPD today does not even fit anymore > and a total revamp would be necessary. >=20 > By decoupling the output tunnel selection (or next-hop selection) from > the IPsec policy, we can take advantage of various forwarding policy > engines. >=20 >=20 >>> - I like how the process described in section 4.3 to 4.6 quickly >>> converges. If host a behind gateway A sends packets to host e behind >>> gateway E, and the packets travel though the tunnels AB, BC, CD, and >>>DE, >>> then the discovery process might go through several hops, but the next >>> tunnel to be set up is AE. There is no case of setting up AC or AD. >=20 >>> - Reading section 4.8, I see that within a single DM-VPN, there is a >>> natural progression from hub&spoke to mesh. There doesn't seem to be a >>> place for policy on whether a shortcut should or should not be >>> established. The resolution request is forwarded until the egress node. >>> So if, for example, you have two government agencies, each with its own >>> set of gateways, and two gateways (one belonging to each agency) have a >>> tunnel between them, there are two possible configurations: a single >>> DM-VPN, in which case they become a mesh, or two DM-VPNs, so that the >>> interdomain tunnel endpoints are egress nodes on their respective >>> DM-VPNs. Is there a way to implement a policy so that some shortcuts >>>are >>> created between those other gateways? >=20 >>> - Section 4.10 seems to be missing something. Suppose gateway A is >>> forwarding traffic to gateway B, and receives an Indirection >>> notification. So A sends a Resolution request. After a while, it >>> receives >>> a Resolution reply with TunS2 and PubS2 addresses. So now A should open >>> a >>> tunnel with TunS2 (right? I'm not clear about the fields). So section >>> 4.10 says that authentication between these two nodes will be done >>>using >>> certificates. Considering that A has only just heard of TunS2's >>> existence, what fields are there going to be in the certificate that >>> will >>> let A know that this is indeed TunS2? While a single domain might have >>> some convention for this, AD-VPN is supposed to be good for multiple >>> administrative domains, so there should be some rule about this. >=20 >=20 > [Fred] We link the tunnel to an IKE profile. This IKE profile turns > contains the identity, identity filter, certificate and certificate >filter > to send to and to accept from the remote peer. So we can create IKE > profiles for each DMVPN and send or accept specific certs. Typically, O >or > OU fields are used. >=20 > regards, >=20 > fred >=20 >>> - The same section hints at using certificate fields for filtering. >>>This >>> sounds weird. Suppose two gateways learn of each other through the >>> resolution process. Now they try to connect, only to find out that the >>> certificate fields do not allow them to connect. So we've gone through >>> an >>> entire IKE handshake just to discover that policy prohibits forming >>>this >>> tunnel? And because caches expire, the gateways will try again and >>>again >>> to form this tunnel, all the time failing on authorization. >>=20 >> [Manish]: Iff routing and NHRP policies(in general, all upper layer >> policies) allow the shortcut, IKE proceeds till Auth the first time and >> fails; this can be conveyed back to the upper layer (NHRP) with an >> appropriate error code, which sends a NACK resolution reply. The NACK >> serves to stop further resolutions either permanently or for an interval >> either configured or communicated by the peer. >>=20 >>>=20 >>>=20 >>> Yoav >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 >=20 >=20 From paul.hoffman@vpnc.org Tue Oct 15 18:44:49 2013 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 A31EA21F9A97 for ; Tue, 15 Oct 2013 18:44:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpYJTGYuwUUM for ; Tue, 15 Oct 2013 18:44:49 -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 4501511E80F7 for ; Tue, 15 Oct 2013 18:44:47 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r9G1iijv027373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Oct 2013 18:44:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: <21078.42152.502994.298696@fireball.kivinen.iki.fi> Date: Tue, 15 Oct 2013 18:44:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9D44031D-5987-411E-978B-91079EA4DF4B@vpnc.org> References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <1B20E03AB216428AA7F16B898AA49FFD@buildpc> <5256426B.4030707@gmail.com> <21078.42152.502994.298696@fireball.kivinen.iki.fi> To: Valery Smyslov X-Mailer: Apple Mail (2.1510) Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Wed, 16 Oct 2013 01:44:49 -0000 Could you wrap up the last set of suggestions for more text into a -04? = That would let us do a WG LC soon. --Paul Hoffman= From svanru@gmail.com Tue Oct 15 23:39:18 2013 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 A81D811E8268 for ; Tue, 15 Oct 2013 23:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZlrMp6uRVos for ; Tue, 15 Oct 2013 23:39:18 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E438011E8244 for ; Tue, 15 Oct 2013 23:39:17 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id gx14so208252lab.37 for ; Tue, 15 Oct 2013 23:39:17 -0700 (PDT) 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; bh=pV2cBWkrOwnduchpmzbIpOePvnDb503Q796QeoCsLJc=; b=Qiu0j5abkYETIzgvTzfkAskM9ri6HZ9s6zjS+zWLvX5iaif6ixmKkkQI/hb0ves4Ym on9QJR6t3isNWF2UbQCkb0EgjayDz9hXw2oXnD+lDoACvsoLo4pwGTxjMogATnFM65lg Owjbb6en2ALWl+dDVItOFPTSlzyx7EEk9iH1XXaQG6AyJ4pVOy7hVGjPVqasPDrmdKVu uK1+b9MH7gx5AmjUkLN7hoxuuPNcbcGQJiinCxCuQr+lLYx1lpopTDObYgcen/XYdKm8 F83eb2maljJQofRkP8Sb7iZlz48wuPI1hYznTW/3P0DHzzRrpg5U5BZzp0fJs6Q5AYi4 Heig== X-Received: by 10.152.2.74 with SMTP id 10mr331351las.36.1381905556966; Tue, 15 Oct 2013 23:39:16 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id ur6sm50066580lbc.5.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 15 Oct 2013 23:39:16 -0700 (PDT) Message-ID: <113EEF94DB0A4A768FC546654B9C9BF4@buildpc> From: "Valery Smyslov" To: "Paul Hoffman" References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <1B20E03AB216428AA7F16B898AA49FFD@buildpc> <5256426B.4030707@gmail.com> <21078.42152.502994.298696@fireball.kivinen.iki.fi> <9D44031D-5987-411E-978B-91079EA4DF4B@vpnc.org> Date: Wed, 16 Oct 2013 10:39:17 +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] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Wed, 16 Oct 2013 06:39:18 -0000 Yes, sure. I'm planning to do it by Friday. > Could you wrap up the last set of suggestions for more text into a -04? > That would let us do a WG LC soon. > > --Paul Hoffman= From fdetienn@cisco.com Wed Oct 16 10:00:54 2013 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 C0B5011E8138 for ; Wed, 16 Oct 2013 10:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MaI9k-Xf-7M for ; Wed, 16 Oct 2013 10:00:49 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 61ED311E8182 for ; Wed, 16 Oct 2013 10:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9879; q=dns/txt; s=iport; t=1381942849; x=1383152449; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Leya3BDu0/wCFY+5HoEmuWrvgrO+FLXoXW6XU/VOx+c=; b=ej7ClMjkcKu8Wj3gRptxT16kggIcx3/FAj9lRrzvuvPBn5vEn2A1FNTo NEU0Bd1jeLUdKpSlCPlobmuFRHPxW01FS+w10cm/AUiwo0oFMG1gA7dpc 6k+4evEXQNTo3eAqBAnBcd3nZXvKvFLABfa59kjoqhoBbx7UJwVu2Nn5m k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAPHEXlKtJXHA/2dsb2JhbABRCYMHOFKDKb5mgR4WdIIlAQEBAwEBAQEBHARDBwsFCwIBCBgDByEDJwslAgQOAwIIE4dlBgysawySSQSBKoxdCIEPAjEHgms0gQYDlCeVX4MkQIFp X-IronPort-AV: E=Sophos;i="4.93,508,1378857600"; d="scan'208";a="272955084" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 16 Oct 2013 17:00:48 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9GH0maG021685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 17:00:48 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.176]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 12:00:48 -0500 From: "Frederic Detienne (fdetienn)" To: Praveen Sathyanarayan Thread-Topic: [IPsec] NUDGE: Reviewing the AD VPN drafts Thread-Index: AQHOv4q3wJGMGhH1F0e56liwS8HiOZniE4+AgAfLtwCAAvxdAIAJef2AgAAOOgCAABMxgIABgCgA Date: Wed, 16 Oct 2013 17:00:47 +0000 Message-ID: <1A87A395651F8F439A0C9D8FE20EB0F529F21887@xmb-aln-x06.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.25.58] Content-Type: text/plain; charset="windows-1250" Content-ID: <2059D5289D7F1849B3EB955E40BD5F0E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" , Yoav Nir , "Manish Kumar \(manishkr\)" , Paul Hoffman Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 16 Oct 2013 17:00:54 -0000 On 15 Oct 2013, at 20:05, Praveen Sathyanarayan wrote: >>=20 >> Are there any other detail that are not part of this draft, that is >> required for interoperating with existing DMVPN solution? >=20 > I think the draft is exhaustive. >=20 > [PRAVEEN] Thanks. Good to know. I can think of, handling of NAT in DMVPN > (looks like there is some special mechanism). The DMVPN product features a NAT mechanism necessary for plain GRE (no IPse= c) in order to figure the public outside address. Since we are talking about IKE/IPsec only here, that information can be dra= wn from IKE itself. > And are there anything > specific changes to routing protocols to support on NBMA network? No change is required to the routing protocols. By treating the connections= as tunnels and tunnel interfaces or tunnel endpoints, routing protocols ru= n natively over these. It really only depends on the modularity of the routing protocol implementa= tion. > Description on policy based routing requirement for policing traffic. There is no specific requirement for policy based routing. To be absolutely precise, as described in the draft, we inject NHRP entries= in the routing table by pointing to a next-hop or an output interface. I s= uppose you could call that policy routing somehow or you could call NHRP a = routing protocol... but all you need is in the document. We manipulate the routing table using all possible sources (NHRP, Routing p= rotocols, IKE,=85) but our draft does not strictly command how packets are = forwarded inside a gateway. >> And, is there >> any other feature that DMVPN supports today (and not required for >> interoperability) that is not part of this draft? >=20 > yes. Not sure how much more you want to know... >=20 > [PRAVEEN] Yes means there are features that are related to DMVPN, that ar= e > not described in the current draft? yes too but this is a different question. You asked me a precise, closed qu= estion and I answered with a precise "yes". Let me rewrite the answers to both questions in a low context form: A1) There is no other feature that DMVPN/FlexVPN (product names) supports t= oday (and not required for interoperability) that is not part of the draft.= =20 A2) There are other features related to DMVPN/FlexVPN (product names) that = are not in the draft (but they are not required for interoperability). thanks, fred > Thanks, > Praveen >=20 >=20 >> Thanks, >> Praveen >>=20 >>=20 >> On 10/9/13 8:23 AM, "Frederic Detienne (fdetienn)" >> wrote: >>=20 >> Hi Yoav, >>=20 >> Thanks indeed for your comments! Please find additional [Fred] comments >> inline. >>=20 >> On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) >> wrote: >>=20 >>> Hi Yoav, >>>=20 >>> Thanks for your comments. I would try adding clarity to some of these >>> inline [Manish] to supplement what Mike said. >>>=20 >>> Manish >>>=20 >>>=20 >>> On 03/10/13 12:14 AM, "Yoav Nir" wrote: >>>=20 >>>> Hi >>>>=20 >>>> I have read the DM-VPN draft. I would not call my reading a review, as >>>> it >>>> was quite superficial, but here's some thoughts: >>>>=20 >>>> - I have to admit that I'm still having trouble wrapping my head aroun= d >>>> some of the concepts. I understand domain-based and route-pased VPNs, >>>> as >>>> well as IPsec and GRE tunnels. But I haven't thought of all the VPN >>>> endpoints as actually being on the same network. In fact I always >>>> thought >>>> of VPN as an abstract concept or as a bunch of tunnels, not as a real >>>> network. Having said that, I'm still trying to get used to the idea of >>>> NHRP being used for discovery (and to the idea of NHRP itself). To my >>>> mind a VPN is not an NBMA, but that does not mean an NBMA cannot serve >>>> as >>>> a good model for a VPN. >>>=20 >>> [Manish]: What the applications running over the VPN see a VPN as (NBMA >>> or >>> otherwise), depends a lot on the services provided on the VPN and the >>> draft doesn't preclude any possibilities that way. >>> RFC 4301 already prescribes the arms and ammunitions needed to protect >>> IP >>> packets (when used in connection with GRE can be used to protect IP >>> multicast as well as non-IP packets) over untrusted networks. Also, as >>> appropriately noted in the requirements document, 4301 is silent on the >>> way the IPSec databases are populated. So the problem is essentially of >>> discovery and resolution. The discovery can be left to the routing >>> protocol but the resolution would still be needed unless IGPs are >>> multi-protocol, which they typically aren't. Even if they were, this >>> would >>> need a next-hop preservation which won't scale. So, essentially DMVPN >>> picks up an appropriate address resolution protocol in NHRP which is >>> enhanced to support both discovery and resolution. This is combined wit= h >>> GRE to make sure IP multicast and non-IP packets can be >>> seamlessly(without >>> changing any other layer/protocol) carried across the same tunnel and >>> also >>> to simplify the SPDs. >>=20 >> [Fred] I would add that any forwarding database is good as long as it >> meets the security requirements of the administrator. Routing tables are >> used for the description but policy routing can be used too=8A VRF's or >> routing context are frequently used in practice as well. There are not >> "pure" routing tables anymore. >>=20 >> When it comes to L2 forwarding, the SPD today does not even fit anymore >> and a total revamp would be necessary. >>=20 >> By decoupling the output tunnel selection (or next-hop selection) from >> the IPsec policy, we can take advantage of various forwarding policy >> engines. >>=20 >>=20 >>>> - I like how the process described in section 4.3 to 4.6 quickly >>>> converges. If host a behind gateway A sends packets to host e behind >>>> gateway E, and the packets travel though the tunnels AB, BC, CD, and >>>> DE, >>>> then the discovery process might go through several hops, but the next >>>> tunnel to be set up is AE. There is no case of setting up AC or AD. >>=20 >>>> - Reading section 4.8, I see that within a single DM-VPN, there is a >>>> natural progression from hub&spoke to mesh. There doesn't seem to be a >>>> place for policy on whether a shortcut should or should not be >>>> established. The resolution request is forwarded until the egress node= . >>>> So if, for example, you have two government agencies, each with its ow= n >>>> set of gateways, and two gateways (one belonging to each agency) have = a >>>> tunnel between them, there are two possible configurations: a single >>>> DM-VPN, in which case they become a mesh, or two DM-VPNs, so that the >>>> interdomain tunnel endpoints are egress nodes on their respective >>>> DM-VPNs. Is there a way to implement a policy so that some shortcuts >>>> are >>>> created between those other gateways? >>=20 >>>> - Section 4.10 seems to be missing something. Suppose gateway A is >>>> forwarding traffic to gateway B, and receives an Indirection >>>> notification. So A sends a Resolution request. After a while, it >>>> receives >>>> a Resolution reply with TunS2 and PubS2 addresses. So now A should ope= n >>>> a >>>> tunnel with TunS2 (right? I'm not clear about the fields). So section >>>> 4.10 says that authentication between these two nodes will be done >>>> using >>>> certificates. Considering that A has only just heard of TunS2's >>>> existence, what fields are there going to be in the certificate that >>>> will >>>> let A know that this is indeed TunS2? While a single domain might have >>>> some convention for this, AD-VPN is supposed to be good for multiple >>>> administrative domains, so there should be some rule about this. >>=20 >>=20 >> [Fred] We link the tunnel to an IKE profile. This IKE profile turns >> contains the identity, identity filter, certificate and certificate >> filter >> to send to and to accept from the remote peer. So we can create IKE >> profiles for each DMVPN and send or accept specific certs. Typically, O >> or >> OU fields are used. >>=20 >> regards, >>=20 >> fred >>=20 >>>> - The same section hints at using certificate fields for filtering. >>>> This >>>> sounds weird. Suppose two gateways learn of each other through the >>>> resolution process. Now they try to connect, only to find out that the >>>> certificate fields do not allow them to connect. So we've gone through >>>> an >>>> entire IKE handshake just to discover that policy prohibits forming >>>> this >>>> tunnel? And because caches expire, the gateways will try again and >>>> again >>>> to form this tunnel, all the time failing on authorization. >>>=20 >>> [Manish]: Iff routing and NHRP policies(in general, all upper layer >>> policies) allow the shortcut, IKE proceeds till Auth the first time and >>> fails; this can be conveyed back to the upper layer (NHRP) with an >>> appropriate error code, which sends a NACK resolution reply. The NACK >>> serves to stop further resolutions either permanently or for an interva= l >>> either configured or communicated by the peer. >>>=20 >>>>=20 >>>>=20 >>>> Yoav >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 >=20 From praveenys@juniper.net Wed Oct 16 17:23:05 2013 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 2AD5121F9808 for ; Wed, 16 Oct 2013 17:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+ZOPCn7KhCY for ; Wed, 16 Oct 2013 17:23:00 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id DE18021F9649 for ; Wed, 16 Oct 2013 17:22:56 -0700 (PDT) Received: from mail88-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE016.bigfish.com (10.236.130.79) with Microsoft SMTP Server id 14.1.225.22; Thu, 17 Oct 2013 00:22:56 +0000 Received: from mail88-co9 (localhost [127.0.0.1]) by mail88-co9-R.bigfish.com (Postfix) with ESMTP id 2C0611E00A0; Thu, 17 Oct 2013 00:22:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275dh1de097h186068h8275bhz2fh2a8h839he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail88-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=praveenys@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(164054003)(199002)(189002)(479174003)(24454002)(51704005)(80976001)(80022001)(74706001)(69226001)(74876001)(31966008)(47446002)(83322001)(19580405001)(74366001)(74662001)(74502001)(66066001)(65816001)(19580395003)(76482001)(4396001)(81542001)(54316002)(56776001)(83506001)(76796001)(76786001)(76176001)(56816003)(77096001)(15975445006)(36756003)(81342001)(79102001)(85306002)(49866001)(50986001)(47736001)(81816001)(47976001)(77982001)(59766001)(51856001)(81686001)(46102001)(63696002)(83072001)(53806001)(54356001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB153; H:BN1PR05MB153.namprd05.prod.outlook.com; CLIP:66.129.224.36; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail88-co9 (localhost.localdomain [127.0.0.1]) by mail88-co9 (MessageSwitch) id 1381969373378603_21191; Thu, 17 Oct 2013 00:22:53 +0000 (UTC) Received: from CO9EHSMHS018.bigfish.com (unknown [10.236.132.231]) by mail88-co9.bigfish.com (Postfix) with ESMTP id 4EB6A44008C; Thu, 17 Oct 2013 00:22:53 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS018.bigfish.com (10.236.130.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 17 Oct 2013 00:22:53 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 17 Oct 2013 00:22:52 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) by BN1PR05MB153.namprd05.prod.outlook.com (10.255.205.18) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 17 Oct 2013 00:22:49 +0000 Received: from BN1PR05MB153.namprd05.prod.outlook.com ([169.254.12.178]) by BN1PR05MB153.namprd05.prod.outlook.com ([169.254.12.186]) with mapi id 15.00.0785.001; Thu, 17 Oct 2013 00:22:49 +0000 From: Praveen Sathyanarayan To: "Frederic Detienne (fdetienn)" Thread-Topic: [IPsec] NUDGE: Reviewing the AD VPN drafts Thread-Index: AQHOv4rKfHQt0E+F/ku7uiacucYlkJnhv72AgAfLtwCAAvxgAIAJBJ4AgACDlwD//53UAIAB9ZGAgAAGI4A= Date: Thu, 17 Oct 2013 00:22:49 +0000 Message-ID: In-Reply-To: <1A87A395651F8F439A0C9D8FE20EB0F529F21887@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [66.129.224.36] x-forefront-prvs: 000227DA0C Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] NUDGE: Reviewing the AD VPN drafts 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, 17 Oct 2013 00:23:05 -0000 Thanks Fred for clarifications. -- Praveen On 10/16/13 10:00 AM, "Frederic Detienne (fdetienn)" wrote: On 15 Oct 2013, at 20:05, Praveen Sathyanarayan wrote: >>=20 >> Are there any other detail that are not part of this draft, that is >> required for interoperating with existing DMVPN solution? >=20 > I think the draft is exhaustive. >=20 > [PRAVEEN] Thanks. Good to know. I can think of, handling of NAT in DMVPN > (looks like there is some special mechanism). The DMVPN product features a NAT mechanism necessary for plain GRE (no IPsec) in order to figure the public outside address. Since we are talking about IKE/IPsec only here, that information can be drawn from IKE itself. > And are there anything > specific changes to routing protocols to support on NBMA network? No change is required to the routing protocols. By treating the connections as tunnels and tunnel interfaces or tunnel endpoints, routing protocols run natively over these. It really only depends on the modularity of the routing protocol implementation. > Description on policy based routing requirement for policing traffic. There is no specific requirement for policy based routing. To be absolutely precise, as described in the draft, we inject NHRP entries in the routing table by pointing to a next-hop or an output interface. I suppose you could call that policy routing somehow or you could call NHRP a routing protocol... but all you need is in the document. We manipulate the routing table using all possible sources (NHRP, Routing protocols, IKE,...) but our draft does not strictly command how packets are forwarded inside a gateway. >> And, is there >> any other feature that DMVPN supports today (and not required for >> interoperability) that is not part of this draft? >=20 > yes. Not sure how much more you want to know... >=20 > [PRAVEEN] Yes means there are features that are related to DMVPN, that >are > not described in the current draft? yes too but this is a different question. You asked me a precise, closed question and I answered with a precise "yes". Let me rewrite the answers to both questions in a low context form: A1) There is no other feature that DMVPN/FlexVPN (product names) supports today (and not required for interoperability) that is not part of the draft.=20 A2) There are other features related to DMVPN/FlexVPN (product names) that are not in the draft (but they are not required for interoperability). thanks, fred > Thanks, > Praveen >=20 >=20 >> Thanks, >> Praveen >>=20 >>=20 >> On 10/9/13 8:23 AM, "Frederic Detienne (fdetienn)" >> wrote: >>=20 >> Hi Yoav, >>=20 >> Thanks indeed for your comments! Please find additional [Fred] comments >> inline. >>=20 >> On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) >> wrote: >>=20 >>> Hi Yoav, >>>=20 >>> Thanks for your comments. I would try adding clarity to some of these >>> inline [Manish] to supplement what Mike said. >>>=20 >>> Manish >>>=20 >>>=20 >>> On 03/10/13 12:14 AM, "Yoav Nir" wrote: >>>=20 >>>> Hi >>>>=20 >>>> I have read the DM-VPN draft. I would not call my reading a review, as >>>> it >>>> was quite superficial, but here's some thoughts: >>>>=20 >>>> - I have to admit that I'm still having trouble wrapping my head >>>>around >>>> some of the concepts. I understand domain-based and route-pased VPNs, >>>> as >>>> well as IPsec and GRE tunnels. But I haven't thought of all the VPN >>>> endpoints as actually being on the same network. In fact I always >>>> thought >>>> of VPN as an abstract concept or as a bunch of tunnels, not as a real >>>> network. Having said that, I'm still trying to get used to the idea of >>>> NHRP being used for discovery (and to the idea of NHRP itself). To my >>>> mind a VPN is not an NBMA, but that does not mean an NBMA cannot serve >>>> as >>>> a good model for a VPN. >>>=20 >>> [Manish]: What the applications running over the VPN see a VPN as (NBMA >>> or >>> otherwise), depends a lot on the services provided on the VPN and the >>> draft doesn't preclude any possibilities that way. >>> RFC 4301 already prescribes the arms and ammunitions needed to protect >>> IP >>> packets (when used in connection with GRE can be used to protect IP >>> multicast as well as non-IP packets) over untrusted networks. Also, as >>> appropriately noted in the requirements document, 4301 is silent on the >>> way the IPSec databases are populated. So the problem is essentially of >>> discovery and resolution. The discovery can be left to the routing >>> protocol but the resolution would still be needed unless IGPs are >>> multi-protocol, which they typically aren't. Even if they were, this >>> would >>> need a next-hop preservation which won't scale. So, essentially DMVPN >>> picks up an appropriate address resolution protocol in NHRP which is >>> enhanced to support both discovery and resolution. This is combined >>>with >>> GRE to make sure IP multicast and non-IP packets can be >>> seamlessly(without >>> changing any other layer/protocol) carried across the same tunnel and >>> also >>> to simplify the SPDs. >>=20 >> [Fred] I would add that any forwarding database is good as long as it >> meets the security requirements of the administrator. Routing tables are >> used for the description but policy routing can be used too=A9 VRF's or >> routing context are frequently used in practice as well. There are not >> "pure" routing tables anymore. >>=20 >> When it comes to L2 forwarding, the SPD today does not even fit anymore >> and a total revamp would be necessary. >>=20 >> By decoupling the output tunnel selection (or next-hop selection) from >> the IPsec policy, we can take advantage of various forwarding policy >> engines. >>=20 >>=20 >>>> - I like how the process described in section 4.3 to 4.6 quickly >>>> converges. If host a behind gateway A sends packets to host e behind >>>> gateway E, and the packets travel though the tunnels AB, BC, CD, and >>>> DE, >>>> then the discovery process might go through several hops, but the next >>>> tunnel to be set up is AE. There is no case of setting up AC or AD. >>=20 >>>> - Reading section 4.8, I see that within a single DM-VPN, there is a >>>> natural progression from hub&spoke to mesh. There doesn't seem to be a >>>> place for policy on whether a shortcut should or should not be >>>> established. The resolution request is forwarded until the egress >>>>node. >>>> So if, for example, you have two government agencies, each with its >>>>own >>>> set of gateways, and two gateways (one belonging to each agency) have >>>>a >>>> tunnel between them, there are two possible configurations: a single >>>> DM-VPN, in which case they become a mesh, or two DM-VPNs, so that the >>>> interdomain tunnel endpoints are egress nodes on their respective >>>> DM-VPNs. Is there a way to implement a policy so that some shortcuts >>>> are >>>> created between those other gateways? >>=20 >>>> - Section 4.10 seems to be missing something. Suppose gateway A is >>>> forwarding traffic to gateway B, and receives an Indirection >>>> notification. So A sends a Resolution request. After a while, it >>>> receives >>>> a Resolution reply with TunS2 and PubS2 addresses. So now A should >>>>open >>>> a >>>> tunnel with TunS2 (right? I'm not clear about the fields). So section >>>> 4.10 says that authentication between these two nodes will be done >>>> using >>>> certificates. Considering that A has only just heard of TunS2's >>>> existence, what fields are there going to be in the certificate that >>>> will >>>> let A know that this is indeed TunS2? While a single domain might have >>>> some convention for this, AD-VPN is supposed to be good for multiple >>>> administrative domains, so there should be some rule about this. >>=20 >>=20 >> [Fred] We link the tunnel to an IKE profile. This IKE profile turns >> contains the identity, identity filter, certificate and certificate >> filter >> to send to and to accept from the remote peer. So we can create IKE >> profiles for each DMVPN and send or accept specific certs. Typically, O >> or >> OU fields are used. >>=20 >> regards, >>=20 >> fred >>=20 >>>> - The same section hints at using certificate fields for filtering. >>>> This >>>> sounds weird. Suppose two gateways learn of each other through the >>>> resolution process. Now they try to connect, only to find out that the >>>> certificate fields do not allow them to connect. So we've gone through >>>> an >>>> entire IKE handshake just to discover that policy prohibits forming >>>> this >>>> tunnel? And because caches expire, the gateways will try again and >>>> again >>>> to form this tunnel, all the time failing on authorization. >>>=20 >>> [Manish]: Iff routing and NHRP policies(in general, all upper layer >>> policies) allow the shortcut, IKE proceeds till Auth the first time and >>> fails; this can be conveyed back to the upper layer (NHRP) with an >>> appropriate error code, which sends a NACK resolution reply. The NACK >>> serves to stop further resolutions either permanently or for an >>>interval >>> either configured or communicated by the peer. >>>=20 >>>>=20 >>>>=20 >>>> Yoav >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 >=20 From kivinen@iki.fi Thu Oct 17 06:54:55 2013 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 11D5911E8257 for ; Thu, 17 Oct 2013 06:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcV-amp1iWMn for ; Thu, 17 Oct 2013 06:54:54 -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 2B66611E8263 for ; Thu, 17 Oct 2013 06:54:53 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9HDsdp7027477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 17 Oct 2013 16:54:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9HDsdb0022096; Thu, 17 Oct 2013 16:54:39 +0300 (EEST) 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: <21087.60447.758422.672867@fireball.kivinen.iki.fi> Date: Thu, 17 Oct 2013 16:54:39 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Subject: [IPsec] Updated version of RFC5996bis 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, 17 Oct 2013 13:54:55 -0000 I made new version of the RFC5996bis (yes, I am more than month too late from my original time-estimate). This version removes the Raw RSA public keys, adds reference to the 5996, 6989 and 4945. Cleans up IANA Considerations section, and adds note to both to the abstract and Introduction that this document intended for Internet Standard status. For the RFC6989 I made Informative reference to it, as all the Diffie-Hellman groups described IN THIS document are those groups which do not need any special checks. I added reference to that RFC in two places, firstly in the section "2.12 Reuse of Diffie-Hellman Exponentials", and secondly after the "Transform Type 4 (Diffie-Hellman group)" table. For the 4945 I made Informative reference at the end of section "3.5 Identification Payloads". -- kivinen@iki.fi From paul@cypherpunks.ca Thu Oct 17 07:14:08 2013 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 1DF8411E8273 for ; Thu, 17 Oct 2013 07:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzamGdB5GyDg for ; Thu, 17 Oct 2013 07:14:02 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4D08511E8205 for ; Thu, 17 Oct 2013 07:14:00 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d0sn00wz4zCCk; Thu, 17 Oct 2013 10:13:56 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LIASqWY74zYp; Thu, 17 Oct 2013 10:13:55 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 17 Oct 2013 10:13:55 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 15868800C4; Thu, 17 Oct 2013 10:13:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0E58A80097; Thu, 17 Oct 2013 10:13:56 -0400 (EDT) Date: Thu, 17 Oct 2013 10:13:56 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: <21087.60447.758422.672867@fireball.kivinen.iki.fi> Message-ID: References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Updated version of RFC5996bis 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, 17 Oct 2013 14:14:08 -0000 On Thu, 17 Oct 2013, Tero Kivinen wrote: > I made new version of the RFC5996bis (yes, I am more than month too > late from my original time-estimate). > > This version removes the Raw RSA public keys Is that the old version that would be obsoleted by draft-kivinen-ipsecme-oob-pubkey that no one implemented? While updating the retransmit timers in libreswan, I found no useful information in 5996. Is that something we could add? I know it is local policy but perhaps it would be good to add some guidance for implementors. Do people use sub-second retries? exponential backoff? How do people deal with slow wakeup stacks (eg 3G) and preventing of firsts of duplicate first packets? Paul From yaronf.ietf@gmail.com Thu Oct 17 07:24:08 2013 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 8C8F611E80F9 for ; Thu, 17 Oct 2013 07:24:08 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsM2elA5Hay4 for ; Thu, 17 Oct 2013 07:24:07 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6765811E8205 for ; Thu, 17 Oct 2013 07:24:04 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id b45so1113356eek.15 for ; Thu, 17 Oct 2013 07:24:03 -0700 (PDT) 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=SJ0oJQTEcgkNRlIEfBQtZAMsJQWCrSL5Ph+HOgNnU1Y=; b=z4YAqm1io7SyiCVypBFVrjSzWuJaSiqPqXaMtzC22IUa1xoZpl1qNhpmYv/NbaJlP+ 051YngSXgTA2DEurfz14AfTq8sneDDJYag49+1kvHMyP8jESLu5Mn4jh+uXqCvEBjOrT rcOWShLOSEQ84tGmLUY9rvr92U1ypQrbyAUWk6N1wnBKZdFv3N+Fiado5NXA5fRx7jOd u4WEj5BC363zzh68RXzSF8Os5hXcIflnRGYnJwJyFcMVQM1u3hqUija2DVpi5vHEg0vP ZrZffimYgajD9lGGF++2Ti5cuE5lWNXDVP8qvCGAM6l45n7VMHIv9v9T8dotTlAm8H79 8oOA== X-Received: by 10.14.218.197 with SMTP id k45mr13104926eep.32.1382019843272; Thu, 17 Oct 2013 07:24:03 -0700 (PDT) Received: from [10.0.0.8] (46-116-149-62.bb.netvision.net.il. [46.116.149.62]) by mx.google.com with ESMTPSA id r48sm193599180eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 07:24:02 -0700 (PDT) Message-ID: <525FF300.8010207@gmail.com> Date: Thu, 17 Oct 2013 17:24:00 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Paul Wouters , Tero Kivinen References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> In-Reply-To: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Updated version of RFC5996bis 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, 17 Oct 2013 14:24:08 -0000 Hi Paul, Regarding your second point, I would like to avoid feature creep in this document. So unless there's a real good reason to add text (e.g. a new security requirement) I would suggest not to do it. More specifically, since this is a matter of local policy and implementations differ, we could debate it forever and for little gain. Thanks, Yaron On 2013-10-17 17:13, Paul Wouters wrote: > On Thu, 17 Oct 2013, Tero Kivinen wrote: > >> I made new version of the RFC5996bis (yes, I am more than month too >> late from my original time-estimate). >> >> This version removes the Raw RSA public keys > > Is that the old version that would be obsoleted by > draft-kivinen-ipsecme-oob-pubkey that no one implemented? > > While updating the retransmit timers in libreswan, I found no useful > information in 5996. Is that something we could add? I know it is > local policy but perhaps it would be good to add some guidance for > implementors. Do people use sub-second retries? exponential backoff? > How do people deal with slow wakeup stacks (eg 3G) and preventing of > firsts of duplicate first packets? > > Paul > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Thu Oct 17 08:04:59 2013 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 A734211E820C for ; Thu, 17 Oct 2013 08:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.414 X-Spam-Level: X-Spam-Status: No, score=-10.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9UeDaqDmhEU for ; Thu, 17 Oct 2013 08:04:54 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D6AD021F923D for ; Thu, 17 Oct 2013 08:04:42 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9HF3xUW028049; Thu, 17 Oct 2013 18:04:00 +0300 X-CheckPoint: {525FFC20-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Thu, 17 Oct 2013 18:03:49 +0300 From: Yoav Nir To: Paul Wouters Thread-Topic: [IPsec] Updated version of RFC5996bis Thread-Index: AQHOy0B6EYWWbwbZc0K/EwR9Ix0YZJn4vW8AgAAN+wA= Date: Thu, 17 Oct 2013 15:03:49 +0000 Message-ID: References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.76] 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: "ipsec@ietf.org WG" , Tero Kivinen Subject: Re: [IPsec] Updated version of RFC5996bis 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, 17 Oct 2013 15:04:59 -0000 On Oct 17, 2013, at 5:13 PM, Paul Wouters wrote: > While updating the retransmit timers in libreswan, I found no useful > information in 5996. Is that something we could add? I know it is > local policy but perhaps it would be good to add some guidance for > implementors. Do people use sub-second retries? exponential backoff? > How do people deal with slow wakeup stacks (eg 3G) and preventing of > firsts of duplicate first packets? I agree with Yaron. The only guidance is "at least 12 retransmission over a= t least two minutes" RTT varies wildly on the Internet. I've just tried pinging www.ietf.org, an= d got this: --- www.ietf.org ping statistics --- 29 packets transmitted, 28 packets received, 3.4% packet loss round-trip min/avg/max/stddev =3D 275.850/542.648/1665.121/321.721 ms To be sure, I'm using a laptop connected to a smartphone hotspot, connected= to a 3G cellular network from a moving train half-way around the world. Bu= t still, sub-second retries would have you send unnecessary retransmissions= , and packet loss is pretty low.=20 My own policy is 1 second between first and second transmissions, and the w= ait time is multiplied by sqrt(2) for each additional transmission, so the = 12th transmission is 107 seconds after the first. Close enough, sort of. While it's possible to add a paragraph giving such a policy as an example, = I don't see why we should even imply that this is a requirement. Yoav From paul@cypherpunks.ca Thu Oct 17 08:22:53 2013 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 E79E021F9EB6 for ; Thu, 17 Oct 2013 08:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Amf6TvM1a5Hr for ; Thu, 17 Oct 2013 08:22:46 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id F2E1321F9EB0 for ; Thu, 17 Oct 2013 08:22:43 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d0vJJ597szCCm; Thu, 17 Oct 2013 11:22:40 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id dKdfCyu5EjV6; Thu, 17 Oct 2013 11:22:40 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 17 Oct 2013 11:22:39 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id AB7BC800C4; Thu, 17 Oct 2013 11:22:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9D6E580097; Thu, 17 Oct 2013 11:22:40 -0400 (EDT) Date: Thu, 17 Oct 2013 11:22:40 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yoav Nir In-Reply-To: Message-ID: References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" , Tero Kivinen Subject: Re: [IPsec] Updated version of RFC5996bis 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, 17 Oct 2013 15:22:53 -0000 On Thu, 17 Oct 2013, Yoav Nir wrote: > On Oct 17, 2013, at 5:13 PM, Paul Wouters wrote: >> While updating the retransmit timers in libreswan, I found no useful >> information in 5996. Is that something we could add? I know it is >> local policy but perhaps it would be good to add some guidance for >> implementors. Do people use sub-second retries? exponential backoff? >> How do people deal with slow wakeup stacks (eg 3G) and preventing of >> firsts of duplicate first packets? > > I agree with Yaron. The only guidance is "at least 12 retransmission over at least two minutes" I guess I was hoping for more operation experiences. I was not asking for specific values, but for some more guidance. > To be sure, I'm using a laptop connected to a smartphone hotspot, connected to a 3G cellular network from a moving train half-way around the world. But still, sub-second retries would have you send unnecessary retransmissions, and packet loss is pretty low. Yet some implementations do sub-second retries. Packet loss is high within the first second when you are waking up your 3G chipset for example. If the first packet hits the wakeup, and you wait one second, that's plenty of opportunity for packet leaks. But sending more packets will likely result in a burst of initial packets being sent out. The world is now much more depending on sub-second times than it was before. > My own policy is 1 second between first and second transmissions, and the wait time is multiplied by sqrt(2) for each additional transmission, so the 12th transmission is 107 seconds after the first. Close enough, sort of. > > While it's possible to add a paragraph giving such a policy as an example, I don't see why we should even imply that this is a requirement. I see widely different times from sub-zero to 20 seconds. It suggests implementors have pretty different ideas on what it should be. Paul From mcr@sandelman.ca Thu Oct 17 10:27:46 2013 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 7898A21F9808; Thu, 17 Oct 2013 10:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pQc2NBh8RZg; Thu, 17 Oct 2013 10:27:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 5D34F11E818C; Thu, 17 Oct 2013 10:27:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B6CF620168; Thu, 17 Oct 2013 14:38:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7949A63B88; Thu, 17 Oct 2013 13:27:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 60B4063AEF; Thu, 17 Oct 2013 13:27:33 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org, iesg-secretary@ietf.org In-Reply-To: <7648545.126141382027750318.JavaMail.SYSTEM@priexchange01.ca.primus> References: <7648545.126141382027750318.JavaMail.SYSTEM@priexchange01.ca.primus> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: [IPsec] virtual interim meetings and "freeconference" 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, 17 Oct 2013 17:27:46 -0000 --=-=-= The IPsecME WG had a virtual interim meeting last Wednesday. It used a conference bridge at: +1 712-775-7400 run, I believe by FreeConference. I was unable to reach it from a number of landlines, and mobile. I got in through GoogleTalk's outdial service, but there was significant quality issues. It did not in the end hinder my participation, but it was annoying. I would like to request that future virtual interim meetings use a secretariat provided conference bridge. My VoIP/ISP/LD provider(s) were asked about connections to this number and I was told: >----------------- RESPONSE FROM PRIMUS SUPPORT AGENT ----------------- >Hello Michael, > >We have got the routing checked and found that we will not be able to >complete this call to conference bridge at +1 712-775-7400 due to that NPA >NXX being locked. This is likely due to high toll costs. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUmAeAoqHRg3pndX9AQKJogQA1vpRCRgj5DogWS8aiajZBOiUB4W/zl9O xNZ/cA1EayZ/TWC2Wjy/SS+k9pjakTnBt4ggKbGCMJ0Q+vHRRJQgsjlAREKNloV7 sWIGNGs6iZ6kkxgjUQGaHBsBYsf5fK84/391QN/H4TsAxfOEMsK1XcIJDW5uXarz +1KDU52VjWk= =o4Im -----END PGP SIGNATURE----- --=-=-=-- From paul.hoffman@vpnc.org Thu Oct 17 10:46:51 2013 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 9D45E11E8295 for ; Thu, 17 Oct 2013 10:46:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sJB2DkPOlng for ; Thu, 17 Oct 2013 10:46: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 444D411E81A2 for ; Thu, 17 Oct 2013 10:46:34 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r9HHkVhd009683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 17 Oct 2013 10:46:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: <15968.1382030853@sandelman.ca> Date: Thu, 17 Oct 2013 10:46:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1446A6D7-A20D-4A10-9BB1-F192D488B92B@vpnc.org> References: <7648545.126141382027750318.JavaMail.SYSTEM@priexchange01.ca.primus> <15968.1382030853@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1510) Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] virtual interim meetings and "freeconference" 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, 17 Oct 2013 17:46:51 -0000 On Oct 17, 2013, at 10:27 AM, Michael Richardson = wrote: > The IPsecME WG had a virtual interim meeting last Wednesday. > It used a conference bridge at: +1 712-775-7400 run, I believe by > FreeConference. >=20 > I was unable to reach it from a number of landlines, and mobile. I = got > in through GoogleTalk's outdial service, but there was significant = quality > issues. >=20 > It did not in the end hinder my participation, but it was annoying. >=20 > I would like to request that future virtual interim meetings use > a secretariat provided conference bridge. This is the first we've heard of the problem, but that does sound = significant enough for us not to use that service any more. We'll go = with the IETF's WebEx service for future interims. --Paul Hoffman= From yaronf.ietf@gmail.com Thu Oct 17 11:27:24 2013 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 718F411E82AF for ; Thu, 17 Oct 2013 11:27:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7s6ud6Uda+hZ for ; Thu, 17 Oct 2013 11:27:24 -0700 (PDT) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id CD0ED11E81A2 for ; Thu, 17 Oct 2013 11:27:20 -0700 (PDT) Received: by mail-ee0-f49.google.com with SMTP id d41so1288054eek.22 for ; Thu, 17 Oct 2013 11:27:20 -0700 (PDT) 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=zQFkHaJM9jY+cHgWNbMgv1sfPoLLIM2A40SacVTNf+E=; b=AxJqdTLZ0E1uHd5YKCn+cuUnOIBwqweWuWmtFqR5uBpmi8Ibt2tiyw5NGEA7OBaZaw QLrd2vpVMwoPPnupqDObPKAWA+rhwGKM72i8iOUpar3SbcQnI01X3Ym1qps+iGXOo390 0DpYfFdepKOy7dlR0Kn0s0fb676xXIw9TK84Ks+QjzZsFXAAveegQU3iXLn4mamUtFkW ZY0xpqaorkZZ/PNoPJNeYiU/gHlReGEm7DoKoArYPg6GOq5046L41Gz8atQBunGRBqDJ ovRKG2dOpZGaS535KKXBfrMIHJQ5lvTvUVsmqp9WBfoeSR0buQCzUNkSXr4ad3G5KHtt HeEQ== X-Received: by 10.15.98.194 with SMTP id bj42mr14744094eeb.12.1382034439979; Thu, 17 Oct 2013 11:27:19 -0700 (PDT) Received: from [10.0.0.7] ([109.64.201.200]) by mx.google.com with ESMTPSA id s3sm32733080eeo.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 11:27:19 -0700 (PDT) Message-ID: <52602C06.8040401@gmail.com> Date: Thu, 17 Oct 2013 21:27:18 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Call for adoption: draft-kivinen-ipsecme-ikev2-rfc5996bis-01 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, 17 Oct 2013 18:27:24 -0000 Hi, We would like to progress IKEv2 to Internet Standard, and the way we do it is by re-publishing it with slight modifications (basically editing for existing errata and adding references to documents published since the original RFC). A draft already exists, thanks Tero [1]. If we do not hear significant objections, we would like to adopt the document as a WG document by Monday, Oct. 21. Thanks, Yaron [1] http://tools.ietf.org/id/draft-kivinen-ipsecme-ikev2-rfc5996bis-01.txt From mls@cisco.com Thu Oct 17 11:34:11 2013 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 1156B11E81A2 for ; Thu, 17 Oct 2013 11:34:11 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YTkcHcuC8gh for ; Thu, 17 Oct 2013 11:34:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 352EF11E82CA for ; Thu, 17 Oct 2013 11:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1906; q=dns/txt; s=iport; t=1382034843; x=1383244443; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=o7VKMwT58SLo1AsPRSjDkv13JGGI9ic+S6J3i1p1CLo=; b=LVYoeNJuYZCTsAcQQGQwQ/Rc/0DUsQeHXbphj7lT1KUfZMn0nhzxpehN 2PPVmNdGZZgF5YTRf82BSPha+FM3woOemrE5VFdnaTZbWCY+VuRP2VA0R FTzPQTSc5+SrT9U29OVKfHJmuup9Oy/WtDYVOpef4ZABROhoJo+7qgjTo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoFAHEsYFKtJV2Z/2dsb2JhbABagwc4Ur4HgSkWdIIlAQEBBAEBAWgDCwwEAgEIDgMEAQELHQcnCxQJCAIEDgUIh34MwGwEjyAxBwaDGYEHA4kEoQaDJIIp X-IronPort-AV: E=Sophos;i="4.93,515,1378857600"; d="scan'208";a="273443894" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 17 Oct 2013 18:34:02 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9HIY2UA001339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Oct 2013 18:34:02 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.176]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 17 Oct 2013 13:34:02 -0500 From: "Mike Sullenberger (mls)" To: Valery Smyslov Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt Thread-Index: AQHOxXpgkGhEjGTo0UW8K2/2etWbZZn5QyeQ Date: Thu, 17 Oct 2013 18:34:02 +0000 Message-ID: <9D83DE546CB6DC47A3AE04086FDE35F523F9D4C8@xmb-aln-x06.cisco.com> References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <1B20E03AB216428AA7F16B898AA49FFD@buildpc> In-Reply-To: <1B20E03AB216428AA7F16B898AA49FFD@buildpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.66.51] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Paul Wouters , "Mike Sullenberger \(mls\)" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Thu, 17 Oct 2013 18:34:11 -0000 As I remember it IPv4 has a minimum packet size of 576 that won't (or at le= ast shouldn't be) fragmented by IP. Mike. Mike Sullenberger, DSE mls@cisco.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 .:|:.:|:. Customer Advocacy=A0=A0=A0=A0=A0=A0=A0=A0=A0 CISCO > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Valery Smyslov > Sent: Wednesday, October 09, 2013 10:34 PM > To: Paul Wouters > Cc: ipsec@ietf.org > Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation- > 03.txt >=20 > >> I also think that PMTU discovery isn't very useful for IKE. > >> That's why it is MAY. > > > > That does not help implementors who still have to implement the MAY's. > > if even you as a document author does not think it is very useful, > > then I think it should just not be in the document. >=20 > Sorry, I wasn't very clear. By "isn't very useful" I meant that it is not= useful > for the usual PMTU discovery goal in TCP - to find _maximum_ IP datagram > size that is not fragmented by IP level. In IKE its the goal is different= - to find > _some_reasonable_ IP datagram size that is not fragmented by IP. >=20 > If we have the size that is guaranteed to not be fragmented, no PMTU > discovery will be needed. As far as I understand, for IPv6 it is 1280 byt= es. But > as far as I know, there's no such value for IPv4. > If we mandate (or recommend) using really small value e.g. 128 bytes, tha= n > the performance will suffer badly, so it is not a good option. > I'm especially worrying about network I'm not familiar with - mobile > networks or other constrained environments. > It would be great if some experts in such networks could clarify this. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Thu Oct 17 11:42:23 2013 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 ECB6611E8192 for ; Thu, 17 Oct 2013 11:42:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OyZd0F20sHj for ; Thu, 17 Oct 2013 11:42:23 -0700 (PDT) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 76A9111E813D for ; Thu, 17 Oct 2013 11:42:20 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id e53so1323944eek.41 for ; Thu, 17 Oct 2013 11:42:19 -0700 (PDT) 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=aJC9X6FW/hXMBuOQCqTMWJXhUDh81O/QLpF/ALIwFS0=; b=xfOOdoiec7DlHhXYfzJhhkxJzHJkjL49v6CH7u95tzg9UC66NUO5Oj2WW4eKVEOfAr 1Ez1WT9xSJE3e70GKLTc6+GCWSeZ5DC9kW9eznh1bFSLk/2X+1DznfmK1ebCzRSkgnul dpOWpam9HGfMjttpuKXo0QRwzUVirB8YEVs8UzZWgB3Xw23YsRYKQ1Rcq4pdk6zeuoQp 2QcTId0MMI2qvvgFD10f+G7r3lOUDnvTV/TTbNxMOhlJkuNL2g6cDH8znTbn9slvHss5 dylmdwQgL/gsogBbY+H0zy6dYlc6PXIDVHoMui59DCvn2QJbHZtmjAdRBNZcBG0JGRFZ y/Iw== X-Received: by 10.14.37.4 with SMTP id x4mr14822216eea.16.1382035339742; Thu, 17 Oct 2013 11:42:19 -0700 (PDT) Received: from [10.0.0.7] ([109.64.201.200]) by mx.google.com with ESMTPSA id l49sm112149232eeo.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 11:42:19 -0700 (PDT) Message-ID: <52602F8A.9020405@gmail.com> Date: Thu, 17 Oct 2013 21:42:18 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Call for adoption: draft-kivinen-ipsecme-signature-auth-01 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, 17 Oct 2013 18:42:24 -0000 This document [1] is a product of a design team that we set up some time ago [2]. Unfortunately it has not received enough WG review when it was first published, but we believe it is important in extending IKE and making it more flexible in the face of new certificate types. We would like to formally adopt it into the WG, and then (assuming no objections) publish it around the Vancouver meeting. Please let us know if you think we should NOT adopt the document into the working group, otherwise we will ask the author(s) to republish it as a WG document by next Monday. Thanks, Paul and Yaron [1] http://tools.ietf.org/id/draft-kivinen-ipsecme-signature-auth-01.txt [2] http://www.ietf.org/mail-archive/web/ipsec/current/msg07854.html, yeah that's more than a year ago From ynir@checkpoint.com Thu Oct 17 12:09:37 2013 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 091A811E82D0 for ; Thu, 17 Oct 2013 12:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.431 X-Spam-Level: X-Spam-Status: No, score=-10.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JrWeaazm7pN for ; Thu, 17 Oct 2013 12:09:32 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8971111E82BB for ; Thu, 17 Oct 2013 12:09:31 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9HJ9E3F024337; Thu, 17 Oct 2013 22:09:14 +0300 X-CheckPoint: {52603598-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Thu, 17 Oct 2013 22:09:03 +0300 From: Yoav Nir To: "Mike Sullenberger (mls)" Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt Thread-Index: AQHOy2d5pYcHqbWxPEWgj+5YQk9+DZn5D5+A Date: Thu, 17 Oct 2013 19:09:04 +0000 Message-ID: References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <1B20E03AB216428AA7F16B898AA49FFD@buildpc> <9D83DE546CB6DC47A3AE04086FDE35F523F9D4C8@xmb-aln-x06.cisco.com> In-Reply-To: <9D83DE546CB6DC47A3AE04086FDE35F523F9D4C8@xmb-aln-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.63] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Thu, 17 Oct 2013 19:09:37 -0000 Yes, it says so in RFC 1122. Microsoft sends 576-byte packets when it does = IKEv1 fragmentation. Still, I don't think you're going to find on the modern Internet any networ= ks that aren't usable by IPv6. So I think we should be pretty safe in adopt= ion IPv6's minimum of 1280 Yoav On Oct 17, 2013, at 9:34 PM, Mike Sullenberger (mls) wrote: > As I remember it IPv4 has a minimum packet size of 576 that won't (or at = least shouldn't be) fragmented by IP. >=20 > Mike. >=20 >=20 > Mike Sullenberger, DSE > mls@cisco.com .:|:.:|:. > Customer Advocacy CISCO >=20 >=20 >=20 >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Valery Smyslov >> Sent: Wednesday, October 09, 2013 10:34 PM >> To: Paul Wouters >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation- >> 03.txt >>=20 >>>> I also think that PMTU discovery isn't very useful for IKE. >>>> That's why it is MAY. >>>=20 >>> That does not help implementors who still have to implement the MAY's. >>> if even you as a document author does not think it is very useful, >>> then I think it should just not be in the document. >>=20 >> Sorry, I wasn't very clear. By "isn't very useful" I meant that it is no= t useful >> for the usual PMTU discovery goal in TCP - to find _maximum_ IP datagram >> size that is not fragmented by IP level. In IKE its the goal is differen= t - to find >> _some_reasonable_ IP datagram size that is not fragmented by IP. >>=20 >> If we have the size that is guaranteed to not be fragmented, no PMTU >> discovery will be needed. As far as I understand, for IPv6 it is 1280 by= tes. But >> as far as I know, there's no such value for IPv4. >> If we mandate (or recommend) using really small value e.g. 128 bytes, th= an >> the performance will suffer badly, so it is not a good option. >> I'm especially worrying about network I'm not familiar with - mobile >> networks or other constrained environments. >> It would be great if some experts in such networks could clarify this. >>=20 >> _______________________________________________ >> 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 mls@cisco.com Thu Oct 17 12:31:47 2013 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 252BD11E817B for ; Thu, 17 Oct 2013 12:31:47 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po1rB3einPeJ for ; Thu, 17 Oct 2013 12:31:42 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4735021F8AD5 for ; Thu, 17 Oct 2013 12:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3212; q=dns/txt; s=iport; t=1382038302; x=1383247902; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gh9FSqr92KmCY2r9MM8ONvtephhru8vL6paAG/9iq2A=; b=gTxq53ZckIAKtNF5v9bkpcAj+lkFKSaqYe50YPXOH7mbr11txIdh6mMa di4YgDOTCoSfYDGAsm7ezNtD+37hmAkJjeEGk8YhC1zxY1GdHziwIg2E/ VPWqlAAV3kKJOZmkAh+LnDykOt6DUt5GgKcIo8WUUKURp4lTLlx5TnM8t 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAN46YFKtJV2a/2dsb2JhbABagwc4Ur4JgSkWdIIlAQEBBAEBAWgDCwwEAgEIDgMEAQEBCh0HJwsUCQgCBA4FCId+DMBlBI8gMQcGgxmBBwOJBKEGgySCKQ X-IronPort-AV: E=Sophos;i="4.93,516,1378857600"; d="scan'208";a="273442844" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 17 Oct 2013 19:31:42 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9HJVfTr014148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Oct 2013 19:31:41 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.176]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 17 Oct 2013 14:31:41 -0500 From: "Mike Sullenberger (mls)" To: Yoav Nir Thread-Topic: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt Thread-Index: AQHOy2xhn+zA1cr0o0a8gshhHOvsL5n5R21Q Date: Thu, 17 Oct 2013 19:31:41 +0000 Message-ID: <9D83DE546CB6DC47A3AE04086FDE35F523F9EC04@xmb-aln-x06.cisco.com> References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <1B20E03AB216428AA7F16B898AA49FFD@buildpc> <9D83DE546CB6DC47A3AE04086FDE35F523F9D4C8@xmb-aln-x06.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.66.51] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-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: Thu, 17 Oct 2013 19:31:47 -0000 Yoav, Yes, I agree. In fact except for tunneling stealing bytes, you could like= ly get away with 1500 bytes. I think that 1280 is good compromise, with pe= rhaps a hop down to 576 if 1280 runs into trouble. Mike. Mike Sullenberger, DSE mls@cisco.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 .:|:.:|:. Customer Advocacy=A0=A0=A0=A0=A0=A0=A0=A0=A0 CISCO > -----Original Message----- > From: Yoav Nir [mailto:ynir@checkpoint.com] > Sent: Thursday, October 17, 2013 12:09 PM > To: Mike Sullenberger (mls) > Cc: Valery Smyslov; ipsec@ietf.org; Paul Wouters > Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation- > 03.txt >=20 > Yes, it says so in RFC 1122. Microsoft sends 576-byte packets when it doe= s > IKEv1 fragmentation. >=20 > Still, I don't think you're going to find on the modern Internet any netw= orks > that aren't usable by IPv6. So I think we should be pretty safe in adopti= on > IPv6's minimum of 1280 >=20 > Yoav >=20 > On Oct 17, 2013, at 9:34 PM, Mike Sullenberger (mls) > wrote: >=20 > > As I remember it IPv4 has a minimum packet size of 576 that won't (or a= t > least shouldn't be) fragmented by IP. > > > > Mike. > > > > > > Mike Sullenberger, DSE > > mls@cisco.com .:|:.:|:. > > Customer Advocacy CISCO > > > > > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > >> Behalf Of Valery Smyslov > >> Sent: Wednesday, October 09, 2013 10:34 PM > >> To: Paul Wouters > >> Cc: ipsec@ietf.org > >> Subject: Re: [IPsec] I-D Action: > >> draft-ietf-ipsecme-ikev2-fragmentation- > >> 03.txt > >> > >>>> I also think that PMTU discovery isn't very useful for IKE. > >>>> That's why it is MAY. > >>> > >>> That does not help implementors who still have to implement the > MAY's. > >>> if even you as a document author does not think it is very useful, > >>> then I think it should just not be in the document. > >> > >> Sorry, I wasn't very clear. By "isn't very useful" I meant that it is > >> not useful for the usual PMTU discovery goal in TCP - to find > >> _maximum_ IP datagram size that is not fragmented by IP level. In IKE > >> its the goal is different - to find _some_reasonable_ IP datagram size= that > is not fragmented by IP. > >> > >> If we have the size that is guaranteed to not be fragmented, no PMTU > >> discovery will be needed. As far as I understand, for IPv6 it is 1280 > >> bytes. But as far as I know, there's no such value for IPv4. > >> If we mandate (or recommend) using really small value e.g. 128 bytes, > >> than the performance will suffer badly, so it is not a good option. > >> I'm especially worrying about network I'm not familiar with - mobile > >> networks or other constrained environments. > >> It would be great if some experts in such networks could clarify this. > >> > >> _______________________________________________ > >> 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 Thu Oct 17 12:33:23 2013 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 C8AE211E8191 for ; Thu, 17 Oct 2013 12:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.438 X-Spam-Level: X-Spam-Status: No, score=-10.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0iwGeL8At2Q for ; Thu, 17 Oct 2013 12:33:19 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D8D8E11E82C1 for ; Thu, 17 Oct 2013 12:33:06 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9HJX4xC029361; Thu, 17 Oct 2013 22:33:04 +0300 X-CheckPoint: {52603B2D-1-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Thu, 17 Oct 2013 22:32:53 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [IPsec] Call for adoption: draft-kivinen-ipsecme-signature-auth-01 Thread-Index: AQHOy2ixX/hUPgNRQ0+PhgHXzWzWMJn5FkcA Date: Thu, 17 Oct 2013 19:32:54 +0000 Message-ID: <9E7528BC-55B3-47C5-B4F8-485608C459C9@checkpoint.com> References: <52602F8A.9020405@gmail.com> In-Reply-To: <52602F8A.9020405@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.63] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <9370CBB2101C7C45932246BC3BA3793D@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Call for adoption: draft-kivinen-ipsecme-signature-auth-01 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, 17 Oct 2013 19:33:23 -0000 The message [2] references a discussion on the list. Reading over that disc= ussion, I see that everyone who participated (with the exception of Scott F= luhrer) ended up on the design team, all 5 of us. Within the design group t= here was intense discussion until we settled on the encoding in the draft. = If those discussions had happened on the list, the perception of working gr= oup interest would be different. So my (totally not biased) opinion is that it should be adopted. And if som= eone objects to the particular encoding that we chose, that's fine and can = be discussed on the list. But if we don't hear another comment ever, that's= still fine, because 5 interested people is not abnormally low for a workin= g group draft (they're not all draft-ietf-httpbis-http2), especially a draf= t about encoding. Yoav On Oct 17, 2013, at 9:42 PM, Yaron Sheffer wrote: > This document [1] is a product of a design team that we set up some time = ago [2]. Unfortunately it has not received enough WG review when it was fir= st published, but we believe it is important in extending IKE and making it= more flexible in the face of new certificate types. We would like to forma= lly adopt it into the WG, and then (assuming no objections) publish it arou= nd the Vancouver meeting. Please let us know if you think we should NOT ado= pt the document into the working group, otherwise we will ask the author(s)= to republish it as a WG document by next Monday. >=20 > Thanks, > Paul and Yaron >=20 > [1] http://tools.ietf.org/id/draft-kivinen-ipsecme-signature-auth-01.txt > [2] http://www.ietf.org/mail-archive/web/ipsec/current/msg07854.html, yea= h that's more than a year ago > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Fri Oct 18 03:30:22 2013 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 AB2E511E8163 for ; Fri, 18 Oct 2013 03:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9n6mCA3LPEMO for ; Fri, 18 Oct 2013 03:30:22 -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 423A511E8171 for ; Fri, 18 Oct 2013 03:30:18 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9IAUGU1017740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 Oct 2013 13:30:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9IAUGbk000879; Fri, 18 Oct 2013 13:30:16 +0300 (EEST) 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: <21089.3511.869215.488134@fireball.kivinen.iki.fi> Date: Fri, 18 Oct 2013 13:30:15 +0300 From: Tero Kivinen To: Michael Richardson In-Reply-To: <3164.1365475675@sandelman.ca> References: <3164.1365475675@sandelman.ca> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 0 min Cc: IPsecme WG Subject: Re: [IPsec] WG Last Call on draft-ietf-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: Fri, 18 Oct 2013 10:30:22 -0000 Michael Richardson writes: > I followed the reference to draft-ietf-tls-oob-pubkey-07, which I read. > I would like to suggest that section 3 more quickly refers to the > tls-oob-pubkey Appendix A, and that it say something like: > > In order to provide a simple and standard way to indicate the key > type when the encoding type is 'Raw Public Key', the > SubjectPublicKeyInfo structure of the PKIX certificate is used. > This is a a very simple encoding, as most of the ASN.1 part can be > included literally, and recognized by block comparison. See > [draft-ietf-tls-oob-pubkey] Appendix A for a detailed breakdown. > In addition, Appendix A has a few examples. Changed to that. > (Yes, add a second example... an RSA example.) Created second example, this time I didn't have time to modify my code to actually print out the final IKEv2 payloads, so just created it manually. Hopefully I didn't make any mistakes there... -- kivinen@iki.fi From kivinen@iki.fi Fri Oct 18 03:42:37 2013 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 9D96E11E81CA for ; Fri, 18 Oct 2013 03:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM528G-J5AvZ for ; Fri, 18 Oct 2013 03:42:37 -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 9DAF621F9F31 for ; Fri, 18 Oct 2013 03:42:36 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9IAgVtV021985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 Oct 2013 13:42:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9IAgU5r024053; Fri, 18 Oct 2013 13:42:30 +0300 (EEST) 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: <21089.4246.861381.766755@fireball.kivinen.iki.fi> Date: Fri, 18 Oct 2013 13:42:30 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 11 min Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Updated version of RFC5996bis 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, 18 Oct 2013 10:42:37 -0000 Paul Wouters writes: > On Thu, 17 Oct 2013, Tero Kivinen wrote: > > > I made new version of the RFC5996bis (yes, I am more than month too > > late from my original time-estimate). > > > > This version removes the Raw RSA public keys > > Is that the old version that would be obsoleted by > draft-kivinen-ipsecme-oob-pubkey that no one implemented? Yes. I will submit new version of draft-kivinen-ipsecme-oob-pubkey shortly that will remove all text about that document obsoleting the Raw RSA keys, and just refer that RFC5996bis already did that... > While updating the retransmit timers in libreswan, I found no useful > information in 5996. Is that something we could add? I know it is > local policy but perhaps it would be good to add some guidance for > implementors. Do people use sub-second retries? exponential backoff? > How do people deal with slow wakeup stacks (eg 3G) and preventing of > firsts of duplicate first packets? RFC5996 already has good enough text for that: ---------------------------------------------------------------------- 2.4. State Synchronization and Connection Timeouts ... The number of retries and length of timeouts are not covered in this specification because they do not affect interoperability. It is suggested that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up on an SA, but different environments may require different rules. To be a good network citizen, retransmission times MUST increase exponentially to avoid flooding the network and making an existing congestion situation worse. ---------------------------------------------------------------------- so exponential backoff, whether to use sub-second retries depends on your environment. In host to host case inside the local area network subsecond would be fine (I think we use 0.5 seconds by default). Over the satellite link that would be too fast. It would also be nice if people would implement the DPD properly as defined in the RFC5996: ---------------------------------------------------------------------- If there has only been outgoing traffic on all of the SAs associated with an IKE SA, it is essential to confirm liveness of the other endpoint to avoid black holes. If no cryptographically protected messages have been received on an IKE SA or any of its Child SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. (This is sometimes called "dead peer detection" or "DPD", although it is really detecting live peers, not dead ones.) Receipt of a fresh cryptographically protected message on an IKE SA or any of its Child SAs ensures liveness of the IKE SA and all of its Child SAs. ---------------------------------------------------------------------- Most of the implementations seem to have stupid send DPD every 10 seconds type of implementations, and some people have even complained that we do not do DPD properly as we only send DPD messages if there is no other traffic, not all the time... Anyways I do not think we want to add anything else that is already there in the rfc5996bis. -- kivinen@iki.fi From kivinen@iki.fi Fri Oct 18 05:13:20 2013 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 B39A111E81B6 for ; Fri, 18 Oct 2013 05:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNbYHw+2BXoP for ; Fri, 18 Oct 2013 05:13: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 0EDDC21F9DC9 for ; Fri, 18 Oct 2013 05:10:58 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9ICAucC010696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 Oct 2013 15:10:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9ICAtiq029187; Fri, 18 Oct 2013 15:10:55 +0300 (EEST) 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: <21089.9551.679432.724929@fireball.kivinen.iki.fi> Date: Fri, 18 Oct 2013 15:10:55 +0300 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <525BAA3F.4070204@secunet.com> References: <525BAA3F.4070204@secunet.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Cc: "ipsec@ietf.org WG" Subject: [IPsec] Moving forward with draft-kivinen-ipsecme-signature-auth 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, 18 Oct 2013 12:13:20 -0000 Johannes Merkle writes: > draft-kivinen-ipsecme-signature-auth-01 is about to expire. Given > the current discussions on potential backdoors in NIST > curves (don't want to participate in these conspiracy theories > though), signature algorithm flexibility may be even more > desirable. As it expired today I resubmitted it without changes just to make it easier for people to find it. If you have read -01 version the -02 version is exactly same... -- kivinen@iki.fi From kivinen@iki.fi Fri Oct 18 05:15:36 2013 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 BA1AD11E8224 for ; Fri, 18 Oct 2013 05:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac1ei00j2EKE for ; Fri, 18 Oct 2013 05:15:36 -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 5B68A11E820A for ; Fri, 18 Oct 2013 05:15:34 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9ICFXpL026067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 18 Oct 2013 15:15:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9ICFXHJ026900; Fri, 18 Oct 2013 15:15:33 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="MS8Szi7/02" Content-Transfer-Encoding: 7bit Message-ID: <21089.9829.183841.778540@fireball.kivinen.iki.fi> Date: Fri, 18 Oct 2013 15:15:33 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Subject: [IPsec] FWD from Cao Zhen \(CZ\): [Lwip] WGLC for I-D draft-ietf-lwig-ikev2-minimal-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: Fri, 18 Oct 2013 12:15:36 -0000 --MS8Szi7/02 Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit My draft-ietf-lwig-ikev2-minimal-01.txt is starting WGLC in the lwig WG, and as this is most likely interesting for people also in the ipsecme wg you might want to go and read the document. The comments and discussion about the draft should most likely be on the lwig mailing list (lwip@ietf.org). --MS8Szi7/02 Content-Type: message/rfc822 Content-Description: forwarded message Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Language: zh-cn Content-Type: text/plain; charset="us-ascii" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on fireball.kivinen.iki.fi X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,IKI_FI_RECEIVED, KIVINEN_DIPLOM_TEXT,KIVINEN_GOOD_TEXT,KIVINEN_HTTP_FOUND, KIVINEN_INVESTMENT_FOUND,T_DKIM_INVALID,T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:123a::1:1e]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9I3Pvis000573 for ; Fri, 18 Oct 2013 06:25:57 +0300 (EEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B71921F941F; Thu, 17 Oct 2013 20:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1382066746; bh=CmM5arFnsk6GSdyiZzMVH8njzsCkpKBqJHnrY4nJ6CA=; h=From:To:Date:Message-ID:MIME-Version:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=IODRON3rqhDTl7fhSQqbq+pjyw8Zk3US6Msk/MQof8Pk+vd2DqKyjN0FJn6tnxnZa /ahIs+eL7lRD7SGCbpcGBlw07f9ITdZrj7NahrWHfFGRWMkJAk4kAesE9SWywmhNP6 4cNnguFJfUAiChaZiTSesy8rUp1h7uXazcT3Cgsk= X-Original-To: lwip@ietfa.amsl.com Delivered-To: lwip@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E5A21F937E for ; Thu, 17 Oct 2013 20:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giSgdgQviHmI for ; Thu, 17 Oct 2013 20:25:39 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 0657121F9301 for ; Thu, 17 Oct 2013 20:25:28 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15260a9c6ad3-3dad3; Fri, 18 Oct 2013 11:23:50 +0800 (CST) X-RM-TRANSID: 2ee15260a9c6ad3-3dad3 Received: from cmccPC (unknown[10.2.54.71]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee15260a9c5213-a69fb; Fri, 18 Oct 2013 11:23:50 +0800 (CST) X-RM-TRANSID: 2ee15260a9c5213-a69fb Message-ID: <01a601cecbb1$aad7ea90$0087bfb0$@chinamobile.com> X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7LsZHMhiBNhB52SrGl3X9wWXPTWg== X-BeenThere: lwip@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Lightweight IP stack List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: lwip-bounces@ietf.org From: "Cao Zhen \(CZ\)" Sender: lwip-bounces@ietf.org To: Cc: kivinen@iki.fi Subject: [Lwip] WGLC for I-D draft-ietf-lwig-ikev2-minimal-01.txt Date: Fri, 18 Oct 2013 11:25:17 +0800 hi ALL We received very positive support for this draft to move forward. This message starts a two-week WGLC for this document. If you have any comments or suggestions, please feedback within the timeline. And I believe Vancouver meeting is a good venue for f2f discussion if needed. Thanks and Best regards, Zhen > -----Original Message----- > From: lwip-bounces@ietf.org [mailto:lwip-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Thursday, October 17, 2013 8:35 PM > To: i-d-announce@ietf.org > Cc: lwip@ietf.org > Subject: [Lwip] I-D Action: draft-ietf-lwig-ikev2-minimal-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Light-Weight Implementation Guidance Working Group of the > IETF. > > Title : Minimal IKEv2 > Author(s) : Tero Kivinen > Filename : draft-ietf-lwig-ikev2-minimal-01.txt > Pages : 44 > Date : 2013-10-17 > > Abstract: > This document describes minimal version of the Internet Key Exchange > version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for > performing mutual authentication and establishing and maintaining > Security Associations (SAs). IKEv2 includes several optional > features, which are not needed in minimal implementations. This > document describes what is required from the minimal implementation, > and also describes various optimizations which can be done. The > protocol described here is compliant with full IKEv2 with exception > that this document describes mainly shared secret authentication > (IKEv2 requires support for certificate authentication in addition to > shared secret authentication). > > This document does not update or modify RFC 5996, but provides more > compact description of the minimal version of the protocol. If this > document and RFC 5996 conflicts then RFC 5996 is the authoritative > description. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lwig-ikev2-minimal > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-lwig-ikev2-minimal-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-ikev2-minimal-01 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized > version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Lwip mailing list > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip --MS8Szi7/02 Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- kivinen@iki.fi --MS8Szi7/02-- From internet-drafts@ietf.org Fri Oct 18 05:33:13 2013 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 9BB8C21F9EB8; Fri, 18 Oct 2013 05:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxqdIpHM+q1A; Fri, 18 Oct 2013 05:33:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F67F21F9E94; Fri, 18 Oct 2013 05:32:34 -0700 (PDT) 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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018123234.4069.63132.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 05:32:34 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 12:33:13 -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 : IKEv2 Fragmentation Author(s) : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-fragmentation-04.txt Pages : 21 Date : 2013-10-18 Abstract: This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-ikev2-fragmentation-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From svanru@gmail.com Fri Oct 18 05:42:32 2013 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 E4E8711E821A for ; Fri, 18 Oct 2013 05:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pofsjVdx7wsy for ; Fri, 18 Oct 2013 05:42:32 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6EF11E81B7 for ; Fri, 18 Oct 2013 05:42:31 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id er20so639504lab.21 for ; Fri, 18 Oct 2013 05:42:31 -0700 (PDT) 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; bh=5LwCxvUl1Wk9feWUem4XguemhyC206uOjTSGLyuGWXs=; b=RNsDd4PY2JPV+rlZV+IQSKYJyng0M+cBMi7buRLz5mzz7G9L1kLRiFRsIbq3j7sMr1 +8w4m+AmEH7yQ0XYnG4wjxsTyOaauJuUpVVrmhkOgUVuqGiHmW8g+zACL5hCezWsimfH 9iiNDjbpdwq3eLmEaso7bJEdP2XhaO4S7ihzLQ3oxE3Deie/ctoY4H5gtE/a/F0Q5IQV LPLi5arRQUHK6H1Qzd3ylXkzGIy6QqU575r/i5BRfOxd+HGkLwma8KY1rNHcXK/mUDTE vc8GlOEYW4ah384W2+b79Bxe4NIHolGE/a8tllBqWqc+AgOFWM6+5/A2phycSoZCU8Ae NDuA== X-Received: by 10.152.170.166 with SMTP id an6mr2388119lac.20.1382100150787; Fri, 18 Oct 2013 05:42:30 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id vk8sm1815400lbb.0.2013.10.18.05.42.29 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 18 Oct 2013 05:42:29 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: References: <20131018123234.4069.63132.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 16:42:28 +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] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-04.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: Fri, 18 Oct 2013 12:42:33 -0000 Hi all, I've just posted new version of IKEv2 Fragmentation draft. Comparing with -03 version it addresses Paul's, Yaron's and Tero's comments made on the list. In particular: 1. Rules for sending fragmented message by responder clarified. 2. More words about dual role of Total Fragments. 3. Rules for checking received fragment made more detailed. 4. PMTU described in its own section. Regards, Valery Smyslov. ----- Original Message ----- From: To: Cc: Sent: Friday, October 18, 2013 4:32 PM Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-04.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > > Title : IKEv2 Fragmentation > Author(s) : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-fragmentation-04.txt > Pages : 21 > Date : 2013-10-18 > > Abstract: > This document describes the way to avoid IP fragmentation of large > IKEv2 messages. This allows IKEv2 messages to traverse network > devices that don't allow IP fragments to pass through. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From svanru@gmail.com Fri Oct 18 06:52:54 2013 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 A8E5011E81C4 for ; Fri, 18 Oct 2013 06:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vnK2UJg5Epc for ; Fri, 18 Oct 2013 06:52:53 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8D311E822A for ; Fri, 18 Oct 2013 06:52:49 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id o14so3156459lbi.18 for ; Fri, 18 Oct 2013 06:52:49 -0700 (PDT) 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; bh=T4huQFOCnMudIn3XSO8Ehr12Os06vn6I6ujhgnl3tD0=; b=OhWeUmP5u4XTaEeZLjdyKQsFx2bWrMvDegdlZ6PiKOAnljvrY4/25JvEPZuptedmHs PS/ddovTlWvR+WwPwpcLshawWVNqyKPDPJHWL8cL3Ld6MfxIayHiKP/etaDjjHsM3NBx sDnai1tIswhy92GKWVobVCvEy/oyFCWOLKvYQfmTETr8hHFcTBJS2GR2X1EU9teUWqdr P6ThAGqZqf7mkzyyOiR85LsCyrLo/A78vwe1XtxI2MJWrd5TWP1+MvHSSWVzRZAuSlgF ysrDNM4XTqxvy4p9gOGZVUJ8iX/Xd0RWAWXgeFO3GnT6//VNEX4HPASp+jV7AFW0Q02p U0eA== X-Received: by 10.152.4.38 with SMTP id h6mr2673238lah.12.1382104368879; Fri, 18 Oct 2013 06:52:48 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id ao4sm1701799lac.1.2013.10.18.06.52.45 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 18 Oct 2013 06:52:48 -0700 (PDT) Message-ID: <7C1EFED8998C4309B562F2224DD39AA2@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> Date: Fri, 18 Oct 2013 17:52:42 +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: [IPsec] Editorial changes to RFC5996 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, 18 Oct 2013 13:52:54 -0000 Hi all, as RFC5996 is revised, I suggest to make some editorial changes to improve its clarity and to fix some small issues that I found. 1. Section 1.6 Requirements Terminology is placed far from the begining of the document and all the requirements words, along with terms from RFC4301 etc. are used before they are formally introduced. I don't think it is appropriate for standards track document. I suggest to move this section before Introduction. 2. Page 5: "IKEv2 was a change to the IKE protocol that was not backward compatible. In contrast, the current document not only provides a clarification of IKEv2, but makes minimum changes to the IKE protocol." For me this piece sounds strange. I think it should look like: "IKEv2 was a change to the IKE protocol that was not backward compatible. In contrast, the current document only provides a clarification of IKEv2, and makes minimum changes to the IKEv2 protocol." 3. Page 10. "HDR contains the Security Parameter Indexes (SPIs), version numbers, and flags of various sorts." Not mentioned Message ID, Exchange Type (and Next Payload and length, but they are not very important here). I suggest to change: "HDR contains the Security Parameter Indexes (SPIs), version numbers, Type of Exchange, Message ID and flags of various sorts." 4. Page 11. "At this point in the negotiation, each party can generate SKEYSEED, from which all keys are derived for that IKE SA." Term SKEYSEED pops up from nowhere. No reference is gived and even no word is explained what is it all about. First-time readers will definitely be puzzled. I suggest to change: "At this point in the negotiation, each party can generate a quantity called SKEYSEED (see section 2.14), from which all keys are derived for that IKE SA." 5. Page 14, 15 and 16 "The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group." "The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if the selected cryptographic suite includes that group." "The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group." All three sentencies look like they were copy-pasted and all three lacks mention Nonce Payload. I think it should be explicitely mentioned here, as it was mentioned in descriptions of Initiator's message, above each of this sentencies. And I also think that words in parentheses here are superfluous, as this requirement is comon for all exchanges, not only for CREATE_CHILD_SA, and stated several times in the document. So, I suggest to change: "The responder replies with the accepted offer in an SA payload, nonce in the Nr payload and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group." "The responder replies with the accepted offer in an SA payload, nonce in the Nr payload and a Diffie-Hellman value in the KEr payload if the selected cryptographic suite includes that group." "The responder replies with the accepted offer in an SA payload, nonce in the Nr payload and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the selected cryptographic suite includes that group." 6. Page 19. "The recipient of this notification cannot tell whether the SPI is for AH or ESP, but this is not important because the SPIs are supposed to be different for the two." Why "is supposed to be different"? RFC4301 clearly states: "For a unicast SA, the SPI can be used by itself to specify an SA, or it may be used in conjunction with the IPsec protocol type." So I suggest to change as follows: "The recipient of this notification cannot tell whether the SPI is for AH or ESP, but this is not important because in many cases the SPIs will be different for the two." And some words should be added for the case when SPIs are not different for AH and ESP. I have no good suggestion here. 7. Page 31. Phrase "(see Section 2.6)" actually references the same section. It should either be removed or corrected. 8. Page 31. "However, if the responder sends a non-zero responder SPI, the initiator should not reject the response for only that reason." Should here "should not" be "SHOULD NOT"? 9. Page 49. "There are two types of EAP authentication (described in Section 2.16), and each type uses different values in the AUTH computations shown above. If the EAP method is key-generating, substitute master session key (MSK) for the shared secret in the computation. For non-key-generating methods, substitute SK_pi and SK_pr, respectively, for the shared secret in the two AUTH computations." Isn't this para superfluous here? Its content belongs to EAP authentication and in fact it is described in more details two pages below. 10. Page 51. "As described in Section 2.2, when EAP is used, each pair of IKE SA initial setup messages will have their message numbers incremented; the first pair of AUTH messages will have an ID of 1, the second will be 2, and so on." Should be: "As described in Section 2.2, when EAP is used, each pair of IKE SA initial setup messages will have their message numbers incremented; the first pair of IKE_AUTH messages will have an ID of 1, the second will be 2, and so on." 11. Page 52: "A single CHILD_SA negotiation may result in multiple Security Associations." Should be: "A single CREATE_CHILD_SA negotiation may result in multiple Security Associations." That's all for now. Valery. From yaronf.ietf@gmail.com Fri Oct 18 07:11:50 2013 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 53AF811E81D9 for ; Fri, 18 Oct 2013 07:11:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GmFl-wCJSdk for ; Fri, 18 Oct 2013 07:11:49 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1122D11E81C8 for ; Fri, 18 Oct 2013 07:11:48 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id t10so2023616eei.26 for ; Fri, 18 Oct 2013 07:11:48 -0700 (PDT) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=LP9tlAnRvijQvTstUyMeFYPB2hg/NHnmHcT0ZoekBqQ=; b=ZAkB2blTEgyx2nUXjjYhv4WNZcogzQauEaWVVBe9ZeLJEQwl+c/ik0nIV9REIw4H0b YXgWD6CSLCdHw4RrMosS3MdDPi/WklS7jN1cdbaNYL9+5Bhb3Uf6LKMEpYTJn22SnXpR BtuYJC/Pd73D/ycgp62xEZFXgPc1z+bKurdKHHwgjoEJLIx00RzK7y1xB9ae+s93A3kC XrOfILuwjtlkXyA3LM3EhiKXxWk3E+cNsTt8SorO2YTa2cvYF/vi+9ceyc8XE6KiM3iU mb4tH9hXaEhIKlys/CyJGC7RorgICrnTjYgwbvar82rdz88U7yY4tqzPct9bCOB41Oa9 KbOQ== X-Received: by 10.14.204.5 with SMTP id g5mr7416eeo.110.1382105508163; Fri, 18 Oct 2013 07:11:48 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-183-168-3.red.bezeqint.net. [79.183.168.3]) by mx.google.com with ESMTPSA id s3sm5042909eeo.3.2013.10.18.07.11.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 07:11:47 -0700 (PDT) Message-ID: <526141A0.5030206@gmail.com> Date: Fri, 18 Oct 2013 17:11:44 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Valery Smyslov , Tero Kivinen , ipsec@ietf.org References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> In-Reply-To: <7C1EFED8998C4309B562F2224DD39AA2@buildpc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Editorial changes to RFC5996 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, 18 Oct 2013 14:11:50 -0000 Hi Valery, Sorry for being the Bad Guy on this. Your #6 does not seem editorial to me. Similarly, #8 (adding new RFC 2119 language) is not editorial. I would suggest to implement #6 only if it is critical to interoperability or security, and to forgo #8. By the way, your correction #2 still does not do it IMHO. The sentence refers to RFC 5996. So: "IKEv2 as stated in RFC 4306 was a change to the IKE protocol that was not backward compatible. RFC 5996 revised RFC 4306 to provide a clarification of IKEv2, making minimum changes to the IKEv2 protocol. The current document slightly revises RFC 5996 to make it suitable for progression to Internet Standard." Thanks, Yaron On 2013-10-18 16:52, Valery Smyslov wrote: > Hi all, > > as RFC5996 is revised, I suggest to make some editorial changes > to improve its clarity and to fix some small issues that I found. > > 1. Section 1.6 Requirements Terminology is placed far from the begining > of the document and all the requirements words, along with terms > from RFC4301 etc. are used before they are formally introduced. > I don't think it is appropriate for standards track document. > I suggest to move this section before Introduction. > > 2. Page 5: > "IKEv2 was a change to the IKE protocol that was not backward > compatible. In contrast, the current document not only provides a > clarification of IKEv2, but makes minimum changes to the IKE > protocol." > > For me this piece sounds strange. I think it should look like: > > "IKEv2 was a change to the IKE protocol that was not backward > compatible. In contrast, the current document only provides a > clarification of IKEv2, and makes minimum changes to the IKEv2 > protocol." > > 3. Page 10. > "HDR contains the Security Parameter Indexes (SPIs), version numbers, > and flags of various sorts." > > Not mentioned Message ID, Exchange Type (and Next Payload and length, > but they are not very important here). I suggest to change: > > "HDR contains the Security Parameter Indexes (SPIs), version numbers, > Type of Exchange, Message ID and flags of various sorts." > > 4. Page 11. > "At this point in the negotiation, each party can generate SKEYSEED, > from which all keys are derived for that IKE SA." > > Term SKEYSEED pops up from nowhere. No reference is gived and > even no word is explained what is it all about. First-time readers will > definitely be puzzled. I suggest to change: > > "At this point in the negotiation, each party can generate a quantity > called SKEYSEED (see section 2.14), from which all keys are derived > for that IKE SA." > > 5. Page 14, 15 and 16 > "The responder replies (using the same Message ID to respond) with the > accepted offer in an SA payload, and a Diffie-Hellman value in the > KEr payload if KEi was included in the request and the selected > cryptographic suite includes that group." > > "The responder replies (using the same Message ID to respond) with the > accepted offer in an SA payload, and a Diffie-Hellman value in the > KEr payload if the selected cryptographic suite includes that group." > > "The responder replies (using the same Message ID to respond) with the > accepted offer in an SA payload, and a Diffie-Hellman value in the > KEr payload if KEi was included in the request and the selected > cryptographic suite includes that group." > > All three sentencies look like they were copy-pasted and all three > lacks mention Nonce Payload. I think it should be explicitely > mentioned here, as it was mentioned in descriptions of Initiator's message, > above each of this sentencies. > > And I also think that words in parentheses here are superfluous, > as this requirement is comon for all exchanges, not only for > CREATE_CHILD_SA, > and stated several times in the document. So, I suggest to change: > > "The responder replies with the accepted offer in an SA payload, > nonce in the Nr payload and a Diffie-Hellman value in the > KEr payload if KEi was included in the request and the selected > cryptographic suite includes that group." > > "The responder replies with the accepted offer in an SA payload, > nonce in the Nr payload and a Diffie-Hellman value in the > KEr payload if the selected cryptographic suite includes that group." > > "The responder replies with the accepted offer in an SA payload, > nonce in the Nr payload and a Diffie-Hellman value in the > KEr payload if KEi was included in the request and the selected > cryptographic suite includes that group." > > 6. Page 19. > "The recipient of this notification cannot tell > whether the SPI is for AH or ESP, but this is not important because > the SPIs are supposed to be different for the two." > > Why "is supposed to be different"? RFC4301 clearly states: > "For a unicast SA, the SPI can be used by itself to specify an SA, > or it may be > used in conjunction with the IPsec protocol type." > > So I suggest to change as follows: > > "The recipient of this notification cannot tell > whether the SPI is for AH or ESP, but this is not important because > in many cases the SPIs will be different for the two." > > And some words should be added for the case when SPIs are not > different for AH and ESP. I have no good suggestion here. > > 7. Page 31. > Phrase "(see Section 2.6)" actually references the same section. It > should either > be removed or corrected. > > 8. Page 31. > "However, if the responder sends a non-zero > responder SPI, the initiator should not reject the response for only > that reason." > > Should here "should not" be "SHOULD NOT"? > > 9. Page 49. > "There are two types of EAP authentication (described in > Section 2.16), and each type uses different values in the AUTH > computations shown above. If the EAP method is key-generating, > substitute master session key (MSK) for the shared secret in the > computation. For non-key-generating methods, substitute SK_pi and > SK_pr, respectively, for the shared secret in the two AUTH > computations." > > Isn't this para superfluous here? Its content belongs to EAP authentication > and in fact it is described in more details two pages below. > > 10. Page 51. > "As described in Section 2.2, when EAP is used, each pair of IKE SA > initial setup messages will have their message numbers incremented; > the first pair of AUTH messages will have an ID of 1, the second will > be 2, and so on." > > Should be: > > "As described in Section 2.2, when EAP is used, each pair of IKE SA > initial setup messages will have their message numbers incremented; > the first pair of IKE_AUTH messages will have an ID of 1, the second > will > be 2, and so on." > > 11. Page 52: > "A single CHILD_SA negotiation may result in multiple Security > Associations." > > Should be: > > "A single CREATE_CHILD_SA negotiation may result in multiple Security > Associations." > > > > That's all for now. > Valery. > > > > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From svanru@gmail.com Fri Oct 18 07:24:30 2013 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 30B9211E82C4 for ; Fri, 18 Oct 2013 07:24:30 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHNtYs2Alqbx for ; Fri, 18 Oct 2013 07:24:29 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id BDA6011E82B3 for ; Fri, 18 Oct 2013 07:24:27 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id eo20so664711lab.12 for ; Fri, 18 Oct 2013 07:24:26 -0700 (PDT) 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; bh=BYdNX+mVchVJVVLm6PgN8egLlco/1Su2t6TCTqdv5R8=; b=iIv2jArm5d99Wrko0YhUs0RMAdFprkFjfUiYEcSQ9CrN/4/JfwZsD7eUNpfgDW8ViL vFx/FpA4QyEwt3G3sPXDrsyAIE+EfNLDwnmddBBl9+i8tUPbixeNpJd2hI9IxKV0qV/z 1IMvCEhqFQ0aFA2FkX25Xn2JKyEbYcNHRPHfnF6eYkIc0ghX9xNBLputp4mCCZMDpJbz e7KCsX/1S1xfK5AhACYf/Db1yYsLuEWagsbCuDiJxW/1JOoqr5aVV4e7jUBAaSpXL+r/ /oW3NXFIqNyvhg08xnIM0lDz5pBrfPm83rQ+00EMfLhjK3sTv2HmPp3lOM4PLdIp0lPW juKg== X-Received: by 10.152.23.137 with SMTP id m9mr2695191laf.17.1382106266651; Fri, 18 Oct 2013 07:24:26 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id ua4sm2050645lbb.17.2013.10.18.07.24.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 18 Oct 2013 07:24:25 -0700 (PDT) Message-ID: <3AAB8F2857A0484D9CE7DF44871E7D02@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "Tero Kivinen" , References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> <526141A0.5030206@gmail.com> Date: Fri, 18 Oct 2013 18:24:24 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response 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] Editorial changes to RFC5996 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, 18 Oct 2013 14:24:30 -0000 Hi Yaron, > Hi Valery, > > Sorry for being the Bad Guy on this. Your #6 does not seem editorial to I think that current text is not aligned with RFC4301. We may leave it as is or try to find other form that would not appear so misaligned. > me. Similarly, #8 (adding new RFC 2119 language) is not editorial. I would > suggest to implement #6 only if it is critical to interoperability or > security, and to forgo #8. What about #8 - it's just a question from me. From my feeling it must be uppercase, but I might be wrong. We may leave it as is. > By the way, your correction #2 still does not do it IMHO. The sentence > refers to RFC 5996. So: > > "IKEv2 as stated in RFC 4306 was a change to the IKE protocol that was not > backward compatible. RFC 5996 revised RFC 4306 to provide a clarification > of IKEv2, making minimum changes to the IKEv2 protocol. The current > document slightly revises RFC 5996 to make it suitable for progression to > Internet Standard." Yes, your text is for RFC5996bis, while I made my notes a while ago and the text was for RFC5996. Of course your variant is better. Valery. > Thanks, > Yaron > > On 2013-10-18 16:52, Valery Smyslov wrote: >> Hi all, >> >> as RFC5996 is revised, I suggest to make some editorial changes >> to improve its clarity and to fix some small issues that I found. >> >> 1. Section 1.6 Requirements Terminology is placed far from the begining >> of the document and all the requirements words, along with terms >> from RFC4301 etc. are used before they are formally introduced. >> I don't think it is appropriate for standards track document. >> I suggest to move this section before Introduction. >> >> 2. Page 5: >> "IKEv2 was a change to the IKE protocol that was not backward >> compatible. In contrast, the current document not only provides a >> clarification of IKEv2, but makes minimum changes to the IKE >> protocol." >> >> For me this piece sounds strange. I think it should look like: >> >> "IKEv2 was a change to the IKE protocol that was not backward >> compatible. In contrast, the current document only provides a >> clarification of IKEv2, and makes minimum changes to the IKEv2 >> protocol." >> >> 3. Page 10. >> "HDR contains the Security Parameter Indexes (SPIs), version numbers, >> and flags of various sorts." >> >> Not mentioned Message ID, Exchange Type (and Next Payload and length, >> but they are not very important here). I suggest to change: >> >> "HDR contains the Security Parameter Indexes (SPIs), version numbers, >> Type of Exchange, Message ID and flags of various sorts." >> >> 4. Page 11. >> "At this point in the negotiation, each party can generate SKEYSEED, >> from which all keys are derived for that IKE SA." >> >> Term SKEYSEED pops up from nowhere. No reference is gived and >> even no word is explained what is it all about. First-time readers will >> definitely be puzzled. I suggest to change: >> >> "At this point in the negotiation, each party can generate a quantity >> called SKEYSEED (see section 2.14), from which all keys are derived >> for that IKE SA." >> >> 5. Page 14, 15 and 16 >> "The responder replies (using the same Message ID to respond) with the >> accepted offer in an SA payload, and a Diffie-Hellman value in the >> KEr payload if KEi was included in the request and the selected >> cryptographic suite includes that group." >> >> "The responder replies (using the same Message ID to respond) with the >> accepted offer in an SA payload, and a Diffie-Hellman value in the >> KEr payload if the selected cryptographic suite includes that group." >> >> "The responder replies (using the same Message ID to respond) with the >> accepted offer in an SA payload, and a Diffie-Hellman value in the >> KEr payload if KEi was included in the request and the selected >> cryptographic suite includes that group." >> >> All three sentencies look like they were copy-pasted and all three >> lacks mention Nonce Payload. I think it should be explicitely >> mentioned here, as it was mentioned in descriptions of Initiator's >> message, >> above each of this sentencies. >> >> And I also think that words in parentheses here are superfluous, >> as this requirement is comon for all exchanges, not only for >> CREATE_CHILD_SA, >> and stated several times in the document. So, I suggest to change: >> >> "The responder replies with the accepted offer in an SA payload, >> nonce in the Nr payload and a Diffie-Hellman value in the >> KEr payload if KEi was included in the request and the selected >> cryptographic suite includes that group." >> >> "The responder replies with the accepted offer in an SA payload, >> nonce in the Nr payload and a Diffie-Hellman value in the >> KEr payload if the selected cryptographic suite includes that group." >> >> "The responder replies with the accepted offer in an SA payload, >> nonce in the Nr payload and a Diffie-Hellman value in the >> KEr payload if KEi was included in the request and the selected >> cryptographic suite includes that group." >> >> 6. Page 19. >> "The recipient of this notification cannot tell >> whether the SPI is for AH or ESP, but this is not important because >> the SPIs are supposed to be different for the two." >> >> Why "is supposed to be different"? RFC4301 clearly states: >> "For a unicast SA, the SPI can be used by itself to specify an SA, >> or it may be >> used in conjunction with the IPsec protocol type." >> >> So I suggest to change as follows: >> >> "The recipient of this notification cannot tell >> whether the SPI is for AH or ESP, but this is not important because >> in many cases the SPIs will be different for the two." >> >> And some words should be added for the case when SPIs are not >> different for AH and ESP. I have no good suggestion here. >> >> 7. Page 31. >> Phrase "(see Section 2.6)" actually references the same section. It >> should either >> be removed or corrected. >> >> 8. Page 31. >> "However, if the responder sends a non-zero >> responder SPI, the initiator should not reject the response for only >> that reason." >> >> Should here "should not" be "SHOULD NOT"? >> >> 9. Page 49. >> "There are two types of EAP authentication (described in >> Section 2.16), and each type uses different values in the AUTH >> computations shown above. If the EAP method is key-generating, >> substitute master session key (MSK) for the shared secret in the >> computation. For non-key-generating methods, substitute SK_pi and >> SK_pr, respectively, for the shared secret in the two AUTH >> computations." >> >> Isn't this para superfluous here? Its content belongs to EAP >> authentication >> and in fact it is described in more details two pages below. >> >> 10. Page 51. >> "As described in Section 2.2, when EAP is used, each pair of IKE SA >> initial setup messages will have their message numbers incremented; >> the first pair of AUTH messages will have an ID of 1, the second will >> be 2, and so on." >> >> Should be: >> >> "As described in Section 2.2, when EAP is used, each pair of IKE SA >> initial setup messages will have their message numbers incremented; >> the first pair of IKE_AUTH messages will have an ID of 1, the second >> will >> be 2, and so on." >> >> 11. Page 52: >> "A single CHILD_SA negotiation may result in multiple Security >> Associations." >> >> Should be: >> >> "A single CREATE_CHILD_SA negotiation may result in multiple Security >> Associations." >> >> >> >> That's all for now. >> Valery. >> >> >> >> >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > From svanru@gmail.com Fri Oct 18 07:41:18 2013 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 8A9F511E819D for ; Fri, 18 Oct 2013 07:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZwK9jn22kxC for ; Fri, 18 Oct 2013 07:41:18 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 340B311E828C for ; Fri, 18 Oct 2013 07:41:17 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id z5so3268136lbh.0 for ; Fri, 18 Oct 2013 07:41:16 -0700 (PDT) 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; bh=EleRnJqgu1JIVR87iPi+GmU/HRB9Ez1ezFRghfsFPj0=; b=BFTAwYy/UNDE7jx4RQjFqXJzpSkrpO3ooqM61DVbq+dwCvTKEb/kNVVDfDlsqMrOR8 RVjOgFKcd8YM0D2wQKUYZKeKWREUvRRTiR/qIv7ZcsDUn5ySZC5i2yW3WvhFdrOtn0yv +zil9NQJR8XjWLWqehT6zfZg/uoKys6fLLoL8Pr1T5b8jMufblGhziaLQ3QNE7+wqbN6 GaeFNnimgmw9/2Jq9ZkIPW+dLXyIiOV7Io1h/gghFCnZBuBV2W6mvmhJ/+TgQOXuN0Wb 5mnrfuQuhJd8nwrCgRIddosx0seMpRlhe/2oJa2jGZAVBY5ZqyXDc9jEWw66mDlGXFW5 DLlQ== X-Received: by 10.152.22.97 with SMTP id c1mr1922046laf.31.1382107276077; Fri, 18 Oct 2013 07:41:16 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id pw4sm2112737lbb.9.2013.10.18.07.41.14 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 18 Oct 2013 07:41:15 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" , "Mike Sullenberger \(mls\)" References: <20131004123552.12797.87073.idtracker@ietfa.amsl.com> <44D6A1836A274C98907D95D59E530FE6@buildpc> <524EC6D8.9040006@gmail.com> <8B0A76CCEF2F4C65A9101BBD717B5C0F@buildpc> <1B20E03AB216428AA7F16B898AA49FFD@buildpc> <9D83DE546CB6DC47A3AE04086FDE35F523F9D4C8@xmb-aln-x06.cisco.com> Date: Fri, 18 Oct 2013 18:41:14 +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, Paul Wouters Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-fragmentation-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: Fri, 18 Oct 2013 14:41:18 -0000 Hi Yoav, > Yes, it says so in RFC 1122. Microsoft sends 576-byte packets when it does > IKEv1 fragmentation. Actually, it is not a requirement in RFC1122, but only recommendation (although a "strong" one): "Since nearly all networks in the Internet currently support an MTU of 576 or greater, we strongly recommend the use of 576 for datagrams sent to non-local networks." But I agree that 576 works in 90 or more percent of cases. And even 1280 will probably work for IPv4, but not so sure about it. Valery. > Still, I don't think you're going to find on the modern Internet any > networks that aren't usable by IPv6. > So I think we should be pretty safe in adoption IPv6's minimum of 1280 > > Yoav > > On Oct 17, 2013, at 9:34 PM, Mike Sullenberger (mls) > wrote: > > > As I remember it IPv4 has a minimum packet size of 576 that won't (or at > > least shouldn't be) fragmented by IP. > > > > Mike. From mcr@sandelman.ca Fri Oct 18 08:29:33 2013 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 AB8BA1F0D4F for ; Fri, 18 Oct 2013 08:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OqPDhNsNm2i for ; Fri, 18 Oct 2013 08:29:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id C225A11E8263 for ; Fri, 18 Oct 2013 08:29:03 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 209E02026F; Fri, 18 Oct 2013 12:39:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4CFC063B88; Fri, 18 Oct 2013 11:28:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3B9B063AEF; Fri, 18 Oct 2013 11:28:54 -0400 (EDT) From: Michael Richardson To: Yaron Sheffer In-Reply-To: <52602C06.8040401@gmail.com> References: <52602C06.8040401@gmail.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: IPsecme WG Subject: Re: [IPsec] Call for adoption: draft-kivinen-ipsecme-ikev2-rfc5996bis-01 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, 18 Oct 2013 15:29:33 -0000 --=-=-= Yaron Sheffer wrote: > We would like to progress IKEv2 to Internet Standard, and the way we do > it is by re-publishing it with slight modifications (basically editing > for existing errata and adding references to documents published since Good. > the original RFC). A draft already exists, thanks Tero [1]. If we do > not hear significant objections, we would like to adopt the document as > a WG document by Monday, Oct. 21. +1. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUmFTs4qHRg3pndX9AQK6NQP/dUPm6As+Dfel9QZHus0lfGGEk/ecr98K 6Kk1VCXWGbDo45G8E2Iz3a1SXoXC58LfgZTgHVZjzNcld5/7NW7+k9A5IQ69vcdQ ygXRTsN6lrsCNPfOngwCtBlafVCsCpGB1/g3llYGZWDGRW64snR1qgxNVq8hCCGC TKXkpE5IPZw= =4Mz8 -----END PGP SIGNATURE----- --=-=-=-- From paul.hoffman@vpnc.org Fri Oct 18 18:47:27 2013 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 CE1EC11E8115 for ; Fri, 18 Oct 2013 18:47:27 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhr0uTpfTO31 for ; Fri, 18 Oct 2013 18:47:27 -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 9525D11E8117 for ; Fri, 18 Oct 2013 18:47:25 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r9J1lOqL071038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 18 Oct 2013 18:47:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9F7302CD-1722-45B6-BAA9-EF50BBAC945C@vpnc.org> Date: Fri, 18 Oct 2013 18:47:23 -0700 To: "ipsec@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [IPsec] Beginning of WG Last Call on 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, 19 Oct 2013 01:47:27 -0000 Greetings again. The WG's draft on IKEv2 fragmentation has gotten a fair = amount of review in the past few months, and is thus ready for a = two-week WG Last Call (ending November 1). The draft is at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation Please read this draft and send any comments to the WG mailing list, = even if the comments are "I see no problems". Comments such as "I do not = understand this part" or "this part could be explained better in this = way" are particularly useful at this point. If you have an IKEv2 implementation, or are using someone else's IKEv2 = implementation in your products, you really should be reviewing and = commenting on this draft. This will have a significant impact on IKEv2 = implementations in the future, and having anything wrong or even unclear = in the draft will make everyone's life worse. Please do a review and = send any comments to the list. --Paul Hoffman= From paul.hoffman@vpnc.org Fri Oct 18 18:49:44 2013 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 D200221F9D7E for ; Fri, 18 Oct 2013 18:49:44 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QklDI5mz40Ig for ; Fri, 18 Oct 2013 18:49:44 -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 62BF221F9B21 for ; Fri, 18 Oct 2013 18:49:44 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r9J1nhFX071119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 18 Oct 2013 18:49:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <043754AD-BA58-4C9A-8491-114EE28E9F0E@vpnc.org> Date: Fri, 18 Oct 2013 18:49:43 -0700 To: "ipsec@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [IPsec] Beginning of WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation 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, 19 Oct 2013 01:49:44 -0000 Greetings again. The WG's draft on IKEv2 fragmentation has gotten a fair = amount of review in the past few months, and is thus ready for a = two-week WG Last Call (ending November 1). The draft is at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation Please read this draft and send any comments to the WG mailing list, = even if the comments are "I see no problems". Comments such as "I do not = understand this part" or "this part could be explained better in this = way" are particularly useful at this point. If you have an IKEv2 implementation, or are using someone else's IKEv2 = implementation in your products, you really should be reviewing and = commenting on this draft. This will have a significant impact on IKEv2 = implementations in the future, and having anything wrong or even unclear = in the draft will make everyone's life worse. Please do a review and = send any comments to the list. --Paul Hoffman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Sat Oct 19 04:56:41 2013 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 077A211E81B7 for ; Sat, 19 Oct 2013 04:56:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UX793xDnIQR for ; Sat, 19 Oct 2013 04:56:40 -0700 (PDT) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id B81A811E80E7 for ; Sat, 19 Oct 2013 04:56:36 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id e50so1400354eek.35 for ; Sat, 19 Oct 2013 04:56:26 -0700 (PDT) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=Y7jH3x84N7kJFNVxUj6TT3wsSJVjVwESB4oRfcOXO+w=; b=gmWa1su1TVbb4RD1PIn22sXhaWjm2sDhOPUp3R7OGpy/SWUIYTxa7gYOKqUdaIXm3C oGNImrbJAeYMd8yuok0OXcl7nADAiIm3DiU+rDNiGCZTdEoOx+r9mMxypfjKoNHZPWvJ J/Ltq/SOlj6dUJKPIZpf0eh8TekZZ5PPe92GaD7cCQKn6pbIUGwVNihK3CuJX5uc+tPP Ev50cj39wPbB7pwd1wjkTIRPHJ7qB5jFWArGbO0/HMfrr5amhFQjot+ELVOlbxANsnrQ /6jD+rp3TUYSP2FczgPPupzycA/P2s4C5Wcst/dF2uZgHjQ6IoHUtE+QMCW/GVIZwp3r Nykg== X-Received: by 10.15.99.205 with SMTP id bl53mr8507415eeb.82.1382183786288; Sat, 19 Oct 2013 04:56:26 -0700 (PDT) Received: from [10.0.0.2] (bzq-109-66-165-46.red.bezeqint.net. [109.66.165.46]) by mx.google.com with ESMTPSA id x47sm16840925eea.16.2013.10.19.04.56.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Oct 2013 04:56:25 -0700 (PDT) Message-ID: <52627368.8090200@gmail.com> Date: Sat, 19 Oct 2013 14:56:24 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Valery Smyslov , Tero Kivinen , ipsec@ietf.org References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> <526141A0.5030206@gmail.com> <3AAB8F2857A0484D9CE7DF44871E7D02@buildpc> In-Reply-To: <3AAB8F2857A0484D9CE7DF44871E7D02@buildpc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Editorial changes to RFC5996 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, 19 Oct 2013 11:56:41 -0000 > Hi Yaron, > >> Hi Valery, >> >> Sorry for being the Bad Guy on this. Your #6 does not seem editorial to > > I think that current text is not aligned with RFC4301. > We may leave it as is or try to find other form that > would not appear so misaligned. Your new text is fine, if we leave it at that. If we try to add text to deal with the exceptional cases (same SPI shared between protocols), this will quickly become normative. I don't want to do it in "bis" and frankly, I think this situation is too rare to matter. > >> me. Similarly, #8 (adding new RFC 2119 language) is not editorial. I >> would suggest to implement #6 only if it is critical to >> interoperability or security, and to forgo #8. > > What about #8 - it's just a question from me. From my feeling it must > be uppercase, but I might be wrong. We may leave it as is. IETF process is very serious about the difference between lowercase and uppercase (see RFC 6919). Maybe it should have been a SHOULD to start with. But we SHOULD NOT change it for a "bis" document. > >> By the way, your correction #2 still does not do it IMHO. The sentence >> refers to RFC 5996. So: >> >> "IKEv2 as stated in RFC 4306 was a change to the IKE protocol that was >> not backward compatible. RFC 5996 revised RFC 4306 to provide a >> clarification of IKEv2, making minimum changes to the IKEv2 protocol. >> The current document slightly revises RFC 5996 to make it suitable for >> progression to Internet Standard." > > Yes, your text is for RFC5996bis, while I made my notes a while ago > and the text was for RFC5996. Of course your variant is better. > > Valery. > >> Thanks, >> Yaron >> From ynir@checkpoint.com Sat Oct 19 05:27:40 2013 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 6CB1B11E81A9 for ; Sat, 19 Oct 2013 05:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.445 X-Spam-Level: X-Spam-Status: No, score=-10.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaQhKBdgQgHZ for ; Sat, 19 Oct 2013 05:27:35 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4C211E81A6 for ; Sat, 19 Oct 2013 05:27:32 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9JCRPxn023027; Sat, 19 Oct 2013 15:27:25 +0300 X-CheckPoint: {52627A50-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Sat, 19 Oct 2013 15:27:13 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [IPsec] Editorial changes to RFC5996 Thread-Index: AQHOzA2+dLcjLOCdL06EwmTj3kWAkpn7uhEAgAAIr4A= Date: Sat, 19 Oct 2013 12:27:14 +0000 Message-ID: <3D85C762-B605-4CA3-A21F-21878B846486@checkpoint.com> References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> <526141A0.5030206@gmail.com> <3AAB8F2857A0484D9CE7DF44871E7D02@buildpc> <52627368.8090200@gmail.com> In-Reply-To: <52627368.8090200@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.153] 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: "" , Valery Smyslov , Tero Kivinen Subject: Re: [IPsec] Editorial changes to RFC5996 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, 19 Oct 2013 12:27:40 -0000 Hi, Yaron Suppose that instead of sending the message to the list yesterday, Valery h= ad submitted his comments as errata a few months ago, before Sean asked us = to do the revision. Would those errata not have been verified? If so (and I think it's true for at least #3, #4, #7, and #11, and #6 would= also merit some new text), the corrections would now be in the draft. So w= hy not now? Yoav On Oct 19, 2013, at 2:56 PM, Yaron Sheffer wrote: >> Hi Yaron, >>=20 >>> Hi Valery, >>>=20 >>> Sorry for being the Bad Guy on this. Your #6 does not seem editorial to >>=20 >> I think that current text is not aligned with RFC4301. >> We may leave it as is or try to find other form that >> would not appear so misaligned. >=20 > Your new text is fine, if we leave it at that. If we try to add text to d= eal with the exceptional cases (same SPI shared between protocols), this wi= ll quickly become normative. I don't want to do it in "bis" and frankly, I = think this situation is too rare to matter. >=20 >>=20 >>> me. Similarly, #8 (adding new RFC 2119 language) is not editorial. I >>> would suggest to implement #6 only if it is critical to >>> interoperability or security, and to forgo #8. >>=20 >> What about #8 - it's just a question from me. From my feeling it must >> be uppercase, but I might be wrong. We may leave it as is. >=20 > IETF process is very serious about the difference between lowercase and u= ppercase (see RFC 6919). Maybe it should have been a SHOULD to start with. = But we SHOULD NOT change it for a "bis" document. >=20 >>=20 >>> By the way, your correction #2 still does not do it IMHO. The sentence >>> refers to RFC 5996. So: >>>=20 >>> "IKEv2 as stated in RFC 4306 was a change to the IKE protocol that was >>> not backward compatible. RFC 5996 revised RFC 4306 to provide a >>> clarification of IKEv2, making minimum changes to the IKEv2 protocol. >>> The current document slightly revises RFC 5996 to make it suitable for >>> progression to Internet Standard." >>=20 >> Yes, your text is for RFC5996bis, while I made my notes a while ago >> and the text was for RFC5996. Of course your variant is better. >>=20 >> Valery. >>=20 >>> Thanks, >>> Yaron >>>=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Sat Oct 19 08:47:16 2013 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 B5D5011E81F9 for ; Sat, 19 Oct 2013 08:47:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHkW0WI7IuoF for ; Sat, 19 Oct 2013 08:47:16 -0700 (PDT) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id DF78811E81EB for ; Sat, 19 Oct 2013 08:47:15 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id e53so2683097eek.41 for ; Sat, 19 Oct 2013 08:47:15 -0700 (PDT) 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=O3LJiz4vPet1LQRVbXn2zpmSR/9UeprmMRfFiF23lzk=; b=F+ocjjzcCCAM9Gk0zeA0s3OX6L0sYteNB88IuZo43q/vuIloVrRC4puEFoyVEg5xRu qs62qB4Z49kO7jlFD0UEdNVUeBf3mlNe2cu7WzF2bo/X0GxJAob3a7xlfAW1zRIjPRDv LBDt+XC0Yj8Pm5aaThz2meAs4a71NavMe4qVtDBdPDpywxzsbhRQ4covVb7/ReCqg2JB eE9OlbdoOGX7RdbcBpxgof2B9OE5gdG/br32B2o2t9jdwntnxBvLeBSfmOiH0VJUjKzV 4JV1qAtoo05lKOzQn6vRAm/w8kAtFgjmBJvNT7hp/XOgayQ6FgFMKYgC5gyEQfmHMWEq Y9JQ== X-Received: by 10.15.44.202 with SMTP id z50mr344412eev.68.1382197634894; Sat, 19 Oct 2013 08:47:14 -0700 (PDT) Received: from [10.0.0.2] ([109.66.165.46]) by mx.google.com with ESMTPSA id i1sm19191568eeg.0.2013.10.19.08.47.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Oct 2013 08:47:13 -0700 (PDT) Message-ID: <5262A980.10304@gmail.com> Date: Sat, 19 Oct 2013 18:47:12 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Yoav Nir References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> <526141A0.5030206@gmail.com> <3AAB8F2857A0484D9CE7DF44871E7D02@buildpc> <52627368.8090200@gmail.com> <3D85C762-B605-4CA3-A21F-21878B846486@checkpoint.com> In-Reply-To: <3D85C762-B605-4CA3-A21F-21878B846486@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , Valery Smyslov , Tero Kivinen Subject: Re: [IPsec] Editorial changes to RFC5996 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, 19 Oct 2013 15:47:16 -0000 Hi Yoav, You're probably right in your speculation. But my point was that Valery's subject line said "editorial changes", and two of these changes were arguably non-editorial. Technical changes would be treated differently in an errata review and should be treated differently in a "bis" document, whose main purpose in life is to progress (i.e., stabilize) the protocol. Thanks, Yaron On 2013-10-19 15:27, Yoav Nir wrote: > Hi, Yaron > > Suppose that instead of sending the message to the list yesterday, Valery had submitted his comments as errata a few months ago, before Sean asked us to do the revision. Would those errata not have been verified? > > If so (and I think it's true for at least #3, #4, #7, and #11, and #6 would also merit some new text), the corrections would now be in the draft. So why not now? > > Yoav > > On Oct 19, 2013, at 2:56 PM, Yaron Sheffer wrote: > >>> Hi Yaron, >>> >>>> Hi Valery, >>>> >>>> Sorry for being the Bad Guy on this. Your #6 does not seem editorial to >>> >>> I think that current text is not aligned with RFC4301. >>> We may leave it as is or try to find other form that >>> would not appear so misaligned. >> >> Your new text is fine, if we leave it at that. If we try to add text to deal with the exceptional cases (same SPI shared between protocols), this will quickly become normative. I don't want to do it in "bis" and frankly, I think this situation is too rare to matter. >> >>> >>>> me. Similarly, #8 (adding new RFC 2119 language) is not editorial. I >>>> would suggest to implement #6 only if it is critical to >>>> interoperability or security, and to forgo #8. >>> >>> What about #8 - it's just a question from me. From my feeling it must >>> be uppercase, but I might be wrong. We may leave it as is. >> >> IETF process is very serious about the difference between lowercase and uppercase (see RFC 6919). Maybe it should have been a SHOULD to start with. But we SHOULD NOT change it for a "bis" document. >> >>> >>>> By the way, your correction #2 still does not do it IMHO. The sentence >>>> refers to RFC 5996. So: >>>> >>>> "IKEv2 as stated in RFC 4306 was a change to the IKE protocol that was >>>> not backward compatible. RFC 5996 revised RFC 4306 to provide a >>>> clarification of IKEv2, making minimum changes to the IKEv2 protocol. >>>> The current document slightly revises RFC 5996 to make it suitable for >>>> progression to Internet Standard." >>> >>> Yes, your text is for RFC5996bis, while I made my notes a while ago >>> and the text was for RFC5996. Of course your variant is better. >>> >>> Valery. >>> >>>> Thanks, >>>> Yaron >>>> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > From svanru@gmail.com Sun Oct 20 21:54:00 2013 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 0235C11E8115 for ; Sun, 20 Oct 2013 21:54:00 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+b7gfquOyrA for ; Sun, 20 Oct 2013 21:53:59 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 80DF211E8149 for ; Sun, 20 Oct 2013 21:53:57 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id w6so4993186lbh.5 for ; Sun, 20 Oct 2013 21:53:56 -0700 (PDT) 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; bh=wFZaZ7yly8taBGqL0hmkdautYzspDSXDIbGlRSGbUdE=; b=Lgndln/KX1X7q4ZzYz0xA/fcf3mzqkoRibv2lCCkZuCPVbKNL+kfjbJArASmLPZUoX yNfe+QLM0B6EIkUmtiZiiJ8xMAY7UWIhqVflbFLO+6u2s6+La+azyviCwOFBKLHAF4Sb XqWKtAdBVG5jMJA3q5IX0KR/6gAtYi9X/BF7nRr6qi+kKfyPI8gF9fVco6TpT2MXcceo GTRFEj9wy15QVDcY7sknHE+q2EGoOkZ/jojdy/CXkbsVKhzVE8LGFNWltH6Olo/V9Aog 4M1uJqlnzHMTNSixzUiNU/WP57h/1bzMaOE8HRXQ+4lIY8FPiqsTd2MJ1T68ft6mFI5J +uGg== X-Received: by 10.112.135.104 with SMTP id pr8mr147123lbb.34.1382331236079; Sun, 20 Oct 2013 21:53:56 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id mr1sm10853131lbc.16.2013.10.20.21.53.54 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 20 Oct 2013 21:53:55 -0700 (PDT) Message-ID: <13A3907F5B6D4AB4ACFE91840F131924@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "Yoav Nir" References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> <526141A0.5030206@gmail.com> <3AAB8F2857A0484D9CE7DF44871E7D02@buildpc> <52627368.8090200@gmail.com> <3D85C762-B605-4CA3-A21F-21878B846486@checkpoint.com> <5262A980.10304@gmail.com> Date: Mon, 21 Oct 2013 08:53:52 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response 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, Tero Kivinen Subject: Re: [IPsec] Editorial changes to RFC5996 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, 21 Oct 2013 04:54:00 -0000 HI Yaron, > Hi Yoav, > > You're probably right in your speculation. But my point was that Valery's > subject line said "editorial changes", and two of these changes were > arguably non-editorial. Technical changes would be treated Actually, I don't think #6 is technical, as It doesn't change protocol's behaviour. Current text doesn't specify what to do if SPIs are the same for AH and ESP, and we can leave the behaviour unspecified either. The only difference is that current text is written as if this situation cannot happen, which contradicts RFC4301. We can rewrite is so, that admit that it may happen, but leave to implementers to decide what to do in this case. I think that it is important that RFC4301 and IKEv2 be aligned. What about #8 - it is a minor issue and we can forgo it. Valery. > differently in an errata review and should be treated differently in a > "bis" document, whose main purpose in life is to progress (i.e., > stabilize) the protocol. > > Thanks, > Yaron > > On 2013-10-19 15:27, Yoav Nir wrote: >> Hi, Yaron >> >> Suppose that instead of sending the message to the list yesterday, Valery >> had submitted his comments as errata a few months ago, before Sean asked >> us to do the revision. Would those errata not have been verified? >> >> If so (and I think it's true for at least #3, #4, #7, and #11, and #6 >> would also merit some new text), the corrections would now be in the >> draft. So why not now? >> >> Yoav >> >> On Oct 19, 2013, at 2:56 PM, Yaron Sheffer wrote: >> >>>> Hi Yaron, >>>> >>>>> Hi Valery, >>>>> >>>>> Sorry for being the Bad Guy on this. Your #6 does not seem editorial >>>>> to >>>> >>>> I think that current text is not aligned with RFC4301. >>>> We may leave it as is or try to find other form that >>>> would not appear so misaligned. >>> >>> Your new text is fine, if we leave it at that. If we try to add text to >>> deal with the exceptional cases (same SPI shared between protocols), >>> this will quickly become normative. I don't want to do it in "bis" and >>> frankly, I think this situation is too rare to matter. >>> >>>> >>>>> me. Similarly, #8 (adding new RFC 2119 language) is not editorial. I >>>>> would suggest to implement #6 only if it is critical to >>>>> interoperability or security, and to forgo #8. >>>> >>>> What about #8 - it's just a question from me. From my feeling it must >>>> be uppercase, but I might be wrong. We may leave it as is. >>> >>> IETF process is very serious about the difference between lowercase and >>> uppercase (see RFC 6919). Maybe it should have been a SHOULD to start >>> with. But we SHOULD NOT change it for a "bis" document. >>> >>>> >>>>> By the way, your correction #2 still does not do it IMHO. The sentence >>>>> refers to RFC 5996. So: >>>>> >>>>> "IKEv2 as stated in RFC 4306 was a change to the IKE protocol that was >>>>> not backward compatible. RFC 5996 revised RFC 4306 to provide a >>>>> clarification of IKEv2, making minimum changes to the IKEv2 protocol. >>>>> The current document slightly revises RFC 5996 to make it suitable for >>>>> progression to Internet Standard." >>>> >>>> Yes, your text is for RFC5996bis, while I made my notes a while ago >>>> and the text was for RFC5996. Of course your variant is better. >>>> >>>> Valery. >>>> >>>>> Thanks, >>>>> Yaron >>>>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> From yaronf.ietf@gmail.com Sun Oct 20 23:35:35 2013 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 1240311E84C5 for ; Sun, 20 Oct 2013 23:35:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNUrJ2jk8H9c for ; Sun, 20 Oct 2013 23:35:34 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 577A611E84CE for ; Sun, 20 Oct 2013 23:35:16 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id c13so3295298eek.19 for ; Sun, 20 Oct 2013 23:35:11 -0700 (PDT) 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=SY3LOB8JazCpJqI6PvRapa/64xmQRMqn+iqbDQYMYEc=; b=mVQmOxSJ/YJWbS2uD8deoCT2saSaanDauEskTNAlK/vAi4lkOliBataI4gx+XkBgOS DqY+2nCmdmY+x/vYqptTNJXeTlFt63ZJDArtE3gmfxCL9iHFm2dic2qUDhmUc4LrzXiL KByxqD5BY/GbAiP3eEU7iKWfSKTWdmO8hgiuZwZ9eJVadHl83+40BozmtbgL1X6raeCz LL63isfhBTGwPXeIIOtsojyOyLlcsXmxWtqLNvvuRNbOT4it+yvee1JatSXZDKvnkKgX 0RlmSl+lM2mSZlLP4dov97IHFFEelf1HDF22uu6z/P2hCENnYIgy3dW1fV+ux5G1pn1Q uEBw== X-Received: by 10.14.175.199 with SMTP id z47mr287277eel.130.1382337311682; Sun, 20 Oct 2013 23:35:11 -0700 (PDT) Received: from [192.168.1.129] ([95.35.54.81]) by mx.google.com with ESMTPSA id r48sm39784638eev.14.2013.10.20.23.35.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Oct 2013 23:35:11 -0700 (PDT) Message-ID: <5264CB1D.2050502@gmail.com> Date: Mon, 21 Oct 2013 09:35:09 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Valery Smyslov , Yoav Nir References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> <526141A0.5030206@gmail.com> <3AAB8F2857A0484D9CE7DF44871E7D02@buildpc> <52627368.8090200@gmail.com> <3D85C762-B605-4CA3-A21F-21878B846486@checkpoint.com> <5262A980.10304@gmail.com> <13A3907F5B6D4AB4ACFE91840F131924@buildpc> In-Reply-To: <13A3907F5B6D4AB4ACFE91840F131924@buildpc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Editorial changes to RFC5996 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, 21 Oct 2013 06:35:35 -0000 Hi Valery, I'm OK with this resolution. Thanks, Yaron On 2013-10-21 07:53, Valery Smyslov wrote: > HI Yaron, > >> Hi Yoav, >> >> You're probably right in your speculation. But my point was that >> Valery's subject line said "editorial changes", and two of these >> changes were arguably non-editorial. Technical changes would be treated > > Actually, I don't think #6 is technical, as It doesn't change protocol's > behaviour. > Current text doesn't specify what to do if SPIs are the same for AH and > ESP, > and we can leave the behaviour unspecified either. The only difference > is that current text is written as if this situation cannot happen, which > contradicts RFC4301. We can rewrite is so, that admit that it may > happen, but leave to implementers to decide what to do in this case. > I think that it is important that RFC4301 and IKEv2 be aligned. > > What about #8 - it is a minor issue and we can forgo it. > > Valery. > >> differently in an errata review and should be treated differently in a >> "bis" document, whose main purpose in life is to progress (i.e., >> stabilize) the protocol. >> >> Thanks, >> Yaron >> >> On 2013-10-19 15:27, Yoav Nir wrote: >>> Hi, Yaron >>> >>> Suppose that instead of sending the message to the list yesterday, >>> Valery had submitted his comments as errata a few months ago, before >>> Sean asked us to do the revision. Would those errata not have been >>> verified? >>> >>> If so (and I think it's true for at least #3, #4, #7, and #11, and #6 >>> would also merit some new text), the corrections would now be in the >>> draft. So why not now? >>> >>> Yoav >>> >>> On Oct 19, 2013, at 2:56 PM, Yaron Sheffer >>> wrote: >>> >>>>> Hi Yaron, >>>>> >>>>>> Hi Valery, >>>>>> >>>>>> Sorry for being the Bad Guy on this. Your #6 does not seem >>>>>> editorial to >>>>> >>>>> I think that current text is not aligned with RFC4301. >>>>> We may leave it as is or try to find other form that >>>>> would not appear so misaligned. >>>> >>>> Your new text is fine, if we leave it at that. If we try to add text >>>> to deal with the exceptional cases (same SPI shared between >>>> protocols), this will quickly become normative. I don't want to do >>>> it in "bis" and frankly, I think this situation is too rare to matter. >>>> >>>>> >>>>>> me. Similarly, #8 (adding new RFC 2119 language) is not editorial. I >>>>>> would suggest to implement #6 only if it is critical to >>>>>> interoperability or security, and to forgo #8. >>>>> >>>>> What about #8 - it's just a question from me. From my feeling it must >>>>> be uppercase, but I might be wrong. We may leave it as is. >>>> >>>> IETF process is very serious about the difference between lowercase >>>> and uppercase (see RFC 6919). Maybe it should have been a SHOULD to >>>> start with. But we SHOULD NOT change it for a "bis" document. >>>> >>>>> >>>>>> By the way, your correction #2 still does not do it IMHO. The >>>>>> sentence >>>>>> refers to RFC 5996. So: >>>>>> >>>>>> "IKEv2 as stated in RFC 4306 was a change to the IKE protocol that >>>>>> was >>>>>> not backward compatible. RFC 5996 revised RFC 4306 to provide a >>>>>> clarification of IKEv2, making minimum changes to the IKEv2 protocol. >>>>>> The current document slightly revises RFC 5996 to make it suitable >>>>>> for >>>>>> progression to Internet Standard." >>>>> >>>>> Yes, your text is for RFC5996bis, while I made my notes a while ago >>>>> and the text was for RFC5996. Of course your variant is better. >>>>> >>>>> Valery. >>>>> >>>>>> Thanks, >>>>>> Yaron >>>>>> >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>> > From k.pentikousis@eict.de Mon Oct 21 05:01:26 2013 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 D430D11E84F9; Mon, 21 Oct 2013 05:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srI-osX0dzK2; Mon, 21 Oct 2013 05:01:22 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 978A911E84DD; Mon, 21 Oct 2013 05:01:10 -0700 (PDT) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 551831FF54; Mon, 21 Oct 2013 14:01:09 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 034EA37819D; Mon, 21 Oct 2013 14:01:09 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Mon, 21 Oct 2013 14:01:08 +0200 From: Konstantinos Pentikousis To: "ippm@ietf.org" Date: Mon, 21 Oct 2013 14:01:06 +0200 Thread-Topic: draft-ietf-ippm-ipsec-01 Thread-Index: Ac7OVTk8AzkEO6uuRee1VRb7bH9Vnw== Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10BFCB854@SBS2008.eict.local> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: [IPsec] draft-ietf-ippm-ipsec-01 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, 21 Oct 2013 12:01:27 -0000 Dear all, We have updated the draft on "Network Performance Measurement for IPsec" (h= ttp://datatracker.ietf.org/doc/draft-ietf-ippm-ipsec), and we would like to= hear your comments/suggestions/text contributions as we proceed towards th= e corresponding milestone in December. One of the main items still to be determined by the IPPM WG would be which = optimization to adopt in the end. We're looking forward to the discussion i= n Vancouver and on the mailing list. Best regards, Kostas From lberger@labn.net Mon Oct 21 13:12:35 2013 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 873A311E8669 for ; Mon, 21 Oct 2013 13:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.037 X-Spam-Level: X-Spam-Status: No, score=-102.037 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWdGFv5T-Jve for ; Mon, 21 Oct 2013 13:12:30 -0700 (PDT) Received: from outbound-ss-819.bluehost.com (outbound-ss-819.bluehost.com [69.89.28.53]) by ietfa.amsl.com (Postfix) with SMTP id 5217311E864B for ; Mon, 21 Oct 2013 13:12:27 -0700 (PDT) Received: (qmail 22311 invoked by uid 0); 18 Oct 2013 22:29:05 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy16-pub.mail.unifiedlayer.com with SMTP; 18 Oct 2013 22:29:05 -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=ThPNP0h/xQao89L9gQ3KQVHc1Xl9dMNzERK3+GKJQUg=; b=IfUz7mWMg75V1735oKRZaeu16hHZZs0AqsazAhd4DWlF8/BHffcyjqkXREzcrm8E/EGMqwdp4OVt6ZHzBYhRFBP8Dag8RGIFyrMlaBDgFv1TE2JbsODRBIEsgSTcpoLB; Received: from box313.bluehost.com ([69.89.31.113]:56791 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VXIXZ-0004Jo-PT; Fri, 18 Oct 2013 16:29:05 -0600 Message-ID: <5261B62A.4020209@labn.net> Date: Fri, 18 Oct 2013 18:28:58 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: draft-detienne-dmvpn@tools.ietf.org X-Enigmail-Version: 1.5.2 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: [IPsec] Some comments on draft-detienne-dmvpn-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: Mon, 21 Oct 2013 20:12:35 -0000 Hi, I have the following comments/questions on the draft: - Why allow IPsec tunnel mode? Is there a case where it provides some value? - Do you want to recommend omitting the GRE checksum? - I think the draft should discuss what happens when the best route moves from one spoke to another spoke. Both the cases where the host/prefix is still reachable via the original spoke and when it isn't should be covered. As should avoiding blackholes, and any periods of suboptimal forwarding. - I think the draft is missing a description of how/when NHRP Purges are used, e.g., resulting from interactions with routing. (Yes there is an overlap with the above, but it depends a bit on your solution.) - I the draft should discuss the NHRP scaling considerations that are important in implementation and deployment/operation. (Basically the solution is proposing network wide ARP.) You already have a teaser on this when you mention rate limiting. - NIT/editorial: If section 4 is your "Solution Overview", where is the solution specification? More seriously, I found parts of this section more of a narrative of an example than a protocol specification. - NIT: Assuming the Indirection Notification described in section 4.3 is the same as the NHRP Traffic Indication covered in 5.1, can you align the names and fix the reference in 4.3? Thanks, Lou From touch@isi.edu Mon Oct 21 17:06:52 2013 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 B6FD411E87A7; Mon, 21 Oct 2013 17:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mns1sNJGay2c; Mon, 21 Oct 2013 17:06:47 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1BB11E8771; Mon, 21 Oct 2013 17:06:46 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9M06DeV005272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Oct 2013 17:06:17 -0700 (PDT) Message-ID: <5265C19B.30108@isi.edu> Date: Mon, 21 Oct 2013 17:06:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Martin Stiemerling , ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, "tsv-ads@tools.ietf.org" , tsvwg References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> In-Reply-To: <523CB9CB.7060507@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tsv-dir@ietf.org" Subject: [IPsec] TSVDIR-ish review of draft-ietf-ipsecme-ikev2-fragmentation-04 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, 22 Oct 2013 00:06:53 -0000 Hi, all, I've reviewed the following doc for TSVDIR: draft-ietf-ipsecme-ikev2-fragmentation-04 Although this is not intended as a complete TSVDIR review, I have checked for the typical issues. Joe ------------------------------------------------------------------- draft-ietf-ipsecme-ikev2-fragmentation-04 This doc makes the case that IKEv2 should implement its own frag/reassembly mechanism, because some NATs don't pass IP fragments. First, the issue with NATs and fragments should be made more clear, especially citing existing descriptions of this issue, e.g., RFC4787. Note that NATs which do not pass fragments violate RFQ-14 of that BCP RFC, and it might be useful to report this issue to the vendor. Second, it is not clear why this issue is being handled inside IKE. Appendix A provides a design rationale, but it clearly trades computation and space overhead for local storage, and still permits DOS attacks (e.g., overloading the receiver with false fragments). An equally viable solution (see ** below) would involve placing a single signed IKE message into a single IP packet, fragmenting that packet, and transmitting those fragments inside UDP datagrams. This approach could use the innermost IP encapsulation as the reassembly layer. **: Although this approach is susceptible to fragmentation overload, so too is transmitting the original message over IP that is naturally fragmented at the network layer anyway - this introducing no new vulnerability. This IP-encapsulated IKE message would need the same negotiation described in section 2.3, but would avoid the complexity of most of the rest of the document, relying instead on existing IP reassembly. In conclusion, I don't see the need for the level of detail and mechanism proscribed, basically because it reinvents the wheel, but see no other substantial issues with it. Additionally, regarding PMTUD, this should be done using PLMTUD (RFC 4821), and should be described as such. --- From touch@isi.edu Mon Oct 21 17:26:50 2013 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 7CEF111E82CD; Mon, 21 Oct 2013 17:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.377 X-Spam-Level: X-Spam-Status: No, score=-104.377 tagged_above=-999 required=5 tests=[AWL=-1.778, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+vno1XR6GBs; Mon, 21 Oct 2013 17:26:44 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 888BF11E82C4; Mon, 21 Oct 2013 17:26:32 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9M0QA46010833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Oct 2013 17:26:10 -0700 (PDT) Message-ID: <5265C647.5020908@isi.edu> Date: Mon, 21 Oct 2013 17:26:47 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Martin Stiemerling , ipsec@ietf.org, draft-amjads-ipsecme-ikev2-data-channel@tools.ietf.org, "tsv-ads@tools.ietf.org" , tsvwg References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> In-Reply-To: <5265C19B.30108@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "tsv-dir@ietf.org" Subject: [IPsec] TSVDIR-ish review of draft-amjads-ipsecme-ikev2-data-channel-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: Tue, 22 Oct 2013 00:26:51 -0000 Hi, all, I've reviewed the following doc for TSVDIR: draft-amjads-ipsecme-ikev2-data-channel-00 Although this is not intended as a complete TSVDIR review, I have checked for the typical issues. Joe ------------------------------------------------------------------- draft-amjads-ipsecme-ikev2-data-channel-00 This doc makes the case that IKEv2 can provide a secure data channel for arbitrary communication, rather than being used (as designed) to configure IPsec channels for that purpose. This mechanism lacks congestion control, and so needs to be used only where its load is known to be a small fraction of capacity. In specific, IKE's window mechanism allows for increasing the window size but not decreasing it, as is needed to react to network congestion. The acknowledged data transfer mode uses IKE's window mechanism, which is presumably set to a small value, and may result in very low throughput. Attempts to increase this window size to overcome this limitation can easily increase burstiness and network loss. This mechanism includes its own fragmentation mechanism based on a pre-configiured MTU, where it should use an adaptive size based on PLMTUD (RFC4821). The mechanism described replicates that of IP, and so introduces no new issues. Fragment reassembly appears to rely on the IKE sequence number, and the relationship between the two should be more clear, especially on the reuse of the IKE sequence number and how that affects reassembly timeout. --- From svanru@gmail.com Mon Oct 21 22:50:29 2013 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 9FDCA11E8140 for ; Mon, 21 Oct 2013 22:50:29 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8rW8T8ayR42 for ; Mon, 21 Oct 2013 22:50:29 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id DC77611E8115 for ; Mon, 21 Oct 2013 22:50:28 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id o14so2086606lbi.14 for ; Mon, 21 Oct 2013 22:50:28 -0700 (PDT) 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; bh=di8c+y0u+7nurx3jNXwe8qhlWTeUmaw5hoevpEjChZ0=; b=G2QUWhfYcsCt/qyqf4sCcOCUGuNgRi7eayIjI2eKDoOOwjOBtGYgm7RUjHHZgHNs4Q BmLk4YI+uLfZCCHd/LHWLDsvjymT8WsAiHZQM52XeFS3YT65/ulHP80bXUws4MCbPCbZ 62YIN39dnCmXEPRAzCqR9wowpozse71+R7lxQcwiv8gFsZaPT+xizmMSLIpdMsOpser5 i5gtB8/yIu9LDq/Jc1AF/AR9Y13r0O3vJL5GBoMrAYc+BHPbn9wNwg+8WMlCfpgU6rPL WESwJICxBDoYy9iJpgHf5wr2YJ9SzmKljbTbo+XQBNXkdr8HjZsaIbHUCB6xCF61HanZ 3FCg== X-Received: by 10.152.120.73 with SMTP id la9mr16469631lab.3.1382421027933; Mon, 21 Oct 2013 22:50:27 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id m13sm14573842lbo.11.2013.10.21.22.50.26 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 21 Oct 2013 22:50:27 -0700 (PDT) Message-ID: <2FA74E8177C2445E82D929E4857FA377@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> <7C1EFED8998C4309B562F2224DD39AA2@buildpc> Date: Tue, 22 Oct 2013 09:50:24 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response 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: [IPsec] One more editorial issue in RFC5996 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, 22 Oct 2013 05:50:29 -0000 Hi, Just came across one more small editorial issue in RFC5996. Page 73, description of "Next Payload" field, sentence In the header of an Encrypted payload, the Next Payload field is set to the payload type of the first contained payload (instead of 0); conversely, the Next Payload field of the last contained payload is set to zero). has extra round bracket at the end. Regards, Valery. From svanru@gmail.com Tue Oct 22 05:51:05 2013 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 92A1911E819F; Tue, 22 Oct 2013 05:51:05 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnpuOcSw5Tc1; Tue, 22 Oct 2013 05:51:04 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD9911E838F; Tue, 22 Oct 2013 05:51:00 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id u14so3601339lbd.36 for ; Tue, 22 Oct 2013 05:50:59 -0700 (PDT) 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; bh=5u3TNbhTmQENnl6oJV+UPDmywtTqX6VY4vtmmQPkAaI=; b=RYMSL55EI2br11ZX2e/q4RDahBkJ14M2rGycu6uyRCLCzQBSVJmEw2Xm0q9pbSP6xQ cYiMxnTVf9UFsii5QtIL/EXTTKqSfZHCSV7d4h0Ew2ssWGBu6XgdtSWuX2+RTazzGKLn FhQVWafmv9G9tU/KwtIz8c8qkc5d0gPs7I45jZyvSje3abPO1v752YXzM6XoOVZmy9HH IvUWdz4SCHkkH/Hj5IjwlfjV//AGC6T8ADfmBSwVmgxMQWRGXlbS9ekc5lJeXnkUBv4o Ezi8t9y5vuKKcsZwS08tWVaJ43vBZ6cK9Dk4WbQIzVH6Rx+5TrCKLU5ISJZa5gQQhEFi IXgg== X-Received: by 10.152.235.40 with SMTP id uj8mr1647796lac.39.1382446259216; Tue, 22 Oct 2013 05:50:59 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id kx1sm20944084lac.7.2013.10.22.05.50.57 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Oct 2013 05:50:58 -0700 (PDT) Message-ID: <14DB3765679C45D283869DC9010F0084@buildpc> From: "Valery Smyslov" To: "Joe Touch" , "Martin Stiemerling" , , , , "tsvwg" References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> Date: Tue, 22 Oct 2013 16:50:57 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response 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: tsv-dir@ietf.org Subject: Re: [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 22 Oct 2013 12:51:05 -0000 Hi Joe, thank you for your review. Please, see my comments inline. > Hi, all, > > I've reviewed the following doc for TSVDIR: > draft-ietf-ipsecme-ikev2-fragmentation-04 > > Although this is not intended as a complete TSVDIR review, I have checked > for the typical issues. > > Joe > > ------------------------------------------------------------------- > > draft-ietf-ipsecme-ikev2-fragmentation-04 > > This doc makes the case that IKEv2 should implement its own > frag/reassembly mechanism, because some NATs don't pass IP fragments. > > First, the issue with NATs and fragments should be made more clear, > especially citing existing descriptions of this issue, e.g., RFC4787. Note > that NATs which do not pass fragments violate RFQ-14 of that BCP RFC, and > it might be useful to report this issue to the vendor. > > Second, it is not clear why this issue is being handled inside IKE. > Appendix A provides a design rationale, but it clearly trades computation > and space overhead for local storage, and still permits DOS I don't see a strict computation/memory tradeoff here. You must verify message validity in any case, whether it is done before reassempling (on each fragment), or after it is complete (including the case when you get garbage message due to false fragments). The amount of consumped CPU power will be roughly the same. But the amount of memory consumption will be smaller if you are able to discard false fragments. > attacks (e.g., overloading the receiver with false fragments). This attack is always possible both with and without fragmentation (just overloading with false full messages) and IKE is designed to withstand it. Handling fragmentation in IKE doesn't make it more vulnerable to this attack. On the other hand, handling fragmentation outside IKE (on IP level) or using unauthenticated fragments in IKE, makes it susceptible to an attack, described in the rationale, i.e. when attacker spending virtually zero resources can stop IKE communication by infrequently injecting bad fragments, which results in "poisoning" of reassembling queue. Using authenticated fragments prevents this kind of attack. > An equally viable solution (see ** below) would involve placing a single > signed IKE message into a single IP packet, fragmenting that packet, and > transmitting those fragments inside UDP datagrams. This approach could use > the innermost IP encapsulation as the reassembly layer. > > **: Although this approach is susceptible to fragmentation overload, so > too is transmitting the original message over IP that is naturally > fragmented at the network layer anyway - this introducing no new > vulnerability. But using IKE fragmentation in this case might eliminate this vulnerability. > This IP-encapsulated IKE message would need the same negotiation described > in section 2.3, but would avoid the complexity of most of the rest of the > document, relying instead on existing IP reassembly. > > In conclusion, I don't see the need for the level of detail and mechanism > proscribed, basically because it reinvents the wheel, but see no other > substantial issues with it. > > Additionally, regarding PMTUD, this should be done using PLMTUD (RFC > 4821), and should be described as such. IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based and RFC4821 has many restrictions when used with connectionless datagram protocols, some of which are often difficult to satisfy in environments, where IKE is used. Second, the goal of PLMTUD is to find _maximum_ MTU size that is not fragmented by IP, in other words, to maximize throughput. For IKE the goal of PMTUD is to find _any_reasonable_ MTU size that won't be fragmented by IP. Throughput is not important. Third, PMTU discovery in the draft is completely optional and one may use any other mechanisms (including PLMTUD, if it is available) to obtain MTU information. Thanks, Valery Smyslov. From svanru@gmail.com Tue Oct 22 06:28:56 2013 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 5AAD711E837C for ; Tue, 22 Oct 2013 06:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVVUPsNq6voG for ; Tue, 22 Oct 2013 06:28:55 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0A011E8397 for ; Tue, 22 Oct 2013 06:28:52 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id ea20so2814564lab.1 for ; Tue, 22 Oct 2013 06:28:51 -0700 (PDT) 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; bh=DljEeWMqbPnh0JjlCk8BOtBgQuxUmcB0+5zr+XzwGRQ=; b=ZIBqZx26xwLuROOGisr63R/ohGBqGQvFrJO/VWDHGKqyehp5eUnzKddNVyXCNldvHS 7veLuMHpMGAsrorCHZwslVQ1pHy64r2nqZjtEro5W57UXyC6VtDZ3aG73PULLhSeFbEo nxqXsgarpf6qV7xDUauRQUL0oYN54VI31+A4zssLUbWoZ4Cbu4WB+GxvSqbpPj7f2fJ8 olif5mjCQ/aCmDMUjmYScQl/+LB45qTb3wV2Sm8DwE+xgYzbCQUwik5Kre7vsZSZh9vb UKVe3xyT2bwzhTJnHDetGk4ANK6ILwS0nqJz/NCaIQMdm5uR02NECqKWCEGATBSctJx3 8nhg== X-Received: by 10.112.57.49 with SMTP id f17mr16889979lbq.26.1382448531558; Tue, 22 Oct 2013 06:28:51 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id n15sm21042474laa.2.2013.10.22.06.28.50 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 22 Oct 2013 06:28:50 -0700 (PDT) Message-ID: <6BCB4096B17543149D30813732C89DAF@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , References: <21089.9829.183841.778540@fireball.kivinen.iki.fi> Date: Tue, 22 Oct 2013 17:28:50 +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] FWD from Cao Zhen \(CZ\): [Lwip] WGLC for I-Ddraft-ietf-lwig-ikev2-minimal-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: Tue, 22 Oct 2013 13:28:56 -0000 HI Tero, one editorial error, copied from RFC5996: on Page 22, in the description of Next Payload, the sentence In the header of an Encrypted payload, the Next Payload field is set to the payload type of the first contained payload (instead of 0); conversely, the Next Payload field of the last contained payload is set to zero). has extra round bracket at the end. Regards, Valery Smyslov. ----- Original Message ----- From: "Tero Kivinen" To: Sent: Friday, October 18, 2013 4:15 PM Subject: [IPsec] FWD from Cao Zhen \(CZ\): [Lwip] WGLC for I-Ddraft-ietf-lwig-ikev2-minimal-01.txt > My draft-ietf-lwig-ikev2-minimal-01.txt is starting WGLC in the lwig > WG, and as this is most likely interesting for people also in the > ipsecme wg you might want to go and read the document. The comments > and discussion about the draft should most likely be on the lwig > mailing list (lwip@ietf.org). > > -------------------------------------------------------------------------------- > > -- > kivinen@iki.fi > -------------------------------------------------------------------------------- > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From touch@isi.edu Tue Oct 22 08:28:14 2013 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 9A7AB11E83FA; Tue, 22 Oct 2013 08:28:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLKZTa0ieD4h; Tue, 22 Oct 2013 08:28:08 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id BDF5311E84C1; Tue, 22 Oct 2013 08:28:08 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9MFRQrG018461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 22 Oct 2013 08:27:39 -0700 (PDT) Message-ID: <52669960.1000706@isi.edu> Date: Tue, 22 Oct 2013 08:27:28 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Valery Smyslov References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> In-Reply-To: <14DB3765679C45D283869DC9010F0084@buildpc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg , tsv-ads@tools.ietf.org, Martin Stiemerling , ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 22 Oct 2013 15:28:14 -0000 Hi, Valery, On 10/22/2013 5:50 AM, Valery Smyslov wrote: > Hi Joe, > > thank you for your review. > Please, see my comments inline. > >> Hi, all, >> >> I've reviewed the following doc for TSVDIR: >> draft-ietf-ipsecme-ikev2-fragmentation-04 >> >> Although this is not intended as a complete TSVDIR review, I have >> checked for the typical issues. >> >> Joe >> >> ------------------------------------------------------------------- >> >> draft-ietf-ipsecme-ikev2-fragmentation-04 >> >> This doc makes the case that IKEv2 should implement its own >> frag/reassembly mechanism, because some NATs don't pass IP fragments. >> >> First, the issue with NATs and fragments should be made more clear, >> especially citing existing descriptions of this issue, e.g., RFC4787. >> Note that NATs which do not pass fragments violate RFQ-14 of that BCP >> RFC, and it might be useful to report this issue to the vendor. >> >> Second, it is not clear why this issue is being handled inside IKE. >> Appendix A provides a design rationale, but it clearly trades >> computation and space overhead for local storage, and still permits DOS > > I don't see a strict computation/memory tradeoff here. You must > verify message validity in any case, whether it is done before > reassempling (on each fragment), or after it is complete (including > the case when you get garbage message due to false fragments). > The amount of consumped CPU power will be roughly the same. The cost to verify several individual messages is higher than the cost to verify a single message, especially when the individual messages are not exactly the blocksize of the algorithm used. So in the case of no attack, the overhead of your proposed mechanism is higher. You can't drop an entire message when a single false fragment arrives, because there could be other valid fragments on the way. So either way you end up checking the same amount of data, but your computational overhead is higher. > But the amount of memory consumption will be smaller if > you are able to discard false fragments. Yes, but you also need to keep some state about pending partial valid messages. AFAICT, the memory difference is more likely to be negligible, but the processing difference high. >> attacks (e.g., overloading the receiver with false fragments). > > This attack is always possible both with and without fragmentation > (just overloading with false full messages) and IKE is designed to > withstand it. > Handling fragmentation in IKE doesn't make it more vulnerable to this > attack. > On the other hand, handling fragmentation outside IKE (on IP level) > or using unauthenticated fragments in IKE, makes it susceptible to an > attack, > described in the rationale, i.e. when attacker spending virtually zero > resources > can stop IKE communication by infrequently injecting bad fragments, > which results in "poisoning" of reassembling queue. Using authenticated > fragments > prevents this kind of attack. Avoiding fragmentation poisoning attacks is not a motivation of this work. If you want to make that case, you need to explain why you think that is a significant issue and worth the effort to fix inside IKE. Further, this method does not necessarily avoid IP fragmentation. Fragments are supposed to pass through a NAT (see my previous reference), and when they do your mechanism wouldn't adjust the IKE size downward. >> An equally viable solution (see ** below) would involve placing a >> single signed IKE message into a single IP packet, fragmenting that >> packet, and transmitting those fragments inside UDP datagrams. This >> approach could use the innermost IP encapsulation as the reassembly >> layer. >> >> **: Although this approach is susceptible to fragmentation overload, >> so too is transmitting the original message over IP that is naturally >> fragmented at the network layer anyway - this introducing no new >> vulnerability. > > But using IKE fragmentation in this case might eliminate this > vulnerability. It might, but again that's not your threat model and there are other vulnerabilities this method opens up (e.g., replay attacks have a higher CPU impact). >> This IP-encapsulated IKE message would need the same negotiation >> described in section 2.3, but would avoid the complexity of most of >> the rest of the document, relying instead on existing IP reassembly. >> >> In conclusion, I don't see the need for the level of detail and >> mechanism proscribed, basically because it reinvents the wheel, but >> see no other substantial issues with it. >> >> Additionally, regarding PMTUD, this should be done using PLMTUD (RFC >> 4821), and should be described as such. > > IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based > and RFC4821 has many restrictions when used with connectionless > datagram protocols, some of which are often difficult to satisfy in > environments, > where IKE is used. You are re-inventing PLMUTD. In places where you claim RFC4821 is too complex - those are the places where your mechanism is deficient IMO. E.g., positive verification that a message gets through as a confirmation of when you've achieved a reasonable size. > Second, the goal of PLMTUD is to find _maximum_ > MTU size that is not fragmented by IP, in other words, to maximize > throughput. For IKE the goal of PMTUD is to find _any_reasonable_ > MTU size that won't be fragmented by IP. Throughput is not important. Agreed, but if that's the case, why not always send the smallest possible message size (68 bytes)? It's because the overhead is too high (additional headers, blocksize mismatch, and computational startup cost on each block). Further, most transports don't care about 1400 vs. 1500 bytes; they're searching for a rough approximation of a 'large' packet, as are you IMO. > Third, PMTU discovery in the draft is completely optional and one may > use any other mechanisms (including PLMTUD, if it is available) > to obtain MTU information. The transport folks spent a lot of time on PLMTUD; there are a lot of lessons there that can and should be applied here. PLMTUD is already flexible enough to apply here directly. You can always reinvent the wheel, of course. Joe From paul@cypherpunks.ca Tue Oct 22 08:35:49 2013 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 E36F511E84B4; Tue, 22 Oct 2013 08:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bqtc2bs5mNzH; Tue, 22 Oct 2013 08:35:44 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 231E811E84A4; Tue, 22 Oct 2013 08:35:43 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d3zLY13Wvz1Kk; Tue, 22 Oct 2013 11:35:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id rhuLavDercs3; Tue, 22 Oct 2013 11:35:15 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 22 Oct 2013 11:35:14 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 5A147807CA; Tue, 22 Oct 2013 11:35:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4E0D3805BD; Tue, 22 Oct 2013 11:35:13 -0400 (EDT) Date: Tue, 22 Oct 2013 11:35:13 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Valery Smyslov In-Reply-To: <14DB3765679C45D283869DC9010F0084@buildpc> Message-ID: References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "ipsec@ietf.org WG" , tsv-ads@tools.ietf.org, tsvwg Subject: Re: [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 22 Oct 2013 15:35:50 -0000 On Tue, 22 Oct 2013, Valery Smyslov wrote: >> attacks (e.g., overloading the receiver with false fragments). > > This attack is always possible both with and without fragmentation > (just overloading with false full messages) and IKE is designed to withstand > it. Partially. For unfragmented IKE, the cookies/SPI mitigate this if you give preference to IKE messages further in the processing queue. With this draft, I'm forced to do more crypto on IKE packets before I can decide if these need prioritization or not (with the exception of the first packet, which cannot get fragmented anyway) > Handling fragmentation in IKE doesn't make it more vulnerable to this attack. Handling encrypted fragments does, because you will spend more time doing the crypto. Although this still happens after the cookie/spi verification. You are doing an additional round of crypto on each fragment in addition to the regular IKE crypto you need to perform on the assembled packet. Fragments could be made artificially long and the IKE packet artificial big, resulting in much more crypto. Now I think this might not matter much, because the attacker needs to be local and they will only be local to a remote endpoint which has enough CPU, not the ipsec core gateway that actually might run out of CPU power when under attack. > On the other hand, handling fragmentation outside IKE (on IP level) > or using unauthenticated fragments in IKE, makes it susceptible to an attack, > described in the rationale, i.e. when attacker spending virtually zero > resources > can stop IKE communication by infrequently injecting bad fragments, > which results in "poisoning" of reassembling queue. But the attack is theoretical and of no practical value. 1) on-path attacker (remote) They can just DOS you regardless by withholding packets. 2) off-path attacker (remote) These attackers don't know the cookies/spi's so they can't really sent a forged fragment you would use for assembly - protected with crypto or not. It is also impossible for them to time their attack so that one of their fragments intersect with one of your fragments so they would need to start sending fragments before the endpoint does but using mostly wrong cookies/spis and would swamp an endpoint with easilly detectable forged packets. 3) shared medium like wifi hotspot (local) These are the only attackers with enough knowledge to sent sufficiently advanced bad fragments interfering with incoming fragments. They can already do all the damage they want without resorting to IKE fragment spoofing. They can arp spoof the gateway, sent a Wifi de-association request, sent enough garbage to fill the air waves, and interfere with the IKE in such a way that you think the remote peer does not support fragmentation at all. So this draft protects against a local attacker that wants to masquerade as a network failure and only prevent you from doing IKE, hoping you will fall back to plaintext traffic. Software could notify the user that they seem to be under attack, which IMHO would be more valuable to the user than quiet resilience against the attack. > Using authenticated fragments prevents this kind of attack. Yes, it prevents one of the low hanging fruits. Which I don't think is worth the complexity of this draft compared to the existing fragmentation code out in the wild. > But using IKE fragmentation in this case might eliminate this vulnerability. At the price of adding more complexity to IKE. With the attacker not stopped from their goal. >> Additionally, regarding PMTUD, this should be done using PLMTUD (RFC 4821), >> and should be described as such. > > IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based > and RFC4821 has many restrictions when used with connectionless > datagram protocols, some of which are often difficult to satisfy in > environments, > where IKE is used. Second, the goal of PLMTUD is to find _maximum_ > MTU size that is not fragmented by IP, in other words, to maximize > throughput. For IKE the goal of PMTUD is to find _any_reasonable_ > MTU size that won't be fragmented by IP. Throughput is not important. > Third, PMTU discovery in the draft is completely optional and one may > use any other mechanisms (including PLMTUD, if it is available) > to obtain MTU information. I agree. There is going to be like 2 to 4 fragments. Size does not matter. It's better to cut down on latency/RTT by using an MTU size that is for sure to work on the first go. But that's also why this complexity is not worth it. Fragmentation does only mean going from 1 IKE packet to 2-4 IKE packets. The timeframe to mess with these are in the 5ms range. If an attacker has that accuracy against you, you've lost already regardless. I doubt the attacker can even pull it off on wifi. The original IKE fragmentation is really nice and simple. Copy part of the original IKE header, add a single payload with fragment payload type and fragment number/max, sent fragments in a burst. This draft looks like it is fixing a security issue, while it really should be just about sending smaller packets as similar as possible to the original single packet. Messing with one IKE packet versus 2-4 IKE packets is not a real problem that I think needs fixing. Paul From svanru@gmail.com Wed Oct 23 00:14:12 2013 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 42CAF11E812D; Wed, 23 Oct 2013 00:14:12 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gyqr4-hSFwlO; Wed, 23 Oct 2013 00:14:11 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5B50611E816D; Wed, 23 Oct 2013 00:14:09 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ec20so304234lab.9 for ; Wed, 23 Oct 2013 00:14:08 -0700 (PDT) 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; bh=QA+KzCD/rmkpQYo0Z6+OA/gQTFD8iAf6+VKbe6AQ3Fk=; b=UWOxDwUF6G/+3l251qnDZ4vLpQOtdxGejn3ePBsGcNZU+l4v+quqrvRAmpF2gi2sDu LZZYoWI2OYzcABAqXkVbkWkI6ko2JrIpZckbolrvqtwauO6eQ5z7X3UnwZqURjsjOUKg u3XUvoCrOxPJL8YykYX2PAGjQeIvRMvvWy74cX1n3zmR22RCIqbGA73TLVmcJoYu5OcG ycJyoYF4F4VCFktS+VhH6IShiF78DIjFTX89D2F7f6Agi/KnaUJo6OsZwIFERwcKTAi7 G6xejYqU8VLCmIpP2M+gb3g7nnMxtXFcq6VV0uWFqirffUDBAM8WVaWvGXon2oKZIEgp epxw== X-Received: by 10.152.120.73 with SMTP id la9mr81648lab.3.1382512448410; Wed, 23 Oct 2013 00:14:08 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id w10sm18355045lbv.6.2013.10.23.00.14.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 23 Oct 2013 00:14:07 -0700 (PDT) Message-ID: <4CB00D77A6544077B506AF5522843BCD@buildpc> From: "Valery Smyslov" To: "Paul Wouters" References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> Date: Wed, 23 Oct 2013 11:14:08 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response 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, tsv-ads@tools.ietf.org, tsvwg Subject: Re: [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 23 Oct 2013 07:14:12 -0000 Hi Paul, >>> attacks (e.g., overloading the receiver with false fragments). >> >> This attack is always possible both with and without fragmentation >> (just overloading with false full messages) and IKE is designed to >> withstand it. > > Partially. For unfragmented IKE, the cookies/SPI mitigate this if > you give preference to IKE messages further in the processing queue. > With this draft, I'm forced to do more crypto on IKE packets before I > can decide if these need prioritization or not (with the exception of > the first packet, which cannot get fragmented anyway) The SPIs are still there and you are supposed to check them before you will do any crypto. What is the difference? >> Handling fragmentation in IKE doesn't make it more vulnerable to this >> attack. > > Handling encrypted fragments does, because you will spend more time > doing the crypto. Although this still happens after the cookie/spi > verification. You are doing an additional round of crypto on each fragment > in addition to the regular IKE crypto you need to perform on the assembled > packet. Fragments could be made artificially long and the IKE packet > artificial big, resulting in much more crypto. Now I think this might No, there is no additional round of crypto. After you has verified and decrypted fragment you will store it in decrypted form. After reassembly has finished you will get decrypted message. No more crypto to apply. > not matter much, because the attacker needs to be local and they will > only be local to a remote endpoint which has enough CPU, not the ipsec > core gateway that actually might run out of CPU power when under attack. > >> On the other hand, handling fragmentation outside IKE (on IP level) >> or using unauthenticated fragments in IKE, makes it susceptible to an >> attack, >> described in the rationale, i.e. when attacker spending virtually zero >> resources >> can stop IKE communication by infrequently injecting bad fragments, >> which results in "poisoning" of reassembling queue. > > But the attack is theoretical and of no practical value. I am not so confident. > 1) on-path attacker (remote) > > They can just DOS you regardless by withholding packets. There may be cases when attacker, even on-path, could only eavesdrop and inject packets, but not to block them. > 2) off-path attacker (remote) > > These attackers don't know the cookies/spi's so they can't really sent > a forged fragment you would use for assembly - protected with crypto or > not. It is also impossible for them to time their attack so that one of > their fragments intersect with one of your fragments so they would need > to start sending fragments before the endpoint does but using mostly > wrong cookies/spis and would swamp an endpoint with easilly detectable > forged packets. Again, I am not so confident that it is impossible, especially for particular implementation. Remember, that TCP ISN was also considered impossible to predict untill we saw a successfull attack on particular implementation of TCP. > 3) shared medium like wifi hotspot (local) > > These are the only attackers with enough knowledge to sent sufficiently > advanced bad fragments interfering with incoming fragments. They can > already do all the damage they want without resorting to IKE fragment > spoofing. They can arp spoof the gateway, sent a Wifi de-association > request, sent enough garbage to fill the air waves, and interfere with > the IKE in such a way that you think the remote peer does not support > fragmentation at all. So this draft protects against a local attacker > that wants to masquerade as a network failure and only prevent you from > doing IKE, hoping you will fall back to plaintext traffic. Software > could notify the user that they seem to be under attack, which IMHO > would be more valuable to the user than quiet resilience against the > attack. Sorry, I don't follow your logic here. Security software should thwart the attacks as much, as it could, and not just notify user that he is under attack and give up. DoS attacks are difficult to thwart and sometimes are easy to perform. So what is the reason not to thwart one kind of them? I agree that others are still possible, but they may have their own drawback for attacker and why should we give him/her more options to choose from? >> Using authenticated fragments prevents this kind of attack. > > Yes, it prevents one of the low hanging fruits. Which I don't think is > worth the complexity of this draft compared to the existing > fragmentation code out in the wild. Is it really _much_ complex if you first fragment then encrypt compared to first encrypt then fragment? >> But using IKE fragmentation in this case might eliminate this >> vulnerability. > > At the price of adding more complexity to IKE. With the attacker not > stopped from their goal. See above. >>> Additionally, regarding PMTUD, this should be done using PLMTUD (RFC >>> 4821), and should be described as such. >> >> IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based >> and RFC4821 has many restrictions when used with connectionless >> datagram protocols, some of which are often difficult to satisfy in >> environments, >> where IKE is used. Second, the goal of PLMTUD is to find _maximum_ >> MTU size that is not fragmented by IP, in other words, to maximize >> throughput. For IKE the goal of PMTUD is to find _any_reasonable_ >> MTU size that won't be fragmented by IP. Throughput is not important. >> Third, PMTU discovery in the draft is completely optional and one may >> use any other mechanisms (including PLMTUD, if it is available) >> to obtain MTU information. > > I agree. There is going to be like 2 to 4 fragments. Size does not > matter. It's better to cut down on latency/RTT by using an MTU size > that is for sure to work on the first go. > > But that's also why this complexity is not worth it. Fragmentation does > only mean going from 1 IKE packet to 2-4 IKE packets. The timeframe > to mess with these are in the 5ms range. If an attacker has that > accuracy against you, you've lost already regardless. I doubt the > attacker can even pull it off on wifi. > > The original IKE fragmentation is really nice and simple. Copy part of > the original IKE header, add a single payload with fragment payload > type and fragment number/max, sent fragments in a burst. Not much difference from the draft - just move fragmentation before encryption. > This draft looks like it is fixing a security issue, while it really > should be just about sending smaller packets as similar as possible > to the original single packet. Messing with one IKE packet versus 2-4 > IKE packets is not a real problem that I think needs fixing. It is about sending smaller packets, but doing so in a secure manner. > Paul Regards, Valery. From k.pentikousis@eict.de Wed Oct 23 02:08:46 2013 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 DE52621F84D0; Wed, 23 Oct 2013 02:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wU98IJwHUTg; Wed, 23 Oct 2013 02:08:41 -0700 (PDT) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 013AB11E8162; Wed, 23 Oct 2013 02:08:36 -0700 (PDT) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 22BD11FF58; Wed, 23 Oct 2013 11:08:35 +0200 (CEST) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id 93AEB37819D; Wed, 23 Oct 2013 11:08:34 +0200 (CEST) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Wed, 23 Oct 2013 11:08:34 +0200 From: Konstantinos Pentikousis To: John Mattsson Date: Wed, 23 Oct 2013 11:08:32 +0200 Thread-Topic: [ippm] draft-ietf-ippm-ipsec-01 review Thread-Index: Ac7PmlUqX2JIOakDT/CgxsRdf+tOogAM82Jw Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEA10BFCB993@SBS2008.eict.local> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "ippm@ietf.org" Subject: Re: [IPsec] [ippm] draft-ietf-ippm-ipsec-01 review 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, 23 Oct 2013 09:08:46 -0000 Hi John, all, | I reviewed draft-ietf-ippm-ipsec-01, I think the issue is important, | and I think the document is a good start. I do however have some the | doubts regarding the suggested solution to extract keying material from | IPsec. |=20 | Here are my comments and suggestions. |=20 | Best Regards | John Many thanks for the review! We really appreciate it, as it also opens up th= e discussion ahead of the meeting in Vancouver. I'm adding in CC the ipsecm= e WG, as experts in that list may want to voice their opinion as well. @ippm: Please note that the core of John's review is on the ipsec part. We = still need to get going on the discussion about the O/TWAMP protocol aspect= s (e.g. Server Greeting and backwards compatibility, Modes, optimizations a= nd so on) @ipsecme: John's full review is available at http://www.ietf.org/mail-archi= ve/web/ippm/current/msg03231.html Best regards, Kostas From svanru@gmail.com Wed Oct 23 06:38:27 2013 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 45E6911E8369 for ; Wed, 23 Oct 2013 06:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpThPJ3IGnvX for ; Wed, 23 Oct 2013 06:38:26 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id 844A111E83A2 for ; Wed, 23 Oct 2013 06:38:21 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id u14so737188lbd.36 for ; Wed, 23 Oct 2013 06:38:20 -0700 (PDT) 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; bh=xbXr6KQejwl/GIzVLH4Hb/U2kJSeqzv/piv+L7BZjEY=; b=e/MiiV2EuRzWIdttXeUCvu9WeUUPjJhVYELdEtT7wFtLJG2yibFCUVy5kNtsq5eKma BCn+/ZHb1cRdagOBwnv8izsgW7tpSvBeXDV/l/NfQm1Y2z4RQL+W/4H5llAup7PxLrr5 iUHvECAqtsnVEA7vrcKkbknEgYE/0VbmPs+/ffjdM89c5ltIXELAlJmkZC0w+crewvcR qH1Rytfw594qBF7UrTUraBjTgKctfcllIuBzYRqG4UJnHEFCFtiLekhz1Fd4trRasQSU ugdR0g/Sw4pZqD8AVMHgNI8sPb2hIIM8GEnHPeJghgso+J83tNZIDBmySiwaZw6HJB63 zhVg== X-Received: by 10.112.51.227 with SMTP id n3mr473469lbo.54.1382535500585; Wed, 23 Oct 2013 06:38:20 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id sc4sm1031660lab.10.2013.10.23.06.38.18 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 23 Oct 2013 06:38:19 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Rajeshwar Singh Jenwar \(rsj\)" , References: <20130915114752.25560.4833.idtracker@ietfa.amsl.com> Date: Wed, 23 Oct 2013 17:38:22 +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: [IPsec] Some comments concerning draft-amjads-ipsecme-ikev2-data-channel-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: Wed, 23 Oct 2013 13:38:27 -0000 Hi, I have some comments concerning the draft. 1. As far as I understand, only one data channel can be created within one IKE SA. So, if application needs several different channels, it have to create several separate IKE SAs, performing authentication several times (probably involving human activity, if EAP is used). This is makes the whole architecture not so lightweight. 2. Nothing is said abouth channel deletion. I presume it exists untill IKE SA is deleted, right? 3. Could this IKE SA be used for other purposes, for example to create Child SAs as usual, or it must be explicitely dedicated to IKE Data channel? 4. In Section 8.1 in description of Protocol ID: according to RFC5996 this field MUST be zero if SPI Size field is zero. Regards, Valery Smyslov. From svan@elvis.ru Tue Oct 22 23:26:28 2013 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 1D15411E82E6; Tue, 22 Oct 2013 23:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.814 X-Spam-Level: X-Spam-Status: No, score=-0.814 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCpwwmUVXeIl; Tue, 22 Oct 2013 23:26:21 -0700 (PDT) Received: from bull.elvis.ru (bull.elvis.ru [93.188.44.194]) by ietfa.amsl.com (Postfix) with ESMTP id D19B311E816F; Tue, 22 Oct 2013 23:25:59 -0700 (PDT) Received: from robin.office.elvis.ru ([10.111.1.40]) by bull.elvis.ru with esmtp (Exim 4.76) (envelope-from ) id 1VYrsh-0002DV-3v; Wed, 23 Oct 2013 10:25:23 +0400 Received: from buildpc (10.111.10.31) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.1.438.0; Wed, 23 Oct 2013 10:25:54 +0400 Message-ID: From: Valery Smyslov To: Joe Touch References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> Date: Wed, 23 Oct 2013 10:25:56 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response 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 X-Mailman-Approved-At: Wed, 23 Oct 2013 08:11:57 -0700 Cc: tsvwg , tsv-ads@tools.ietf.org, Martin Stiemerling , ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 23 Oct 2013 06:26:28 -0000 >>> This doc makes the case that IKEv2 should implement its own >>> frag/reassembly mechanism, because some NATs don't pass IP fragments. >>> >>> First, the issue with NATs and fragments should be made more clear, >>> especially citing existing descriptions of this issue, e.g., RFC4787. >>> Note that NATs which do not pass fragments violate RFQ-14 of that BCP >>> RFC, and it might be useful to report this issue to the vendor. >>> >>> Second, it is not clear why this issue is being handled inside IKE. >>> Appendix A provides a design rationale, but it clearly trades >>> computation and space overhead for local storage, and still permits DOS >> >> I don't see a strict computation/memory tradeoff here. You must >> verify message validity in any case, whether it is done before >> reassempling (on each fragment), or after it is complete (including >> the case when you get garbage message due to false fragments). >> The amount of consumped CPU power will be roughly the same. > > The cost to verify several individual messages is higher than the cost to > verify a single message, especially when the individual messages are not > exactly the blocksize of the algorithm used. Right. That's why I wrote "_roughly_ the same". Of course there is some overhead, not only due to blocksize, but mainly due to the inclusion of IKE Header into ICV calculations for each fragment message. > So in the case of no attack, the overhead of your proposed mechanism is > higher. You can't drop an entire message when a single false fragment > arrives, because there could be other valid fragments on the way. So > either way you end up checking the same amount of data, but your > computational overhead is higher. Yes, it is higher, but the amount of the overhead could be estimated about 10%. If some system cannot bear this overhead, I think it is broken. >> But the amount of memory consumption will be smaller if >> you are able to discard false fragments. > > Yes, but you also need to keep some state about pending partial valid > messages. Right. But only after fragment is validated. > AFAICT, the memory difference is more likely to be negligible, but the > processing difference high. No. In solution you have proposed (relying on IP fragmentation inside UDP datagrams) the attacker could send you millions of packets, all with different IP Fragmentation IDs in inner packet. As you has no way to know which Fragmentation ID is valid (from real peer) you will need to try to reassemble all of them, consuming as much memory, as attacker wishes. If attacker is smart enough, s(he) could easy make so, that all the false fragments will eventually be reassembled by your system (into garbage), and you will also consume the CPU power trying to validate them. In this case you will consume roughly the same CPU power as with authenticated fragments, but the amount of your memory consumption will be under attacker's control. >>> attacks (e.g., overloading the receiver with false fragments). >> >> This attack is always possible both with and without fragmentation >> (just overloading with false full messages) and IKE is designed to >> withstand it. >> Handling fragmentation in IKE doesn't make it more vulnerable to this >> attack. >> On the other hand, handling fragmentation outside IKE (on IP level) >> or using unauthenticated fragments in IKE, makes it susceptible to an >> attack, >> described in the rationale, i.e. when attacker spending virtually zero >> resources >> can stop IKE communication by infrequently injecting bad fragments, >> which results in "poisoning" of reassembling queue. Using authenticated >> fragments >> prevents this kind of attack. > > Avoiding fragmentation poisoning attacks is not a motivation of this work. > If you want to make that case, you need to explain why you think that is a > significant issue and worth the effort to fix inside IKE. Actually, Security Consideration Section of RFC5996 has already stated that IP fragmentation is a significant issue for IKE: If the messages of IKEv2 are long enough that IP-level fragmentation is necessary, it is possible that attackers could prevent the exchange from completing by exhausting the reassembly buffers. RFC5996 advices to avoid IP fragmentation by using Hash and URL format for certificates. For some reasons, this is not widely supported by implementations and is not generic solution (some systems transfer a fair amount of data in Configuration Payloads, in which case Hash and URL won't help). The immediate goal of IKE Fragmentation was to deal with devices, that block IP fragments. But the solution is all in line with RFC5996, advicing avoid IP fragmentation whenever possible. > Further, this method does not necessarily avoid IP fragmentation. > Fragments are supposed to pass through a NAT (see my previous reference), > and when they do your mechanism wouldn't adjust the IKE size downward. It doesn't matter. If IP fragmentation works in some environment - it is ok. If it doesn't (either because some intermediate devices block IP fragments or because an attacker is trying to exploit it), then peers detect it and start using IKE Fragmentation. >>> An equally viable solution (see ** below) would involve placing a >>> single signed IKE message into a single IP packet, fragmenting that >>> packet, and transmitting those fragments inside UDP datagrams. This >>> approach could use the innermost IP encapsulation as the reassembly >>> layer. >>> >>> **: Although this approach is susceptible to fragmentation overload, >>> so too is transmitting the original message over IP that is naturally >>> fragmented at the network layer anyway - this introducing no new >>> vulnerability. >> >> But using IKE fragmentation in this case might eliminate this >> vulnerability. > > It might, but again that's not your threat model and there are other > vulnerabilities this method opens up (e.g., replay attacks have a higher > CPU impact). Why? Are you reffering to the fact, that with IKE Fragmentation you need to check 4 additional bytes to detect a replay? Is it really a CPU impact? >>> This IP-encapsulated IKE message would need the same negotiation >>> described in section 2.3, but would avoid the complexity of most of >>> the rest of the document, relying instead on existing IP reassembly. >>> >>> In conclusion, I don't see the need for the level of detail and >>> mechanism proscribed, basically because it reinvents the wheel, but >>> see no other substantial issues with it. >>> >>> Additionally, regarding PMTUD, this should be done using PLMTUD (RFC >>> 4821), and should be described as such. >> >> IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based >> and RFC4821 has many restrictions when used with connectionless >> datagram protocols, some of which are often difficult to satisfy in >> environments, >> where IKE is used. > > You are re-inventing PLMUTD. In places where you claim RFC4821 is too > complex - those are the places where your mechanism is deficient IMO. > E.g., positive verification that a message gets through as a confirmation > of when you've achieved a reasonable size. It is sufficient for IKE. >> Second, the goal of PLMTUD is to find _maximum_ >> MTU size that is not fragmented by IP, in other words, to maximize >> throughput. For IKE the goal of PMTUD is to find _any_reasonable_ >> MTU size that won't be fragmented by IP. Throughput is not important. > > Agreed, but if that's the case, why not always send the smallest possible > message size (68 bytes)? It's because the overhead is too high (additional > headers, blocksize mismatch, and computational startup cost on each > block). Further, most transports don't care about 1400 vs. 1500 bytes; > they're searching for a rough approximation of a 'large' packet, as are > you IMO. I think, the main difference is that PLMTUD is always trying to increase MTU size when everything works fine, while in IKE PMTUD is supposed to decrease it only if packets don't get through. For IKE the former is just not needed. >> Third, PMTU discovery in the draft is completely optional and one may >> use any other mechanisms (including PLMTUD, if it is available) >> to obtain MTU information. > > The transport folks spent a lot of time on PLMTUD; there are a lot of > lessons there that can and should be applied here. PLMTUD is already > flexible enough to apply here directly. You can always reinvent the wheel, > of course. I appreciate the work transport folks has done. I will also appreciate if you point out what exact lessons should be applied here and why. And you may consider PMTUD in IKE as simplified PLMTUD, implemented according with Section 10.4 of RFC4821. > Joe Regards, Valery. From yaronf.ietf@gmail.com Wed Oct 23 10:20:34 2013 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 C025E11E8479 for ; Wed, 23 Oct 2013 10:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P7W-07lHB-T for ; Wed, 23 Oct 2013 10:20:34 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD9411E81E4 for ; Wed, 23 Oct 2013 10:20:33 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id r16so609652ead.3 for ; Wed, 23 Oct 2013 10:20:32 -0700 (PDT) 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=IDrxDCds4apMhr3QKR6pqHLvo6ZhvVzVeg56iky8sSs=; b=hglv7aGTC5Lo2cc28pyfkfAXLxSeepUnuSsx0A3mB6lQ6FKTyqZ69pY4BWZoW573l2 VcZPB0KGU7GjXULe5UGI/yv7quJtS9p+FOqBFD7RHYoTSQdGTIiq7bFnf70RqL3t8sNX 7ZT28nea5W4/Tau7/Xr6OrNa3MUCe5oFbHp4pz0k05Q9uDq00W+9LekeWPc5bifnWAXa Aw9QD3ZnflQ2xbYcAu6ZpYzvUVbi17eY/CQCrsG56csxNxhHDKoIejqQ7HojGn0Al9Qx TFD7UZMSv0EbX+zILKkwmeVx7RK42kEcEW3NCBs7e/NccCLuhYRyf1BqYfzFwM3IjByY nnhA== X-Received: by 10.14.2.2 with SMTP id 2mr1521422eee.92.1382548832720; Wed, 23 Oct 2013 10:20:32 -0700 (PDT) Received: from [10.0.0.8] (46-116-149-62.bb.netvision.net.il. [46.116.149.62]) by mx.google.com with ESMTPSA id m54sm72588689eex.2.2013.10.23.10.20.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 10:20:32 -0700 (PDT) Message-ID: <5268055E.4000804@gmail.com> Date: Wed, 23 Oct 2013 20:20:30 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Working Group Last Call: draft-kivinen-ipsecme-signature-auth-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: Wed, 23 Oct 2013 17:20:34 -0000 Hi, this is to start a 3-week working group last call on the IKE Signature Authentication document, ending Nov. 13. The draft is at: http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-02. The document is a product of a design team that was started for this purpose, but should now be treated like any WG document. Please read this draft and send any comments to the WG mailing list, even if the comments are "I see no problems". Comments such as "I do not understand this part" or "this part could be explained better in this way" are particularly useful at this point. Thanks, Paul and Yaron From yaronf.ietf@gmail.com Wed Oct 23 10:20:45 2013 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 A61F711E8487 for ; Wed, 23 Oct 2013 10:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Falxxyot1ql for ; Wed, 23 Oct 2013 10:20:45 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D424011E846D for ; Wed, 23 Oct 2013 10:20:42 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id b45so716345eek.1 for ; Wed, 23 Oct 2013 10:20:42 -0700 (PDT) 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=K2ShdtgcVuqNeRJaKbQerk6jXzmMR9ai+KmtHajJYqM=; b=KOjbrY1f2eDg7FYUDSXKg3corQErukRv2KjcmD8ulY3yRq/pziOjO4u9Zj9zvY1BUr S4tuKdHaxaoY45+jg9KfwuAK1SYDYV2FXb8lEhcDFzQ4qTS28Is5ZRViZTuWyjksYbly +X5d+RiWMaumsJGYpKLC92JnUP5TvIhRSjxnVZelWB/6CWh/MnVIQLdN8Fw5EwymASZY EDzApXCaEhrYTubI9Td8k+UqOOeV4cjUwinq51IVgUBLiWUMBqrmmOJ7YSYATkqFXFTN P124K+T2lg3u8TpQaiwemK/qdWg8T7bTd69Z+lRUzIJAoxuwSNEFepXnKYjm4a6RDx7U /nrA== X-Received: by 10.14.178.67 with SMTP id e43mr2939603eem.59.1382548842188; Wed, 23 Oct 2013 10:20:42 -0700 (PDT) Received: from [10.0.0.8] (46-116-149-62.bb.netvision.net.il. [46.116.149.62]) by mx.google.com with ESMTPSA id u46sm72527062eep.17.2013.10.23.10.20.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 10:20:41 -0700 (PDT) Message-ID: <52680567.2080204@gmail.com> Date: Wed, 23 Oct 2013 20:20:39 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Working Group Last Call: draft-kivinen-ipsecme-ikev2-rfc5996bis-01 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, 23 Oct 2013 17:20:45 -0000 Hi, this is to start a 3-week working group last call on the IKEv2-bis (or -bis-bis) document, ending Nov. 13. The draft is at: http://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-rfc5996bis. The main motivation behind the draft is to progress IKEv2 from Proposed Standard to Internet Standard based on its broad industry adoption, and with a minimal number of changes. See RFC 6410 for the process details. We are planning to progress a couple other of our foundational RFCs in the near future. Please read this draft and send any comments to the WG mailing list, even if the comments are "I see no problems". Comments such as "I do not understand this part" or "this part could be explained better in this way" are particularly useful at this point. Please pay special attention to differences from RFC 5996, as listed in Sec. 1.8. Thanks, Paul and Yaron From touch@isi.edu Wed Oct 23 10:23:42 2013 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 6C84A11E81E4; Wed, 23 Oct 2013 10:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.054 X-Spam-Level: X-Spam-Status: No, score=-104.054 tagged_above=-999 required=5 tests=[AWL=-1.455, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY+Wdry19jgu; Wed, 23 Oct 2013 10:23:36 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A178611E81B3; Wed, 23 Oct 2013 10:23:36 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9NHMbCx023189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 23 Oct 2013 10:22:44 -0700 (PDT) Message-ID: <5268060B.4060604@isi.edu> Date: Wed, 23 Oct 2013 10:23:23 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Valery Smyslov References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg , tsv-ads@tools.ietf.org, Martin Stiemerling , ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 23 Oct 2013 17:23:42 -0000 On 10/22/2013 11:25 PM, Valery Smyslov wrote: > I appreciate the work transport folks has done. I will also appreciate > if you point out what exact lessons should be applied here and why. > And you may consider PMTUD in IKE as simplified PLMTUD, > implemented according with Section 10.4 of RFC4821. From the second sentence of that section: Because you never generate distinct probes, finding out when the MTU fails is tied to timeouts in your message exchange system, rather than being decoupled. From Section 9: You don't talk about trying to make sure that IPv4 DF is set, as per Section 9, which means that even the conservative values you pick might continue to generate fragments downstream. Finally, and this is separate from RFC4821, you don't mention the fact that dropping fragments is against the recommended behavior for NATs. I appreciate trying to get around that issue, but it's equally important to indicate this as a flaw of the network, rather than "just the way it is". Joe From paul.hoffman@vpnc.org Wed Oct 23 11:50:29 2013 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 E535311E8190 for ; Wed, 23 Oct 2013 11:50:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLup7B94cHP4 for ; Wed, 23 Oct 2013 11:50:29 -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 7AFC911E8152 for ; Wed, 23 Oct 2013 11:50:28 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r9NIoQ4J011210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 23 Oct 2013 11:50:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8DEB5081-AC73-43DA-A8E3-70638ED3E28A@vpnc.org> Date: Wed, 23 Oct 2013 11:50:25 -0700 To: "ipsec@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) X-Mailer: Apple Mail (2.1816) Subject: [IPsec] Agenda for Vancouver 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, 23 Oct 2013 18:50:30 -0000 Below is the proposed agenda; please let Yaron and I know if there are = any requested changes. --Paul Hoffman IPsecME WG agenda IETF 88, Vancouver Monday, November 4. 2013 WG staus report and update on open WG Last Calls Chairs - 15 mins Handing Over Child SAs Following Re-Authentication in IKEv2 = (draft-nir-ipsecme-cafr) Yoav Nir - 15 mins Auto Discovery VPN Protocol (draft-mao-ipsecme-ad-vpn-protocol) Vishwas Manral - 30 mins Comparison of AD VPN proposoals to other proposals Each author team - 20 mins each Other WG topics (if approved by chairs) From mls@cisco.com Wed Oct 23 11:54:21 2013 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 09CD611E81B8 for ; Wed, 23 Oct 2013 11:54:21 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tsLio68i1KG for ; Wed, 23 Oct 2013 11:54:15 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2C011E8156 for ; Wed, 23 Oct 2013 11:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4985; q=dns/txt; s=iport; t=1382554449; x=1383764049; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5+5kaNR9Ra/O1ge4wGMak4l/+H+0qIPOAz9skqpueOE=; b=VysHm42lHBKNWOaYwihf3N6HCLsGCl94nBUnyg3oAZDy/U2HSZ3ioGBY SBOXK/YMT4GJMDRHV1Q83AKCAQhcDz+R2jHf9fnxW40VUvq8yKCFHTelj ByXKQtyjieVQ3cqC3WVd3+zOkWgrvyts6IqwTxUlrvPeheXXrtzPbjdQM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFACYaaFKtJV2Y/2dsb2JhbABZgweBDL5XgS4WdIIlAQEBAwF5DAQCAQgOAwQBAQsdBzIUCQgCBA4FCBOHZQa7No8dMQcGgxmBCwOJB6EJgySCKg X-IronPort-AV: E=Sophos;i="4.93,555,1378857600"; d="scan'208";a="275782965" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 23 Oct 2013 18:54:06 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9NIs6N4030377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 18:54:06 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.176]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 13:54:06 -0500 From: "Mike Sullenberger (mls)" To: Lou Berger Thread-Topic: Some comments on draft-detienne-dmvpn-00 Thread-Index: AQHOzpni81p/PXN/mUSc2YFRqxy7R5oCmuAw Date: Wed, 23 Oct 2013 18:54:05 +0000 Message-ID: <9D83DE546CB6DC47A3AE04086FDE35F523FADE2D@xmb-aln-x06.cisco.com> References: <5261B62A.4020209@labn.net> In-Reply-To: <5261B62A.4020209@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.253.185] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , "draft-detienne-dmvpn@tools.ietf.org" Subject: Re: [IPsec] Some comments on draft-detienne-dmvpn-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: Wed, 23 Oct 2013 18:54:21 -0000 Lou, Thank you for your comments, more inline. Mike. Mike Sullenberger, DSE mls@cisco.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 .:|:.:|:. Customer Advocacy=A0=A0=A0=A0=A0=A0=A0=A0=A0 CISCO > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, October 18, 2013 3:29 PM > To: draft-detienne-dmvpn@tools.ietf.org > Cc: IPsecme WG > Subject: Some comments on draft-detienne-dmvpn-00 >=20 > Hi, > I have the following comments/questions on the draft: >=20 > - Why allow IPsec tunnel mode? Is there a case where it provides some val= ue? [Mike Sullenberger]=20 You are correct that IPsec tunnel mode is not really needed and transport m= ode is far recommended and preferred. There are a couple of rare situations= where tunnel-mode could help, like when separating the GRE/NHRP tunneling = and IPsec encryption onto separate nodes, these cases are not recommended, = but we thought we should leave in the possibility.=20 =20 > - Do you want to recommend omitting the GRE checksum? [Mike Sullenberger]=20 Good idea, we definitely don't use the GRE checksum, and I don't think it p= rovides any value so we should recommend omitting it. I think this is also= the case for most of the other optional GRE header attributes. Though, th= e GRE Tunnel Key must be allowed, handled and provided. > - I think the draft should discuss what happens when the best route moves > from one spoke to another spoke. Both the cases where the host/prefix is > still reachable via the original spoke and when it isn't should be covere= d. As > should avoiding blackholes, and any periods of suboptimal forwarding. [Mike Sullenberger]=20 We can add some more discussion around this point. The main feature here i= s that this is handled by the routing protocol that is running over the DMV= PN tunnels. The routing protocol will redirect the data packets via differe= nt tunnels and/or spokes as the routing is updated. Note, if static routing= is used then you lose this capability. > - I think the draft is missing a description of how/when NHRP Purges are > used, e.g., resulting from interactions with routing. (Yes there is an ov= erlap > with the above, but it depends a bit on your solution.) [Mike Sullenberger]=20 As you have noted, NHRP purges are used to keep the distributed NHRP databa= se in sync. If a local node loses access to a destination that it has prev= iously replied with itself as the egress point in an NHRP mapping (and the = entry hasn't timed out yet) then it will generate an NHRP purge and send a = copy to each requester (recorded when it sent the original reply). This wi= ll then clear out these now invalid mapping entries on the remote nodes and= trigger them to find an alternate path if available. Note, this is basic= ally what is described in NHRP (RFC2332), we didn't really want to duplicat= e this in this RFC, but it could be added. > - I the draft should discuss the NHRP scaling considerations that are > important in implementation and deployment/operation. (Basically the > solution is proposing network wide ARP.) You already have a teaser on th= is > when you mention rate limiting. [Mike Sullenberger]=20 We can certainly do so. In DMVPN deployments we haven't really found that = NHRP scaling has been an issue. Usually we ran into either Routing protoco= l or IPsec scaling issues first. It is correct we do mention a couple of = places about rate limiting triggering or sending of NHRP messages, mainly b= ecause it wasn't felt that it was useful to continue to "bother" another no= de if it was working on the previous request, which was the same as the one= to be sent again. Note, we do have mechanisms for retransmission and back= -off of messages. Again some of this is covered in the NHRP RFC.=20 > - NIT/editorial: If section 4 is your "Solution Overview", where is the > solution specification? More seriously, I found parts of this section mo= re of > a narrative of an example than a protocol specification. [Mike Sullenberger]=20 Yes, I think this needs to be cleaned up. Since a lot of what we do with = NHRP is covered in the NHRP RFC we didn't want to duplicate too much here, = but we can certainly make a more clear solution specification. I think the= solution overview section is also useful since, a walk through can help pe= ople to understand how the solution is intended to work. Many times I find = it hard with just solution specifications to get a real feel for how things= go together. > - NIT: Assuming the Indirection Notification described in section 4.3 is = the > same as the NHRP Traffic Indication covered in 5.1, can you align the nam= es > and fix the reference in 4.3? [Mike Sullenberger]=20 Yes, thanks for noting this. We tend to use those terms interchangeably, b= ut we should be more consistent here. >=20 > Thanks, > Lou From yaronf.ietf@gmail.com Wed Oct 23 13:58:41 2013 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 3C88611E81F8 for ; Wed, 23 Oct 2013 13:58:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSUWpCG9JwQu for ; Wed, 23 Oct 2013 13:58:40 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD5A21F9CAD for ; Wed, 23 Oct 2013 13:58:40 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id q58so1444501wes.28 for ; Wed, 23 Oct 2013 13:58:39 -0700 (PDT) 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=EfiVxr5xSCIkvcHVysaFlhZidsuJPG+CBZO/8QPslLY=; b=ugBBODqGGqQcQOl/CLbDNnQ5PRy6QumWrNVPSsamtr/P5dp7bAVr8Kxh9bKMYFsJD7 Y7wFfDfC5jmci9f0ptVGsx8LezKrFSUwNiqw2as7Or6qXedcb1wRG++w5awzcSMqi3qj f1LY3Z4GY+vs19dPH2avj74UmzB7t5ePm1I5Vjw/MevXKJnyFflL+VEi2UvYNXlQZ0tW XiSfRHLnmtBldUOPXdl2J+ttfh/u4hg0WiEfiWZJ8ThulK6cRDP7UKU3Cmq/lHAkANGo KeyL9zf8/dvzIitdw9iwAyZx0JtEgiUj637U+A9RxtW/M7bY7IgS7menkAO10buxx5Cy g12A== X-Received: by 10.180.36.242 with SMTP id t18mr3174744wij.28.1382561919308; Wed, 23 Oct 2013 13:58:39 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-177-145-22.red.bezeqint.net. [79.177.145.22]) by mx.google.com with ESMTPSA id ev4sm20390015wib.7.2013.10.23.13.58.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 13:58:38 -0700 (PDT) Message-ID: <5268387A.1060509@gmail.com> Date: Wed, 23 Oct 2013 23:58:34 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.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: discussion kick off 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, 23 Oct 2013 20:58:41 -0000 Hi everyone, We spent a lot of time understanding the requirements from autodiscovery VPN solutions, and we have 3 serious proposals on the table. We have had in-depth presentations of two of them (http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03.txt and http://tools.ietf.org/html/draft-detienne-dmvpn-00 respectively) in Berlin and the last interim meeting. We will have the third in-depth presentation (of http://tools.ietf.org/html/draft-mao-ipsecme-ad-vpn-protocol-02.txt) in Vancouver. It is now time to start the selection process, so that we end up adopting one proposal into the working group, and developing it together into an RFC with WG consensus. We will not make the final selection in Vancouver, but we would like to use the time before, during and after the meeting to advance this process. With that in mind, we would like to request each author team to present 3-5 bullet points explaining why their solution is preferable compared to the alternatives. Please send your comparison to the list so we can start a serious discussion before the meeting and make the best use of our face time. Needless to say, please keep the discussion civil and to the point, even when comparing your perfect solution with the other obviously inferior kludges :-) Thanks, Paul and Yaron From svanru@gmail.com Wed Oct 23 23:42:56 2013 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 37A5111E8109; Wed, 23 Oct 2013 23:42:56 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abRt2a7XgaYB; Wed, 23 Oct 2013 23:42:55 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A825221E8090; Wed, 23 Oct 2013 23:42:48 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id el20so1521496lab.16 for ; Wed, 23 Oct 2013 23:42:47 -0700 (PDT) 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; bh=h5v/JY+TyOY81HtEiKM3CifNhY3ZV/tMYUX+rCiW8dI=; b=JVBi3VJj4xmy5qTzVetSWxscgwY60/ugwK3Wi1w/VfCr2T9KWdwSZk6UwX2ghSiXFI pG3xF1qj0RIgpM7UucZcBwL3UzU4YLaWnuGFuwJbT8gtssNL7B/iNFHL63v83hAiFo7L 6ZKZjBU7vkjzheDXw4f6aL7n+XRqkkBWbfHVCfYYHfeKVNaNzEXcxFdEEzwpaOuFMTvZ 44R3wDCaLdGsOdumxOhnCpuORH0HzqK8WiGBdESh7vgCYYHXeYR8yoV4rfjORSH+igph Au95VGYBRRhonUn0rjeygFCmjy5G3Vf/eEcXnutgL7ZuYkgy7i1tAA0mWDd3CpTOkALL hwTw== X-Received: by 10.152.29.38 with SMTP id g6mr785962lah.25.1382596967419; Wed, 23 Oct 2013 23:42:47 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id ao4sm124957lac.1.2013.10.23.23.42.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 23 Oct 2013 23:42:46 -0700 (PDT) Message-ID: <81953CE6126542A8AD40207921B8E018@buildpc> From: "Valery Smyslov" To: "Joe Touch" References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> Date: Thu, 24 Oct 2013 10:42:50 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response 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: tsvwg , tsv-ads@tools.ietf.org, Martin Stiemerling , ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 24 Oct 2013 06:42:56 -0000 Hi Joe, thank you for your suggestions. I still have some comments. > On 10/22/2013 11:25 PM, Valery Smyslov wrote: >> I appreciate the work transport folks has done. I will also appreciate >> if you point out what exact lessons should be applied here and why. >> And you may consider PMTUD in IKE as simplified PLMTUD, >> implemented according with Section 10.4 of RFC4821. > > From the second sentence of that section: Because you never generate > distinct probes, finding out when the MTU fails is tied to timeouts in > your message exchange system, rather than being decoupled. That's true. I don't see any requirements in section 10.4. that the probes must be distinct. Request/reply nature of IKE's messages make them well suitable for probes and I see no need here to introduce separate mechanism, adding complexity, consuming bandwith and adding delay. Moreover, section 10.4 explicitely allows using application data for probes. > From Section 9: You don't talk about trying to make sure that IPv4 DF is > set, as per Section 9, which means that even the conservative values you > pick might continue to generate fragments downstream. With all due respect, I have to disagree that setting DF bit is needed in case of IKE. With IKE the goal is not to make sure that _no_ IP fragmentation takes place on the path, but to make sure that IP fragmentation issues, if any, do not prevent IKE communications. So, IP fragmentation is present on the path, but it doesn't bother us - let it be. If it doesn't allow IKE to work (either by dropping IP fragments or by attacking destination host with bogus fragments) - we will try to avoid it. So, in your example, even if IP fragments are generated downstream, but those fragments are passed - let them be. Note, that this approach is in line with advices, given for IKE in the paper C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection for UDP-based protocols", ACM Conference on Computer and Communications Security, October 2003. that is reffered by RFC5996 as recommendations to protect against IP fragmentation issues. Section 3.3 of this paper discusses the ways PMTUD should be done in IKE and finds it more advantageous not to set DF bit. > Finally, and this is separate from RFC4821, you don't mention the fact > that dropping fragments is against the recommended behavior for NATs. I > appreciate trying to get around that issue, but it's equally important to > indicate this as a flaw of the network, rather than "just the way it is". That's true and I will definitely add some words about it. > Joe Thank you, Valery Smyslov. From svanru@gmail.com Thu Oct 24 05:39:19 2013 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 C804511E832F for ; Thu, 24 Oct 2013 05:39:19 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqo++yuvX0HN for ; Thu, 24 Oct 2013 05:39:19 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id A408F11E830C for ; Thu, 24 Oct 2013 05:39:10 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id w6so215149lbh.41 for ; Thu, 24 Oct 2013 05:39:09 -0700 (PDT) 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; bh=qXwHi2DGmeSCCWxuUOHUyN5EvGRwBCJm86PpLvQca7E=; b=R3BHOS/luDZyxe2JKSxZBzIMkcZlx+Z1/080U0QfUg+lO7t/H+pl73Cvo2PRYXhqDd QQjvvb9tbyImWhA7M8U+PjgeREsrWwG2E17d4NgU5G9UY+muXdOrxUGfI3RgMUL8GD4p Moj5lG+ekgPf7sOO6WShok5Ixl5ldzAUKRpdu+m6DfoPrlpn/QpGJyvpa0JwwD5pIjbC WkAXzsThSlDOGrwXIbRCauuw5d7OYoqsUisF7jDFa9FP0464PIKdz7RxcogPVzflnX69 i7mwcQLy4xFy/bDdXymURg9uRs0posqNgguBciKj7eJTY+vJnIJnH8CllLhEIskSELr+ JlTQ== X-Received: by 10.152.20.74 with SMTP id l10mr1134067lae.46.1382618349679; Thu, 24 Oct 2013 05:39:09 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id ao4sm1438303lac.1.2013.10.24.05.39.08 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Oct 2013 05:39:08 -0700 (PDT) Message-ID: <876DF97CB1AF4CA7B96634DDE3D51B1B@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "IPsecme WG" References: <5268055E.4000804@gmail.com> Date: Thu, 24 Oct 2013 16:39:18 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response 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] Working Group Last Call:draft-kivinen-ipsecme-signature-auth-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: Thu, 24 Oct 2013 12:39:19 -0000 Hi all, first, I think that the draft is very important for interoperability. But I also think, that in its current form it is insufficient in some situations and could have been made better. The problem, that the draft is not solving, is the situation, when one of the peers has more than one private key, each for different signature algorithm. This may happen if in deployed VPN there is a need to move from one signature alg to another (for any reason, for example when old algorithm is found to be broken or obsoleted by authorities). As the transition cannot be done at once, there will be a period when some of the hosts will have only a single key, while the others will have more than one. In general, host with multiple keys cannot decide which of them to use with different peers, so there is a possibility, that IKE will fail, when it could have completed. CERTREQ payloads may help in some cases, but not in all (single CA may issue both certificates signed with one trusted root) and they are optional anyway. The solution to the problem would be if host be able to explicitely indicate, which signature algorithms it supports. Currently draft includes ability to indicate to the peer which hash algorithms it supports. I suggest to change this as following. Instead of adding IKE registry, listing hash algorithms, add registry listing combinations of hash&signature algorithms, as listed in Appendix A. So, the registry would look like: RESERVED 0 sha1WithRSAEncryption 1 sha256WithRSAEncryption 2 sha384WithRSAEncryption 3 sha512WithRSAEncryption 4 dsa-with-sha1 5 dsa-with-sha256 6 ecdsa-with-sha1 7 ecdsa-with-sha256 8 ecdsa-with-sha384 9 ecdsa-with-sha512 10 RSASSA-PSS-default 11 And to include values from this registry into SIGNATURE_HASH_ALGORITHMS notification. This will allow peer indicate not only hash alg, but the particular pairs signature-hash which it supports. Regards, Valery Smyslov. P.S. One small typo in the draft. in Appendix A last sentence of first para: "These values are taken form the New ASN.1 Modules..." s/form/from > Hi, this is to start a 3-week working group last call on the IKE > Signature Authentication document, ending Nov. 13. > > The draft is at: > http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-02. > The > document is a product of a design team that was started for this > purpose, but should now be treated like any WG document. > > Please read this draft and send any comments to the WG mailing list, > even if the comments are "I see no problems". Comments such as "I do not > understand this part" or "this part could be explained better in this > way" are particularly useful at this point. > > Thanks, > Paul and Yaron From ynir@checkpoint.com Thu Oct 24 07:09:44 2013 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 CCD8011E819B for ; Thu, 24 Oct 2013 07:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.446 X-Spam-Level: X-Spam-Status: No, score=-10.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hjv0l0wlHPdc for ; Thu, 24 Oct 2013 07:09:25 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 87D3611E8315 for ; Thu, 24 Oct 2013 07:09:07 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9OE963t028594 for ; Thu, 24 Oct 2013 17:09:06 +0300 X-CheckPoint: {52692958-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Thu, 24 Oct 2013 17:08:50 +0300 From: Yoav Nir To: IPsecme WG Thread-Topic: [IPsec] AD VPN: discussion kick off Thread-Index: AQHO0DKq3uGh8NKKjkSYLkYxqARjppoDsoAA Date: Thu, 24 Oct 2013 14:08:47 +0000 Message-ID: <62A56E6A-DFE4-4775-9D1E-9E720562BA94@checkpoint.com> References: <5268387A.1060509@gmail.com> In-Reply-To: <5268387A.1060509@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.46] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <5A471F0BA27E724197F913ABDCB26C83@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] AD VPN: discussion kick off 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, 24 Oct 2013 14:09:44 -0000 Hi I think one of the most striking things is how similar all three mechanisms= are. They all begin with a node doing what the DMVPN guys call a "hairpin" - it = decrypts packets from one peer, then re-encrypts them and sends them to ano= ther peer. In all three proposals, the node doing the hairpin notices this inefficienc= y, and informs one or both of the peers. In all three proposals, the peers learn of each other, and open a direct tu= nnel.=20 The semantics are practically identical, so the difference is only in the m= echanism.=20 In our proposal (draft-sathyanarayan), it is the hairpin node that does the= introduction, which takes place at the same time as the notification. In draft-mao there is an omniscient server known as ADS that the peers ask = for tunnel information In DMVPN the peer runs a discovery process using NHRP over a GRE tunnel. Our proposal in an IKE extension draft-mao defines a new UDP-based protocol DMVPN (draft-detienne) uses NHRP over a GRE tunnel As a document, I think ours has the advantage of being more complete. Both = DMVPN and the other ADVPN gloss over authentication, identities and authori= zation. Mike pretty much said it in the conf call: any gateway that has a v= alid certificate will connect, and will be trusted. There might be some rou= ting protocol security, but that is outside scope, and anything based on RP= KI is unlikely in corporate networks. Those are, however, gaps that can be = filled. Whichever proposal gets chosen is only a starting point, and the WG= can decide to tightly profile the authentication and authorization in any = proposal, as well as augment any of the protocols with identities and crede= ntials. Our advantages are: - fewer packets, because notification, introduction and credential provisio= ning are all done in one round-trip. - Less complexity, as it's all in an IKE extension (compared with the new p= rotocol of ADVPN2 and the whole GRE+NHRP+routing protocol implementation of= DMVPN) - Works with IPsec tunnels (no need for an extra GRE tunnel) - Requires no new components which can be points of failure (like an ADS) - Scalability. Consider 10,000 remote access clients - Mike said you could do that with GRE. The fact is that Cisco's clients= use IPsec tunnels or L2TP, neither requires a virtual interface on the gat= eway. Running GRE and routing protocols to the clients is not done, and pro= bably for a good reason. I've also been told that having a large number of = neighbors is a problem for routing protocols (although I'm no expert on tho= se) - ADS is an obvious potential bottleneck. Loss of state there can be dev= astating - how would it recover the data? OTOH we have the ability to keep= servers running without losing state. It costs money, but servers can work= reliably and scalably. Just look at the Facebook web servers :-) Our disadvantages: - Shortcuts work a single hop at a time. If the path through the VPN is lon= ger, we may set up some useless SAs. - Not tested in the field Yoav From kivinen@iki.fi Thu Oct 24 08:42:31 2013 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 A786311E81E2 for ; Thu, 24 Oct 2013 08:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZCWRvavk-BD for ; Thu, 24 Oct 2013 08:42:11 -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 52CAE11E829B for ; Thu, 24 Oct 2013 08:40:50 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9OFeb5Y023712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Oct 2013 18:40:37 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9OFebmj016380; Thu, 24 Oct 2013 18:40:37 +0300 (EEST) 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: <21097.16245.405563.467088@fireball.kivinen.iki.fi> Date: Thu, 24 Oct 2013 18:40:37 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <876DF97CB1AF4CA7B96634DDE3D51B1B@buildpc> References: <5268055E.4000804@gmail.com> <876DF97CB1AF4CA7B96634DDE3D51B1B@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 21 min X-Total-Time: 21 min Cc: IPsecme WG Subject: Re: [IPsec] Working Group Last Call:draft-kivinen-ipsecme-signature-auth-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: Thu, 24 Oct 2013 15:42:31 -0000 Valery Smyslov writes: > The problem, that the draft is not solving, is the situation, > when one of the peers has more than one private key, each > for different signature algorithm. This may happen if in deployed > VPN there is a need to move from one signature alg > to another (for any reason, for example when old algorithm > is found to be broken or obsoleted by authorities). As the > transition cannot be done at once, there will be a period when > some of the hosts will have only a single key, while the others > will have more than one. In general, host with multiple keys > cannot decide which of them to use with different peers, > so there is a possibility, that IKE will fail, when it could have > completed. CERTREQ payloads may help in some cases, > but not in all (single CA may issue both certificates signed > with one trusted root) and they are optional anyway. Lets take example where someone thinks that RSA keys are not strong enough anymore, and should be replaced with ECDSA keys. They also have old implementation which only support RSA, and then they have newer implementation which support both. To do the change, they need to provide newer implementations a ECDSA certificates and keys, but also keep the old RSA keys around, as those are needed to talk to the old implementations. Also note, as they do consider RSA keys too weak to be used, they would also need to change the signature algorithms on their certificates. This would mean they would need to get new CA or sub CA key with ECDSA keys to sign those new ECDSA certificates. So when the old device talks to new device, it will send CERTREQ to the old RSA CA, and because the new implementation only has RSA certificate for that older RSA CA, it will automatically pick RSA key and use that. Everything works automatically. The new device knows both ECDSA and RSA so it can always verify what the old device sends. Things work automatically there too. CERTREQ payloads may be optional, but so is support for this. If you want to support changing from one CA infrastructure to another you need to support CERTREQ payloads. Changing the underlaying key used in the IPsec is useless unless you also change it in the certificate infrastructure too. The real problem is that with Raw Public keys you do not have this option, as CERTREQ payloads are not useful there (their contents are empty). But on the other hand RFC5996bis does not have Raw public keys anymore :-) And you can always retry when you notice that you get authentication error after using private key, provided you have multiple types of keys. Anyways, I do not really consider this as serious problem in the real world. In most of the cases the certificate hierarchy needs to be changed anyways at the same time when changing authentication keys, and then you get this negotiation automatically. On those situations this does not work, then you can always manually configure the devices to use specific keys, or try both keys. > I suggest to change this as following. Instead of > adding IKE registry, listing hash algorithms, > add registry listing combinations of hash&signature > algorithms, as listed in Appendix A. > So, the registry would look like: > > RESERVED 0 > sha1WithRSAEncryption 1 > sha256WithRSAEncryption 2 > sha384WithRSAEncryption 3 > sha512WithRSAEncryption 4 The problem here is that RSA Encryption is not enough. For example there might be implementations which only support 1024-bit RSA keys, as they have old crypto hardware. > dsa-with-sha1 5 > dsa-with-sha256 6 > ecdsa-with-sha1 7 > ecdsa-with-sha256 8 > ecdsa-with-sha384 9 > ecdsa-with-sha512 10 Or there is implementation which support ECDSA only with NIST curves, and not with brainpool curves. > RSASSA-PSS-default 11 > > And to include values from this registry into > SIGNATURE_HASH_ALGORITHMS notification. > This will allow peer indicate not only hash alg, > but the particular pairs signature-hash which it supports. The problem with that kind of registry is that the registry gets quite large quite quickly, especially if we take different curves etc in to account too. And also it will make the initial IKE_SA_INIT packets bigger. On the other hand we could move that negotiation at the same place where have CERTREQ, i.e. responders IKE_SA_INIT, and initiators IKE_AUTH, as this is where that information is needed. > P.S. One small typo in the draft. > in Appendix A last sentence of first para: > > "These values are taken form the New > ASN.1 Modules..." > > s/form/from Fixed. -- kivinen@iki.fi From rsj@cisco.com Thu Oct 24 08:44:31 2013 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 8EE8711E819F for ; Thu, 24 Oct 2013 08:44:29 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVUESjpMoUui for ; Thu, 24 Oct 2013 08:44:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CCBE011E8363 for ; Thu, 24 Oct 2013 08:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2375; q=dns/txt; s=iport; t=1382629359; x=1383838959; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=WUjiZgFf9VWkWBC73jzF3ckV+AaMS2KahfKCsIljYB8=; b=XWtr2zPSEbQ+ZL0s8e6tuq2g9nhpfkoQ2X+gG6aMCon1QBatqL6glA5A S9n3GvPrN+QTyAIMO9EJW+UDVI7mfvi/sMRSWP+WWFxT7DFLLf7gcPZJp svgKqvknAU8y2ywwPGsut8MDtrT1h27fTrOSGScZqqMx0gpg1t/elQ4HN A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAHE+aVKtJXHB/2dsb2JhbABZgwc4VL5YgR0WdIIlAQEBBAEBATc0FwQCAQgOAwEDAQELFAkHJwsUAwYIAgQBEggRh24NuigEjgKBGjgGgxmBDQOqEYFmgT6BaEI X-IronPort-AV: E=Sophos;i="4.93,563,1378857600"; d="scan'208";a="273184195" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 24 Oct 2013 15:42:38 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9OFgcEi010584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 15:42:38 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 24 Oct 2013 10:42:37 -0500 From: "Rajeshwar Singh Jenwar (rsj)" To: Valery Smyslov , "ipsec@ietf.org" Thread-Topic: [IPsec] Some comments concerning draft-amjads-ipsecme-ikev2-data-channel-00.txt Thread-Index: AQHOz/UyWMl9R1YPskqodl90QxQTeZoD4Yvg Date: Thu, 24 Oct 2013 15:42:37 +0000 Message-ID: References: <20130915114752.25560.4833.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.36.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] Some comments concerning draft-amjads-ipsecme-ikev2-data-channel-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: Thu, 24 Oct 2013 15:44:31 -0000 Hi Valery, Thanks for your comments. Please see my replies inline [RSJ] Kind Regards, Raj -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of V= alery Smyslov Sent: Wednesday, October 23, 2013 7:08 PM To: Rajeshwar Singh Jenwar (rsj); ipsec@ietf.org Subject: [IPsec] Some comments concerning draft-amjads-ipsecme-ikev2-data-c= hannel-00.txt Hi, I have some comments concerning the draft. 1. As far as I understand, only one data channel can be created within one IKE SA. So, if application needs several different channels, it have to create several separate IKE SAs, performing authentication several times (probably involving human activity, if EAP is used). This is makes the whole architecture not so lightweight. [RSJ] Most of deployment use only single IPsec SA per peer, either They want to use security for all data for a peer/network or do= n't. The network for which we don't want security protection can be = excluded using Access Control Lists (ACLs). So, in deployment where different application want to use IKEv2= data channel, we can use same IKEv2 SA for same peer for different applica= tion. =20 We are working on how to multiplex different applications using = single IKEv2 SA, currently, we are thinking of using adding source and des= tination Port in IKEv2 data channel payload. =20 2. Nothing is said abouth channel deletion. I presume it exists untill IKE SA is deleted, right? [RSJ] Right. It is coupled with life of IKEv2 SA. 3. Could this IKE SA be used for other purposes, for example to create Child SAs as usual, or it must be explicitely dedicated to IKE Data channel? [RSJ] Good Point. With IKEv2 data channel IKE_AUTH will not have IPsec payl= oads. But don't see any reason why this SA can't be used to create chil= d SAs using CREATE_CHILD_SA exchange. 4. In Section 8.1 in description of Protocol ID: according to RFC5996 this field MUST be zero if SPI Size field is zero. [RSJ] There is some confusion as per Sec 3.10, it is not very clear.=20 Regards, Valery Smyslov.=20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Thu Oct 24 08:57:36 2013 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 0D05C11E8388 for ; Thu, 24 Oct 2013 08:57:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtbqAAramaX9 for ; Thu, 24 Oct 2013 08:57:24 -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 1332811E8389 for ; Thu, 24 Oct 2013 08:53:32 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r9OFrSUA060323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Oct 2013 08:53:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Paul Hoffman In-Reply-To: Date: Thu, 24 Oct 2013 08:53:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1974A9CB-192B-4306-A070-F25EBBACD49D@vpnc.org> References: <20130915114752.25560.4833.idtracker@ietfa.amsl.com> To: "Rajeshwar Singh Jenwar (rsj)" X-Mailer: Apple Mail (2.1816) Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Some comments concerning draft-amjads-ipsecme-ikev2-data-channel-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: Thu, 24 Oct 2013 15:57:46 -0000 As a note to the WG, I asked Raj to turn in a revised draft which = covered some of the points that Valery and others have made. Given the = number of questions asked so far, I would prefer that the WG hold off on = discussing this draft until there is a new, clarified draft. --Paul Hoffman= From lberger@labn.net Thu Oct 24 09:03:41 2013 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 0DC8E11E8362 for ; Thu, 24 Oct 2013 09:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.109 X-Spam-Level: X-Spam-Status: No, score=-102.109 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 857fir0BfYtq for ; Thu, 24 Oct 2013 09:03:35 -0700 (PDT) Received: from outbound-ss-189.hostmonster.com (outbound-ss-189.hostmonster.com [67.222.50.187]) by ietfa.amsl.com (Postfix) with SMTP id 0F06E11E8374 for ; Thu, 24 Oct 2013 08:57:10 -0700 (PDT) Received: (qmail 3600 invoked by uid 0); 24 Oct 2013 15:57:09 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy18-pub.mail.unifiedlayer.com with SMTP; 24 Oct 2013 15:57:09 -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=M9YdC0r1Rxx/xfWZ4ZfbsrPCP1aWFZarFLNzHQMwHV0=; b=17sT3f/BJgU/HnciWqt/eovtH9K6qPOPVU8I7EznvPLqmblAV9NMaiFzKF7rd1E4ZoiEZ5B4Om88WovFcXz85N48U80k0yiOCXsQHxmUVIs82UHNI9yRofBtM6iBtDrT; Received: from box313.bluehost.com ([69.89.31.113]:51606 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1VZNHZ-0005Yj-0o; Thu, 24 Oct 2013 09:57:09 -0600 Message-ID: <5269434E.3050109@labn.net> Date: Thu, 24 Oct 2013 11:57:02 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Mike Sullenberger (mls)" References: <5261B62A.4020209@labn.net> <9D83DE546CB6DC47A3AE04086FDE35F523FADE2D@xmb-aln-x06.cisco.com> In-Reply-To: <9D83DE546CB6DC47A3AE04086FDE35F523FADE2D@xmb-aln-x06.cisco.com> X-Enigmail-Version: 1.5.2 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 , "draft-detienne-dmvpn@tools.ietf.org" Subject: Re: [IPsec] Some comments on draft-detienne-dmvpn-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: Thu, 24 Oct 2013 16:03:41 -0000 Hi Mike, Thanks for the response. See below... On 10/23/2013 2:54 PM, Mike Sullenberger (mls) wrote: > Lou, > > Thank you for your comments, more inline. > > Mike. > > Mike Sullenberger, DSE > mls@cisco.com .:|:.:|:. > Customer Advocacy CISCO > > > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Friday, October 18, 2013 3:29 PM >> To: draft-detienne-dmvpn@tools.ietf.org >> Cc: IPsecme WG >> Subject: Some comments on draft-detienne-dmvpn-00 >> >> Hi, >> I have the following comments/questions on the draft: >> >> - Why allow IPsec tunnel mode? Is there a case where it provides some value? > > [Mike Sullenberger] > You are correct that IPsec tunnel mode is not really needed and > transport mode is far recommended and preferred. There are a couple > of rare situations where tunnel-mode could help, like when separating > the GRE/NHRP tunneling and IPsec encryption onto separate nodes, > these cases are not recommended, but we thought we should leave in > the possibility. > How does this work? As I understand it, NHRP is run inside the GRE tunnel so this means that the IPsec and GRE endpoints now need some way to communicate (for e.g., public ("NBMA") addresses and GRE/IPsec tunnel creation/removal coordination). Am I missing something? >> - Do you want to recommend omitting the GRE checksum? > > [Mike Sullenberger] > Good idea, we definitely don't use the GRE checksum, and I don't > think it provides any value so we should recommend omitting it. I > think this is also the case for most of the other optional GRE header > attributes. > Though, the GRE Tunnel Key must be allowed, handled and > provided. > I missed that the tunnel key MUST be "provided". Can you elaborate on this? I only see one oblique reference to it in the draft. >> - I think the draft should discuss what happens when the best route moves >> from one spoke to another spoke. Both the cases where the host/prefix is >> still reachable via the original spoke and when it isn't should be covered. As >> should avoiding blackholes, and any periods of suboptimal forwarding. > > [Mike Sullenberger] > We can add some more discussion around this point. The main feature > here is that this is handled by the routing protocol that is running > over the DMVPN tunnels. For clarification: routing runs over the configured DMVPN topology, but not shortcuts, right? > The routing protocol will redirect the data > packets via different tunnels and/or spokes as the routing is > updated. I think your answer to my next question actually helps answer this one. So Section 6.1 of RFC2332 says: ... In such circumstances, NHRP should not be used. This situation can be avoided if there are no "back door" paths between the entry and egress router outside of the NBMA subnetwork. Protocol mechanisms to relax these restrictions are under investigation. Do you believe this restriction still applies? > Note, if static routing is used then you lose this > capability. Sure. > >> - I think the draft is missing a description of how/when NHRP Purges are >> used, e.g., resulting from interactions with routing. (Yes there is an overlap >> with the above, but it depends a bit on your solution.) > > [Mike Sullenberger] > As you have noted, NHRP purges are used to keep the distributed NHRP > database in sync. If a local node loses access to a destination that > it has previously replied with itself as the egress point in an NHRP > mapping (and the entry hasn't timed out yet) then it will generate an > NHRP purge and send a copy to each requester (recorded when it sent > the original reply). This will then clear out these now invalid > mapping entries on the remote nodes and trigger them to find an > alternate path if available. Note, this is basically what is > described in NHRP (RFC2332), we didn't really want to duplicate this > in this RFC, but it could be added. > okay, I think this comes back to where the draft says: > In this document, we will depart the > underlying notion of a centralized NHS. I think the part that's missing (or perhaps I just missed) is an explicit statement that an egress must follow the NHS procedures related to any issued Resolution Reply. >> - I the draft should discuss the NHRP scaling considerations that are >> important in implementation and deployment/operation. (Basically the >> solution is proposing network wide ARP.) You already have a teaser on this >> when you mention rate limiting. > > [Mike Sullenberger] > We can certainly do so. In DMVPN deployments we haven't really found > that NHRP scaling has been an issue. Usually we ran into either > Routing protocol or IPsec scaling issues first. It is correct we do > mention a couple of places about rate limiting triggering or sending > of NHRP messages, mainly because it wasn't felt that it was useful to > continue to "bother" another node if it was working on the previous > request, which was the same as the one to be sent again. Note, we do > have mechanisms for retransmission and back-off of messages. Again > some of this is covered in the NHRP RFC. > I guess it all depends on the number of routes in the system and reachability pattern at a particular spoke. I think when both are large, the use of per prefix soft state refreshes will prove problematic. I'm a bit surprised you've run into routing protocol scaling issues though, but that's certainly out of scope. >> - NIT/editorial: If section 4 is your "Solution Overview", where is the >> solution specification? More seriously, I found parts of this section more of >> a narrative of an example than a protocol specification. > > [Mike Sullenberger] > Yes, I think this needs to be cleaned up. Since a lot of what we do > with NHRP is covered in the NHRP RFC we didn't want to duplicate too > much here, but we can certainly make a more clear solution > specification. I think the solution overview section is also useful > since, a walk through can help people to understand how the solution > is intended to work. Many times I find it hard with just solution > specifications to get a real feel for how things go together. > Avoiding duplicate specification is certainly goodness, but I think some additional pointers to when standard NHRP procedures are to be followed (or not) would be a valuable addition as part of the cleanup. Much thanks, Lou >> - NIT: Assuming the Indirection Notification described in section 4.3 is the >> same as the NHRP Traffic Indication covered in 5.1, can you align the names >> and fix the reference in 4.3? > > [Mike Sullenberger] > Yes, thanks for noting this. We tend to use those terms interchangeably, but we should be more consistent here. > >> >> Thanks, >> Lou > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > From rsj@cisco.com Thu Oct 24 09:07:04 2013 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 D804811E8355 for ; Thu, 24 Oct 2013 09:07:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZG9noL05y-W for ; Thu, 24 Oct 2013 09:06:57 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 72CBA11E8365 for ; Thu, 24 Oct 2013 09:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=651; q=dns/txt; s=iport; t=1382630488; x=1383840088; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=fGgRDllkHbe5XELTnOIAGUdibyXKZx6Q6cOTwiH4Z6w=; b=KzS0tldat79VSyhpG7McT3QAFB7cakTjgKBUgYHUlNO+UyKYz8D8ZHDr GEIWNlRwxvWpGI05Dy4eDphF5RhdsXu8udvU0atXk+LtnliEM/TB7Hies SBHRSeGRHXPwZGFm0bx/BQYqkKUtGrnBYNYK8X8WiIqIiXHRIyu9QygDi g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOVCaVKtJXG8/2dsb2JhbABZgweBDL5YgR0WdIIlAQEBBDo/DAQCAQgRBAEBCxQJBzIUCQgCBA4FCId/ukqPHDEHBoMZgQ0DqhGBZoE+gio X-IronPort-AV: E=Sophos;i="4.93,563,1378857600"; d="scan'208";a="276207644" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 24 Oct 2013 16:01:19 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9OG1JEx022295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 16:01:19 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.247]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 24 Oct 2013 11:01:19 -0500 From: "Rajeshwar Singh Jenwar (rsj)" To: Paul Hoffman Thread-Topic: [IPsec] Some comments concerning draft-amjads-ipsecme-ikev2-data-channel-00.txt Thread-Index: AQHOz/UyWMl9R1YPskqodl90QxQTeZoD4YvggAB0tgD//65MUA== Date: Thu, 24 Oct 2013 16:01:18 +0000 Message-ID: References: <20130915114752.25560.4833.idtracker@ietfa.amsl.com> <1974A9CB-192B-4306-A070-F25EBBACD49D@vpnc.org> In-Reply-To: <1974A9CB-192B-4306-A070-F25EBBACD49D@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.36.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Some comments concerning draft-amjads-ipsecme-ikev2-data-channel-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: Thu, 24 Oct 2013 16:07:05 -0000 Sure Paul, We will submit revised version soon. Kind Regards, Raj -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Thursday, October 24, 2013 9:23 PM To: Rajeshwar Singh Jenwar (rsj) Cc: ipsec@ietf.org Subject: Re: [IPsec] Some comments concerning draft-amjads-ipsecme-ikev2-da= ta-channel-00.txt As a note to the WG, I asked Raj to turn in a revised draft which covered s= ome of the points that Valery and others have made. Given the number of que= stions asked so far, I would prefer that the WG hold off on discussing this= draft until there is a new, clarified draft. --Paul Hoffman From priikone@iki.fi Thu Oct 24 09:41:00 2013 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 40C8B11E81A0 for ; Thu, 24 Oct 2013 09:40:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWAiz9KpRoHR for ; Thu, 24 Oct 2013 09:40:38 -0700 (PDT) Received: from git.silcnet.org (git.silcnet.org [81.89.56.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F11811E837B for ; Thu, 24 Oct 2013 09:40:13 -0700 (PDT) Received: from git.silcnet.org (localhost [127.0.0.1]) by git.silcnet.org (8.14.4+Sun/8.14.4) with ESMTP id r9OGe9ff005660; Thu, 24 Oct 2013 18:40:09 +0200 (CEST) Received: from localhost (priikone@localhost) by git.silcnet.org (8.14.4+Sun/8.14.4/Submit) with ESMTP id r9OGe2Mu005657; Thu, 24 Oct 2013 18:40:03 +0200 (CEST) X-Authentication-Warning: git.silcnet.org: priikone owned process doing -bs Date: Thu, 24 Oct 2013 18:40:02 +0200 (CEST) From: Pekka Riikonen X-X-Sender: priikone@git.silcnet.org To: Yaron Sheffer In-Reply-To: <5268055E.4000804@gmail.com> Message-ID: References: <5268055E.4000804@gmail.com> User-Agent: Alpine 2.00 (GSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: IPsecme WG Subject: Re: [IPsec] Working Group Last Call: draft-kivinen-ipsecme-signature-auth-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: Thu, 24 Oct 2013 16:41:00 -0000 The ASN.1 used here are the same ASN.1 which is used in the AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]). The It should specify encoding rules, even though it references RFC5280. So this could say something like: The ASN.1 used here are the same ASN.1 which is used in the AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]) encoded using distinguished encoding rules (DER) [X.690]. -- the authentication methods are not negotiated in the IKEv2, the peer is only allowed to use this authentication method if the SIGNATURE_HASH_ALGORITHMS Notify Payload has been sent and received. I think I said this already for -00 version, that I'd still prefer to allow the use of the new authentication method even if the hashes weren't negotiated (the hash is is indicated in the ASN.1). I get why we want to negotiate them, but it's not always necessary, necessarily. And if it isn't allowed should it be MUST NOT? Otherwise it's great, and important work. Pekka From touch@isi.edu Thu Oct 24 10:05:38 2013 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 B06B811E8246; Thu, 24 Oct 2013 10:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.742 X-Spam-Level: X-Spam-Status: No, score=-103.742 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrCX1MTTo34v; Thu, 24 Oct 2013 10:05:28 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id C1C8C11E8189; Thu, 24 Oct 2013 10:05:07 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9OH4oFR002866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 24 Oct 2013 10:04:50 -0700 (PDT) Message-ID: <52695365.4070803@isi.edu> Date: Thu, 24 Oct 2013 10:05:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Valery Smyslov References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> In-Reply-To: <81953CE6126542A8AD40207921B8E018@buildpc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg , tsv-ads@tools.ietf.org, Martin Stiemerling , ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 24 Oct 2013 17:05:44 -0000 On 10/23/2013 11:42 PM, Valery Smyslov wrote: > Hi Joe, > > thank you for your suggestions. I still have some comments. > >> On 10/22/2013 11:25 PM, Valery Smyslov wrote: >>> I appreciate the work transport folks has done. I will also appreciate >>> if you point out what exact lessons should be applied here and why. >>> And you may consider PMTUD in IKE as simplified PLMTUD, >>> implemented according with Section 10.4 of RFC4821. >> >> From the second sentence of that section: Because you never generate >> distinct probes, finding out when the MTU fails is tied to timeouts in >> your message exchange system, rather than being decoupled. > > That's true. I don't see any requirements in section 10.4. that the probes > must be distinct. Request/reply nature of IKE's messages make them > well suitable for probes and I see no need here to introduce > separate mechanism, adding complexity, consuming bandwith and adding delay. > Moreover, section 10.4 explicitely allows using application data for > probes. Yes, but there are two components: - the probes - the timeouts You're using existing IKE messages *and* existing timeouts to determine when there is a problem. A separate timer would be useful, if only to allow you to decouple fragment retransmission from IKE transaction retries. >> From Section 9: You don't talk about trying to make sure that IPv4 DF >> is set, as per Section 9, which means that even the conservative >> values you pick might continue to generate fragments downstream. > > With all due respect, I have to disagree that setting DF bit is needed > in case of IKE. > With IKE the goal is not to make sure that _no_ IP fragmentation takes > place > on the path, but to make sure that IP fragmentation issues, if any, > do not prevent IKE communications. So, IP fragmentation is present on > the path, > but it doesn't bother us - let it be. Agreed. But that's the case when IKE works with whatever message size you start with. > If it doesn't allow IKE to work > (either by dropping IP fragments or by attacking destination host with > bogus fragments) - we will try to avoid it. So, in your example, even if > IP fragments are generated downstream, but those fragments are passed - > let them be. Your mechanism kicks in (presumably) when IKE fails, and then you retry with application-layer fragments. App-layer fragments are useless if the network level then fragments the messages. That's why you should set DF=1. > Note, that this approach is in line with advices, given for IKE in the > paper > > C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection > for UDP-based protocols", ACM Conference on Computer and > Communications Security, October 2003. That paper doesn't consider IKE-level fragmentation, which you're introducing. I agree that DF=0 for IKE without IKE-level fragmentation. > that is reffered by RFC5996 as recommendations to protect against IP > fragmentation issues. Section 3.3 of this paper discusses the ways PMTUD > should be done in IKE and finds it more advantageous not to set DF bit. That too refers to IKE without IKE-level fragmentation (see Sec 2). Again, once you introduce fragmentation at the IKE-level to avoid IP fragmentation, it makes no sense to continue to allow it at the IP level. Joe From svanru@gmail.com Thu Oct 24 22:45:47 2013 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 041C011E813D; Thu, 24 Oct 2013 22:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pp-WuY0j+KC; Thu, 24 Oct 2013 22:45:46 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 048F411E82AD; Thu, 24 Oct 2013 22:45:39 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so349219lbj.17 for ; Thu, 24 Oct 2013 22:45:39 -0700 (PDT) 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; bh=817cBuN6nNYLL1BL4q2sNN2jfobyYIqeeVMVEEXLjtY=; b=c7krcE4FnkSskTnXKHbZCaUY/eddVmZLkslt6/39XG7/e6GZ4UyM9uatvqgoqSexPw jH8StCvHAX6jiF7Y/nKOsbvL4nGIG4NzSuF8gyENFDmyZGfo9aUYvTVFvN/9Yc1+rFye lx6kDwzvyow+OaJWXRwqJ0n/zsEDIjVTWFMi+dXYXx5LhgtP8rLjquAjNNlrnHdy5gRB rG9DiXkImplJK+cWpAEnz96H3fLM7JfXHs/+tdW5FUoQIMmXBGse9pvnrtOV+MZyaAS3 mOYj5yewT0dQ68+MPNa7VT6GZ3EXj12iWBLSCHfawFIprow/25zpJBgawz3EpIJch3qE nnhQ== X-Received: by 10.112.89.100 with SMTP id bn4mr1122815lbb.16.1382679938894; Thu, 24 Oct 2013 22:45:38 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id vk8sm1330016lbb.0.2013.10.24.22.45.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Oct 2013 22:45:38 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Joe Touch" References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> Date: Fri, 25 Oct 2013 09:45:48 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response 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: tsvwg , tsv-ads@tools.ietf.org, Martin Stiemerling , ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 25 Oct 2013 05:45:47 -0000 >> That's true. I don't see any requirements in section 10.4. that the >> probes >> must be distinct. Request/reply nature of IKE's messages make them >> well suitable for probes and I see no need here to introduce >> separate mechanism, adding complexity, consuming bandwith and adding >> delay. >> Moreover, section 10.4 explicitely allows using application data for >> probes. > > Yes, but there are two components: > - the probes > - the timeouts > > You're using existing IKE messages *and* existing timeouts to determine > when there is a problem. A separate timer would be useful, if only to > allow you to decouple fragment retransmission from IKE transaction > retries. No, the timeouts are different. I should have made it more expplicit in the draft. When doing PMTU discovery host needs to try several MTU sizes before considering peer to be dead, so exchange timeout must be greater then the sum of all probes timeouts. Probe timeout should be relatively short, just less then 10 seconds before going to next size, while the whole exchange timeout is pretty long, about one minute or more. >>> From Section 9: You don't talk about trying to make sure that IPv4 DF >>> is set, as per Section 9, which means that even the conservative >>> values you pick might continue to generate fragments downstream. >> >> With all due respect, I have to disagree that setting DF bit is needed >> in case of IKE. >> With IKE the goal is not to make sure that _no_ IP fragmentation takes >> place >> on the path, but to make sure that IP fragmentation issues, if any, >> do not prevent IKE communications. So, IP fragmentation is present on >> the path, >> but it doesn't bother us - let it be. > > Agreed. But that's the case when IKE works with whatever message size you > start with. > >> If it doesn't allow IKE to work >> (either by dropping IP fragments or by attacking destination host with >> bogus fragments) - we will try to avoid it. So, in your example, even if >> IP fragments are generated downstream, but those fragments are passed - >> let them be. > > Your mechanism kicks in (presumably) when IKE fails, and then you retry > with application-layer fragments. App-layer fragments are useless if the > network level then fragments the messages. That's why you should set DF=1. Again, there's no need for IKE to absolutely disallow IP fragmentation unless it prevents IKE to communicate. If we have two routers down the path, first fragmenting IP packets into size S1 and the second fragmenting them into size S2, so that S2 < S1, and some device between them that drops IP fragments, then it is enough for IKE to make so that application fragments will have size < S1, but probably > S2. Then we will avoid first fragmentation, but will still allow second one, as it doesn't bother us. In this case application fragments are useful, even with the presence of IP fragmentation. Always setting DF bit in this case will probably increase the delay before IKE SA is set up (as more probes will need to be done). >> Note, that this approach is in line with advices, given for IKE in the >> paper >> >> C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection >> for UDP-based protocols", ACM Conference on Computer and >> Communications Security, October 2003. > > That paper doesn't consider IKE-level fragmentation, which you're > introducing. I agree that DF=0 for IKE without IKE-level fragmentation. It does, in Section 3.3. >> that is reffered by RFC5996 as recommendations to protect against IP >> fragmentation issues. Section 3.3 of this paper discusses the ways PMTUD >> should be done in IKE and finds it more advantageous not to set DF bit. > > That too refers to IKE without IKE-level fragmentation (see Sec 2). Again, > once you introduce fragmentation at the IKE-level to avoid IP > fragmentation, it makes no sense to continue to allow it at the IP level. Please, see above. > Joe Regards, Valery. From svanru@gmail.com Thu Oct 24 23:02:11 2013 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 BCDB311E813D for ; Thu, 24 Oct 2013 23:02:11 -0700 (PDT) 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.125, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAq+c4-yYmY3 for ; Thu, 24 Oct 2013 23:02:11 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 68C8411E8118 for ; Thu, 24 Oct 2013 23:02:07 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id eh20so2612248lab.25 for ; Thu, 24 Oct 2013 23:02:06 -0700 (PDT) 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; bh=+TPVOmKDXz45bJK3MAnOLVd53E1rhbCQJx2uQ2Stbgs=; b=A/Dwx6p0Ty9Zf1iuejQTlZrJrGfMixB6ODmaFeYwm/hecTHPvdI37em11PD74Dnn9C 84yY7lvugBfvJqwhpRs22OMhLH7Y0NaoSsgyyPMfICA6EF2lPVd70KNouwU8erxSN07n ID/RNYswZbGR4eMjlwb9VDU9dt9dTql+lAJ7Zz9dvSEm9iEhJEy7+qkbsg/McsxsB0gI 0+0iY9Hln1tgT8C1mSBCJLW9LwO7A+L32luMNIfarzyh4KWgRsCTfoyCOtxGJ1/LzcJw YDD9UdT7dUeofW/kYRXfaAY1NqiUB0ibZFPS9b157f81NK+jlImXBIkUUsFH65OtCuAu zHxg== X-Received: by 10.152.235.40 with SMTP id uj8mr241276lac.39.1382680926439; Thu, 24 Oct 2013 23:02:06 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id k6sm4933235lae.9.2013.10.24.23.02.05 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 24 Oct 2013 23:02:05 -0700 (PDT) Message-ID: <512D7DBD7035491D8A89A7774D07B6E8@buildpc> From: "Valery Smyslov" To: "Rajeshwar Singh Jenwar \(rsj\)" , References: <20130915114752.25560.4833.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2013 10:02:16 +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] Some comments concerningdraft-amjads-ipsecme-ikev2-data-channel-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: Fri, 25 Oct 2013 06:02:11 -0000 Hi Raj, > 1. As far as I understand, only one data channel can be created > within one IKE SA. So, if application needs several different > channels, > it have to create several separate IKE SAs, performing authentication > several times (probably involving human activity, if EAP is used). > This is makes the whole architecture not so lightweight. > > [RSJ] Most of deployment use only single IPsec SA per peer, either > They want to use security for all data for a peer/network or > don't. > The network for which we don't want security protection can be > excluded using Access Control Lists (ACLs). > So, in deployment where different application want to use > IKEv2 data channel, we can use same IKEv2 SA > for same peer for different application. > We are working on how to multiplex different applications using > single IKEv2 SA, currently, we are thinking of > using adding source and destination Port in IKEv2 data channel > payload. To clarify my comment - I meant that your draft allows to create data channels with different properties - aknowledged unacknowledged, integrity only etc. Different applications will need different properties. If you create only one data channel per IKE SA, its properties won't probably satisfy all applications that need it. So you will need to create several IKE SA. But let's wait for next version of the draft. Regards, Valery. From svanru@gmail.com Fri Oct 25 00:25:42 2013 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 7245321F9FB0 for ; Fri, 25 Oct 2013 00:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5grJT6vX8HY for ; Fri, 25 Oct 2013 00:25:41 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8A77F21F9FAC for ; Fri, 25 Oct 2013 00:25:36 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id w7so414132lbi.4 for ; Fri, 25 Oct 2013 00:25:33 -0700 (PDT) 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; bh=B3X7GvnqwgPitJH2LnXtOBhVMoCaBaQVI55uCoIfs7I=; b=aBhaXSwfwVlQZ27//YyLvjJvMyF1ioW0MjfgqdUKE/VudqruN9sFUNPA+zMfv8GbO/ pwuguvhzjhU7OWSW0ztS0zkjWdAhab6tBXlOvcx4Da1xbOjcODP7Jgclvm8I3lMQiwPf dsiOUGFdPZf0aWLNtN3RYJbEpzbz6gVATLX8IjH2zNEMRDdCVkQuBDgYwFG8D1hGeExg RHl421tBCmRVDgLSPCudPy6fWUb27ccd7zxIGz4MLIQqGxejxizKV1MeaaNk+QxrgWWX NLC4dd0iwtDZZFySJPGYZzrcCrAxmO28zb3/AQCVPJDsY2uPCWQTor5RL4yElsNnmetQ uLZg== X-Received: by 10.112.72.100 with SMTP id c4mr185564lbv.57.1382685933482; Fri, 25 Oct 2013 00:25:33 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id ao4sm5247438lac.1.2013.10.25.00.25.31 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Oct 2013 00:25:32 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <5268055E.4000804@gmail.com><876DF97CB1AF4CA7B96634DDE3D51B1B@buildpc> <21097.16245.405563.467088@fireball.kivinen.iki.fi> Date: Fri, 25 Oct 2013 11:25:42 +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: IPsecme WG Subject: Re: [IPsec] Working Group LastCall:draft-kivinen-ipsecme-signature-auth-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: Fri, 25 Oct 2013 07:25:42 -0000 Hi Tero, > Valery Smyslov writes: >> The problem, that the draft is not solving, is the situation, >> when one of the peers has more than one private key, each >> for different signature algorithm. This may happen if in deployed >> VPN there is a need to move from one signature alg >> to another (for any reason, for example when old algorithm >> is found to be broken or obsoleted by authorities). As the >> transition cannot be done at once, there will be a period when >> some of the hosts will have only a single key, while the others >> will have more than one. In general, host with multiple keys >> cannot decide which of them to use with different peers, >> so there is a possibility, that IKE will fail, when it could have >> completed. CERTREQ payloads may help in some cases, >> but not in all (single CA may issue both certificates signed >> with one trusted root) and they are optional anyway. > > Lets take example where someone thinks that RSA keys are not strong > enough anymore, and should be replaced with ECDSA keys. They also have > old implementation which only support RSA, and then they have newer > implementation which support both. > > To do the change, they need to provide newer implementations a ECDSA > certificates and keys, but also keep the old RSA keys around, as those > are needed to talk to the old implementations. Right. > Also note, as they do consider RSA keys too weak to be used, they > would also need to change the signature algorithms on their > certificates. This would mean they would need to get new CA or sub CA > key with ECDSA keys to sign those new ECDSA certificates. Most probably yes. But I can imagine situations when new ECDSA certificates will be signed by old RSA keys. Root CA keys are usually made much longer than EE keys, so they may still be considered secure for mean time. Changing all CA infrastructure at once is a big problem. And algorithm weakness is only one example of the necessity to change it. Trere may be other reasons as well (administartive requirements, performance, licensing issues), and not all of them will require to change CA and its algorithm. > So when the old device talks to new device, it will send CERTREQ to > the old RSA CA, and because the new implementation only has > RSA certificate for that older RSA CA, it will automatically pick RSA > key and use that. Everything works automatically. > > The new device knows both ECDSA and RSA so it can always verify what > the old device sends. Things work automatically there too. Yes, but see above. > CERTREQ payloads may be optional, but so is support for this. If you > want to support changing from one CA infrastructure to another you > need to support CERTREQ payloads. > > Changing the underlaying key used in the IPsec is useless unless you > also change it in the certificate infrastructure too. > > The real problem is that with Raw Public keys you do not have this > option, as CERTREQ payloads are not useful there (their contents are > empty). But on the other hand RFC5996bis does not have Raw public keys > anymore :-) > > And you can always retry when you notice that you get authentication > error after using private key, provided you have multiple types of > keys. In general you can't if it is responder who selected wrong key. > Anyways, I do not really consider this as serious problem in the real > world. In most of the cases the certificate hierarchy needs to be > changed anyways at the same time when changing authentication keys, > and then you get this negotiation automatically. > > On those situations this does not work, then you can always manually > configure the devices to use specific keys, or try both keys. I admit, that such situations are rare but not non-existent. And manual configuration is not an option for large VPNs. Retry is not always possible and is a hack anyway. >> I suggest to change this as following. Instead of >> adding IKE registry, listing hash algorithms, >> add registry listing combinations of hash&signature >> algorithms, as listed in Appendix A. >> So, the registry would look like: >> >> RESERVED 0 >> sha1WithRSAEncryption 1 >> sha256WithRSAEncryption 2 >> sha384WithRSAEncryption 3 >> sha512WithRSAEncryption 4 > > The problem here is that RSA Encryption is not enough. For example > there might be implementations which only support 1024-bit RSA keys, > as they have old crypto hardware. There might also be implementations, that supports only md5, but we do not consider them, do we? And the problem with the current SIGNATURE_HASH_ALGORITHMS is that it decouples hash from signature, assuming that any hash could be used with any signature algorithm. Actually this is not true, as some algorithms are administratively defined only in conjunction with particular hash function. For example GOST signature algorithm is defined ONLY with GOST hash. And even if you could use DSA with SHA-2 or even SHA-3, I would more likely expect the existence of crypto that supports DSA only with SHA-1, than the crypto, that supports only RSA with 1024 bit keys and no other RSA key sizes. >> dsa-with-sha1 5 >> dsa-with-sha256 6 >> ecdsa-with-sha1 7 >> ecdsa-with-sha256 8 >> ecdsa-with-sha384 9 >> ecdsa-with-sha512 10 > > Or there is implementation which support ECDSA only with NIST curves, > and not with brainpool curves. Probably they should also be added. >> RSASSA-PSS-default 11 >> >> And to include values from this registry into >> SIGNATURE_HASH_ALGORITHMS notification. >> This will allow peer indicate not only hash alg, >> but the particular pairs signature-hash which it supports. > > The problem with that kind of registry is that the registry gets quite > large quite quickly, especially if we take different curves etc in to Yes, this is a problem. But I hope the registry will still be of reasonable size, much less that its capacity. > account too. And also it will make the initial IKE_SA_INIT packets > bigger. On the other hand we could move that negotiation at the same Yes, this is also a problem. That's why I'd prefer registry to approach, when supported ASN.1 are listed in the notification. And I still expect, that the number of supported hash-sign combinations in real life will be limited (probably by configuration). > place where have CERTREQ, i.e. responders IKE_SA_INIT, and initiators > IKE_AUTH, as this is where that information is needed. It will solve the last problem only partially. Regards, Valery. From Johannes.Merkle@secunet.com Fri Oct 25 01:24:53 2013 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 E9C8821E80A7 for ; Fri, 25 Oct 2013 01:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MteoNlZudOh4 for ; Fri, 25 Oct 2013 01:24:48 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB1821F9DAA for ; Fri, 25 Oct 2013 01:24:45 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id A03F41A007A; Fri, 25 Oct 2013 10:25:34 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Zw8Vhy0A4IhP; Fri, 25 Oct 2013 10:25:32 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id AA4E11A0079; Fri, 25 Oct 2013 10:25:32 +0200 (CEST) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Oct 2013 10:24:41 +0200 Message-ID: <526A2ACD.3000406@secunet.com> Date: Fri, 25 Oct 2013 10:24:45 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Valery Smyslov , Tero Kivinen References: <5268055E.4000804@gmail.com><876DF97CB1AF4CA7B96634DDE3D51B1B@buildpc> <21097.16245.405563.467088@fireball.kivinen.iki.fi> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2013 08:24:42.0125 (UTC) FILETIME=[A76953D0:01CED15B] Cc: IPsecme WG Subject: Re: [IPsec] Working Group LastCall:draft-kivinen-ipsecme-signature-auth-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: Fri, 25 Oct 2013 08:24:54 -0000 Valery, >>> I suggest to change this as following. Instead of >>> adding IKE registry, listing hash algorithms, >>> add registry listing combinations of hash&signature >>> algorithms, as listed in Appendix A. >>> So, the registry would look like: >>> >>> RESERVED 0 >>> sha1WithRSAEncryption 1 >>> sha256WithRSAEncryption 2 >>> sha384WithRSAEncryption 3 >>> sha512WithRSAEncryption 4 >> >> The problem here is that RSA Encryption is not enough. For example >> there might be implementations which only support 1024-bit RSA keys, >> as they have old crypto hardware. Your proposal creates exactly the issue which the draft is trying to solve: The lack of flexibility by relying on IPsec code points for the signature algorithm (as opposed to using existing OIDs commonly used in certificates and CMS) and the coupling of signing algorithms and signature hash functions. > And the problem with the current SIGNATURE_HASH_ALGORITHMS > is that it decouples hash from signature, assuming that any hash > could be used with any signature algorithm. This decoupling was explicitly stated as objective by the WG chairs when the design team was set-up: Yaron Sheffer wrote on 24.07.2012 18:08: > - Allows flexibility in associating hash functions with EC groups. Therefore, this feature is not the problem, it is the solution. > Actually this is not true, as some algorithms are administratively defined > only in conjunction with particular hash function. This is the exception. For the most commonly used algorithms, RSA and ECDSA, There are no requirements to use fixed combinations. For ECDSA, there is only a minimum requirement relating to the targeted security level. > For example GOST signature algorithm is defined ONLY with GOST hash. The current proposal allows to use that combination, so what is the problem? > > And even if you could use DSA with SHA-2 or even SHA-3, > I would more likely expect the existence of crypto > that supports DSA only with SHA-1, than the crypto, > that supports only RSA with 1024 bit keys and no other RSA key sizes. > I do not think, DSA is used much at all. Even if it was, SHA-1 is phasing out due to (not so) recent advances in cryptoanalysis. Thus, I would expect either implementations to change to allow the use of DSA with SHA-2/3, or the (limited) prevalence of DSA to end soon. >>> dsa-with-sha1 5 >>> dsa-with-sha256 6 >>> ecdsa-with-sha1 7 >>> ecdsa-with-sha256 8 >>> ecdsa-with-sha384 9 >>> ecdsa-with-sha512 10 >> >> Or there is implementation which support ECDSA only with NIST curves, >> and not with brainpool curves. > > Probably they should also be added. There are 4 Brainpool curves registered and 5 NIST curves. Each can be combined with a bunch of hash functions (from the SHA-2 and SHA-3 families). > >>> RSASSA-PSS-default 11 >>> The default is with SHA-1 which will soon be outdated. Thus, you would need to allow many further PSS combinations. -- Johannes From svanru@gmail.com Fri Oct 25 04:41:26 2013 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 62AAD11E831B for ; Fri, 25 Oct 2013 04:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jql65I5SE9CO for ; Fri, 25 Oct 2013 04:41:25 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id AFBBE11E82D5 for ; Fri, 25 Oct 2013 04:41:21 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id ea20so2901552lab.24 for ; Fri, 25 Oct 2013 04:41:20 -0700 (PDT) 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; bh=L2HIA/JzDtB0ZyAPNIzfuXmxJAoLO04E7mY9Oa92AYs=; b=mcVhLzagLYO3i4I1Ha1lbWugE9gpxQAKdZuVVNc09KTwvRwDdpPYysGr8FZsD313F1 Xm3lQZ+aHiF+Q1GC8bH9fnfwoXB61kkcN3of9Un1T20+w2ASVyUCtDgspQdjXSHbxFGL mBIc1QYa9hefs36BvvQCmahsgcg/MVpRdlkJBUrKzpmZF4fsej727iJda6zlCj6MMJMn jhWW2KoedoVW93yWLTQYkFQ1QUaX76f8UbWPEPubDs/K4r2duFs1CII6pv07749SKzLZ 2rvK7lXt56kOvdPUjFW7tlfCBJ5X8cIKrxzvLRZ3LZllNpliveYglC5quQZ+ilTVZysG kNlg== X-Received: by 10.152.19.132 with SMTP id f4mr1116200lae.42.1382701280627; Fri, 25 Oct 2013 04:41:20 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id mr1sm2253217lbc.16.2013.10.25.04.41.18 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 25 Oct 2013 04:41:19 -0700 (PDT) Message-ID: <9AC5E66FCEFE43468926B26DEE20E5A0@buildpc> From: "Valery Smyslov" To: "Johannes Merkle" , "Tero Kivinen" References: <5268055E.4000804@gmail.com><876DF97CB1AF4CA7B96634DDE3D51B1B@buildpc> <21097.16245.405563.467088@fireball.kivinen.iki.fi> <526A2ACD.3000406@secunet.com> Date: Fri, 25 Oct 2013 15:41:30 +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: IPsecme WG Subject: Re: [IPsec] Working Group LastCall:draft-kivinen-ipsecme-signature-auth-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: Fri, 25 Oct 2013 11:41:26 -0000 Hi Johannes, > Your proposal creates exactly the issue which the draft is trying to > solve: The lack of flexibility by relying on IPsec > code points for the signature algorithm (as opposed to using existing OIDs > commonly used in certificates and CMS) and > the coupling of signing algorithms and signature hash functions. The main idea of my proposal is to allow node to advertise what signature algorithms it supports along with what hash functions it supports. >> And the problem with the current SIGNATURE_HASH_ALGORITHMS >> is that it decouples hash from signature, assuming that any hash >> could be used with any signature algorithm. > > This decoupling was explicitly stated as objective by the WG chairs when > the design team was set-up: > Yaron Sheffer wrote on 24.07.2012 18:08: >> - Allows flexibility in associating hash functions with EC groups. > > Therefore, this feature is not the problem, it is the solution. As far as I remember, the main problem was that Auth Method field in AUTH Payload was only 8 bits and its codepoints coupled signature with particular hash. And proposed solution just moves this coupling from IPsec registry to AlgorithmIdentifier ASN.1 object, where they are coupled naturally. That's great and I don't have any objections against it. But the other part of solution - advertising supported algorithms, is, IMHO, currently a bit deficient, as it lists only hash algoritms, while supported signature algorithms must be guessed by some indirect means. I don't insist on coupling while advertising algorithms. Another possible option is to use one more notification, say SIGNATURE_ALGORITHMS (with associated registry), listing signature algorithms (decupled from hashes) that node supports. Then peer may assume that any combination of listed signature algorithms and hashes is supported. But again, we have some special cases when some signature algorithms are defined only with particular hash functions. > -- > Johannes Regards, Valery. From Johannes.Merkle@secunet.com Fri Oct 25 05:10:55 2013 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 7B6DF11E8259 for ; Fri, 25 Oct 2013 05:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JWi-d2wZZ1B for ; Fri, 25 Oct 2013 05:10:50 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9B88111E82B8 for ; Fri, 25 Oct 2013 05:10:49 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 8F87D1A006F; Fri, 25 Oct 2013 14:11:41 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kZnmAcd2y76w; Fri, 25 Oct 2013 14:11:40 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 3DDBF1A0066; Fri, 25 Oct 2013 14:11:40 +0200 (CEST) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Oct 2013 14:10:47 +0200 Message-ID: <526A5FC6.5060601@secunet.com> Date: Fri, 25 Oct 2013 14:10:46 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Valery Smyslov , Tero Kivinen References: <5268055E.4000804@gmail.com><876DF97CB1AF4CA7B96634DDE3D51B1B@buildpc> <21097.16245.405563.467088@fireball.kivinen.iki.fi> <526A2ACD.3000406@secunet.com> <9AC5E66FCEFE43468926B26DEE20E5A0@buildpc> In-Reply-To: <9AC5E66FCEFE43468926B26DEE20E5A0@buildpc> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2013 12:10:47.0866 (UTC) FILETIME=[3D3921A0:01CED17B] Cc: IPsecme WG Subject: Re: [IPsec] Working Group LastCall:draft-kivinen-ipsecme-signature-auth-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: Fri, 25 Oct 2013 12:10:55 -0000 Hi Valery, > > As far as I remember, the main problem was that Auth Method field in AUTH Payload > was only 8 bits and its codepoints coupled signature with particular hash. Well, this was the initial problem, but then Yoav had the great idea of generalizing the mechanism by using the OIDs in CERT payload. Hash flexibility was added later and this finally resulted in the current draft. > And proposed solution just moves this coupling from IPsec > registry to AlgorithmIdentifier ASN.1 object, Experience shows that the standardization of ASN.1 AlgorithmIdentifiers is done much sooner than registration of code points for protocols. Consider the Brainpool curves or RSA-PSS as examples. > where they are coupled naturally. At least for RSA-PSS, ASN.1 AlgorithmIdentifiers provide more flexibility by the parameters field. > But the other part of solution - advertising supported algorithms, > is, IMHO, currently a bit deficient, as it lists only hash algoritms, > while supported signature algorithms must be guessed by some indirect means. > I do not object to this point. While I agree with Tero, that in most situations, a transition of the algorithm will be accompanied with a change of the CA, it may not always be the case. For instance, the usage of an RSA key specified in the certificate (SPKI) by a rsaPublicKey OID may change from PKCS#1v1.5 to RSA-PSS even without replacing the certificate. > I don't insist on coupling while advertising algorithms. > Another possible option is to use one more notification, > say SIGNATURE_ALGORITHMS (with associated registry), > listing signature algorithms (decupled from hashes) that node supports. > Then peer may assume that any combination of listed > signature algorithms and hashes is supported. This is ok for me. But of course any additional means of negotiation adds complexity which must be balanced with its benefits. > > But again, we have some special cases when some signature > algorithms are defined only with particular hash functions. > Yes, but I do not see a problem here with decoupling signature and hash. -- Johannes From paul.hoffman@vpnc.org Fri Oct 25 07:53:36 2013 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 DF50A11E8335 for ; Fri, 25 Oct 2013 07:53: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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-3JVvn6JhQ9 for ; Fri, 25 Oct 2013 07:53:36 -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 B6D8811E81B0 for ; Fri, 25 Oct 2013 07:53:28 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r9PErQVN003853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 25 Oct 2013 07:53:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Paul Hoffman In-Reply-To: <043754AD-BA58-4C9A-8491-114EE28E9F0E@vpnc.org> Date: Fri, 25 Oct 2013 07:53:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <664172B4-1C5D-46BA-BBEE-5C232D964EF5@vpnc.org> References: <043754AD-BA58-4C9A-8491-114EE28E9F0E@vpnc.org> To: "ipsec@ietf.org WG" X-Mailer: Apple Mail (2.1816) Subject: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation 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, 25 Oct 2013 14:53:37 -0000 Although there is a spirited, useful discussion going on between three = or four participants, we could certainly use more reviewers for this WG = document. Please send any comments to the list, and feel free to hop = into the threads already running. Thanks! --Paul Hoffman= From yaronf.ietf@gmail.com Fri Oct 25 12:36:08 2013 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 F00F711E81CF; Fri, 25 Oct 2013 12:36:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+XWxXj5hvcT; Fri, 25 Oct 2013 12:36:07 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BE10C11E81CB; Fri, 25 Oct 2013 12:35:52 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so4215699wgh.13 for ; Fri, 25 Oct 2013 12:35:49 -0700 (PDT) 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=MTY8VntCg1ohpihmWatF9v6ad5kucyvn9Ml0fLu+wK8=; b=Dkj7t+K9kI9zzy2rx9k8UDbLOPpunGz/7/94/m6eABBaz9D2mJaRRL4M9Dsxarlc6n 7OvNIw6v7x5NkhZamMrOezOp9TSqd4KCkzRG4s/vzkGZ/Ut+vZdQ3qUNNrv2cypUjIWW X9OlIVau+nn3EUxpmXks9tZjEyJ69pcuN7gk1o4codGYV09RNkibu7TcR80Rkm/jmlTC 6LisEF0AgLCm3AWBbF3EWX2jyVbDQZ+MHoEeQ09eBJOWTWvalxrkWgVBzuBbkqiMDPRI gcR0GUBgb1I8N2uqvLt/uZDYJJWk/ZlxDY4LW4+t+ooeztz13lmi/HFVsJlx708dq+iR oAqQ== X-Received: by 10.194.109.68 with SMTP id hq4mr8839108wjb.12.1382729749040; Fri, 25 Oct 2013 12:35:49 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-177-145-22.red.bezeqint.net. [79.177.145.22]) by mx.google.com with ESMTPSA id i8sm9231920wiy.6.2013.10.25.12.35.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Oct 2013 12:35:48 -0700 (PDT) Message-ID: <526AC812.7070903@gmail.com> Date: Fri, 25 Oct 2013 22:35:46 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Paul Wouters , Valery Smyslov References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org WG" , tsv-ads@tools.ietf.org, tsvwg Subject: Re: [IPsec] TSVDIR-ish review ofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 25 Oct 2013 19:36:08 -0000 Hi Paul, Sorry for the late reply. You seem to assume that SPIs are random. This is not mandated by IKEv2 and in practice it is usually, but not always, the case. See http://www.ietf.org/mail-archive/web/ipsec/current/msg06563.html Thanks, Yaron On 2013-10-22 18:35, Paul Wouters wrote: > On Tue, 22 Oct 2013, Valery Smyslov wrote: > >>> attacks (e.g., overloading the receiver with false fragments). >> >> This attack is always possible both with and without fragmentation >> (just overloading with false full messages) and IKE is designed to >> withstand it. > > Partially. For unfragmented IKE, the cookies/SPI mitigate this if > you give preference to IKE messages further in the processing queue. > With this draft, I'm forced to do more crypto on IKE packets before I > can decide if these need prioritization or not (with the exception of > the first packet, which cannot get fragmented anyway) > >> Handling fragmentation in IKE doesn't make it more vulnerable to this >> attack. > > Handling encrypted fragments does, because you will spend more time > doing the crypto. Although this still happens after the cookie/spi > verification. You are doing an additional round of crypto on each fragment > in addition to the regular IKE crypto you need to perform on the assembled > packet. Fragments could be made artificially long and the IKE packet > artificial big, resulting in much more crypto. Now I think this might > not matter much, because the attacker needs to be local and they will > only be local to a remote endpoint which has enough CPU, not the ipsec > core gateway that actually might run out of CPU power when under attack. > >> On the other hand, handling fragmentation outside IKE (on IP level) >> or using unauthenticated fragments in IKE, makes it susceptible to an >> attack, >> described in the rationale, i.e. when attacker spending virtually zero >> resources >> can stop IKE communication by infrequently injecting bad fragments, >> which results in "poisoning" of reassembling queue. > > But the attack is theoretical and of no practical value. > > 1) on-path attacker (remote) > > They can just DOS you regardless by withholding packets. > > 2) off-path attacker (remote) > > These attackers don't know the cookies/spi's so they can't really sent > a forged fragment you would use for assembly - protected with crypto or > not. It is also impossible for them to time their attack so that one of > their fragments intersect with one of your fragments so they would need > to start sending fragments before the endpoint does but using mostly > wrong cookies/spis and would swamp an endpoint with easilly detectable > forged packets. > > 3) shared medium like wifi hotspot (local) > > These are the only attackers with enough knowledge to sent sufficiently > advanced bad fragments interfering with incoming fragments. They can > already do all the damage they want without resorting to IKE fragment > spoofing. They can arp spoof the gateway, sent a Wifi de-association > request, sent enough garbage to fill the air waves, and interfere with > the IKE in such a way that you think the remote peer does not support > fragmentation at all. So this draft protects against a local attacker > that wants to masquerade as a network failure and only prevent you from > doing IKE, hoping you will fall back to plaintext traffic. Software > could notify the user that they seem to be under attack, which IMHO > would be more valuable to the user than quiet resilience against the > attack. > >> Using authenticated fragments prevents this kind of attack. > > Yes, it prevents one of the low hanging fruits. Which I don't think is > worth the complexity of this draft compared to the existing > fragmentation code out in the wild. > >> But using IKE fragmentation in this case might eliminate this >> vulnerability. > > At the price of adding more complexity to IKE. With the attacker not > stopped from their goal. > >>> Additionally, regarding PMTUD, this should be done using PLMTUD (RFC >>> 4821), and should be described as such. >> >> IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based >> and RFC4821 has many restrictions when used with connectionless >> datagram protocols, some of which are often difficult to satisfy in >> environments, >> where IKE is used. Second, the goal of PLMTUD is to find _maximum_ >> MTU size that is not fragmented by IP, in other words, to maximize >> throughput. For IKE the goal of PMTUD is to find _any_reasonable_ >> MTU size that won't be fragmented by IP. Throughput is not important. >> Third, PMTU discovery in the draft is completely optional and one may >> use any other mechanisms (including PLMTUD, if it is available) >> to obtain MTU information. > > I agree. There is going to be like 2 to 4 fragments. Size does not > matter. It's better to cut down on latency/RTT by using an MTU size > that is for sure to work on the first go. > > But that's also why this complexity is not worth it. Fragmentation does > only mean going from 1 IKE packet to 2-4 IKE packets. The timeframe > to mess with these are in the 5ms range. If an attacker has that > accuracy against you, you've lost already regardless. I doubt the > attacker can even pull it off on wifi. > > The original IKE fragmentation is really nice and simple. Copy part of > the original IKE header, add a single payload with fragment payload > type and fragment number/max, sent fragments in a burst. > > This draft looks like it is fixing a security issue, while it really > should be just about sending smaller packets as similar as possible > to the original single packet. Messing with one IKE packet versus 2-4 > IKE packets is not a real problem that I think needs fixing. > > Paul > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Fri Oct 25 13:06:37 2013 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 7B5F911E81CB for ; Fri, 25 Oct 2013 13:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.45 X-Spam-Level: X-Spam-Status: No, score=-10.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4bPObEcxiSj for ; Fri, 25 Oct 2013 13:06:26 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 99BE811E810C for ; Fri, 25 Oct 2013 13:06:22 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9PK68Hl012526; Fri, 25 Oct 2013 23:06:12 +0300 X-CheckPoint: {526ACE72-1-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Fri, 25 Oct 2013 23:05:51 +0300 From: Yoav Nir To: Paul Hoffman Thread-Topic: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation Thread-Index: AQHO0ZH3tqC6ozrmIkG6vSPVxBH/VpoFpdUA Date: Fri, 25 Oct 2013 20:05:48 +0000 Message-ID: <0CBA2879-0369-4853-BE01-2235E28A48AB@checkpoint.com> References: <043754AD-BA58-4C9A-8491-114EE28E9F0E@vpnc.org> <664172B4-1C5D-46BA-BBEE-5C232D964EF5@vpnc.org> In-Reply-To: <664172B4-1C5D-46BA-BBEE-5C232D964EF5@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.169] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <6CDC5DA01854D64C869559D488111888@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation 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, 25 Oct 2013 20:06:38 -0000 Hi I think the draft is in good shape and is almost ready for publication. The= re is a bunch of grammatical issues with it, but I think the RFC editor is = much better at fixing those than most of us. Section 2.5.1 recommends using 1280-byte max IP datagram size for IPv6 (bas= ed on RFC 2460), and 576 bytes (based on RFC 1122). The big difference betw= een those two RFCs is not some technical difference between IPv6 and IPv4, = but that the former was written in 1998 while the latter is from 1989. By 1= 998 it was reasonable to mandate infrastructure that could handle 1280-byte= datagrams. This has become more true, not less in the 15 years since RFC 2= 460. Pretty much all networks today can carry IPv6, and any network that ca= n carry 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4 packe= ts. I don't think there's any point in still making this distinction today. Lastly, some nits: Section 2.1:=20 OLD: The idea of the protocol is to split large IKE message into the set of smaller ones, calling IKE Fragment Messages. NEW: The idea of the protocol is to split large IKE message into a set of smaller ones, called IKE Fragment Messages. Section 2.5: OLD: o Total Fragments (2 octets) - number of fragments original message was divided into. With PMTU discovery this field plays additional role. See Section 2.5.2 for details. This field MUST NOT be zero. NEW: o Total Fragments (2 octets) - number of fragments original message was divided into. With PMTU discovery this field plays additional role. See Section 2.5.2 for details. This field MUST NOT be zero or one.= From touch@isi.edu Fri Oct 25 13:18:51 2013 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 08A6011E814F; Fri, 25 Oct 2013 13:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.54 X-Spam-Level: X-Spam-Status: No, score=-103.54 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wNQMFLIwQH9i; Fri, 25 Oct 2013 13:18:45 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7FE11E8145; Fri, 25 Oct 2013 13:18:45 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r9PKI1RM016453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Oct 2013 13:18:01 -0700 (PDT) Message-ID: <526AD233.3090109@isi.edu> Date: Fri, 25 Oct 2013 13:18:59 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Valery Smyslov References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg , tsv-ads@tools.ietf.org, Martin Stiemerling , ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 25 Oct 2013 20:18:51 -0000 On 10/24/2013 10:45 PM, Valery Smyslov wrote: ... >> You're using existing IKE messages *and* existing timeouts to >> determine when there is a problem. A separate timer would be useful, >> if only to allow you to decouple fragment retransmission from IKE >> transaction retries. > > No, the timeouts are different. I should have made it more expplicit in > the draft. That'd be useful. ... > Always setting DF bit in this case will probably increase the delay > before IKE SA is set up (as more probes will need to be done). Except that if you continue to allow IP fragmentation, you can't claim your solution is robust to IP fragment poisoning. >>> Note, that this approach is in line with advices, given for IKE in the >>> paper >>> >>> C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection >>> for UDP-based protocols", ACM Conference on Computer and >>> Communications Security, October 2003. >> >> That paper doesn't consider IKE-level fragmentation, which you're >> introducing. I agree that DF=0 for IKE without IKE-level fragmentation. > > It does, in Section 3.3. Sorry - I missed that. But that section also gives good reasons why this is a bad idea in IKE too. Joe From yaronf.ietf@gmail.com Fri Oct 25 13:23:39 2013 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 7155611E8156 for ; Fri, 25 Oct 2013 13:23:39 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpkAUDicwZeV for ; Fri, 25 Oct 2013 13:23:39 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id BF23C11E8152 for ; Fri, 25 Oct 2013 13:23:38 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so1360576wgh.2 for ; Fri, 25 Oct 2013 13:23:37 -0700 (PDT) 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=cHGa+RV3FmssE++4TKFYx7QjFiDlGiNYSBILljFH7nQ=; b=N7B1qRxUrGSm3yoJT1YfiqxoH0/ChCcrSR+4Tu/u5pavFc82XsrkqNrrCXoiptufEW f1kNtHgsSKSRAraBNvMgkffGmjDeOWn1Dl4EsW+aPfQRJ0dGyC3r0JxbUkiJ6wKF1VfY LyeWuZfEExe0ipIXpJH2JjElXDLxkjmz9W4iUL+0GmofJy/Oh5W0MpeUPZqJV7OwS9Rt 0TXaPn++SP957c/i5A4X2LH6c0WcF4QtJZmSAij0DyhQYbZtXDSyW8D+E2lVsJFq9Kp2 yQ/8VzfN6M6Fgp2cWQJNbO2ruCcTYoQ4pxNLN8HPnC3AJNm+B+IwlfjmUcDHRVSJS9wG RcpA== X-Received: by 10.180.9.134 with SMTP id z6mr24076wia.9.1382732617439; Fri, 25 Oct 2013 13:23:37 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-177-145-22.red.bezeqint.net. [79.177.145.22]) by mx.google.com with ESMTPSA id d10sm9582131wic.2.2013.10.25.13.23.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Oct 2013 13:23:37 -0700 (PDT) Message-ID: <526AD347.8040304@gmail.com> Date: Fri, 25 Oct 2013 23:23:35 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Yoav Nir , Paul Hoffman References: <043754AD-BA58-4C9A-8491-114EE28E9F0E@vpnc.org> <664172B4-1C5D-46BA-BBEE-5C232D964EF5@vpnc.org> <0CBA2879-0369-4853-BE01-2235E28A48AB@checkpoint.com> In-Reply-To: <0CBA2879-0369-4853-BE01-2235E28A48AB@checkpoint.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation 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, 25 Oct 2013 20:23:39 -0000 On 2013-10-25 23:05, Yoav Nir wrote: > Hi > [...] > > Section 2.5.1 recommends using 1280-byte max IP datagram size for > IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big > difference between those two RFCs is not some technical difference > between IPv6 and IPv4, but that the former was written in 1998 while > the latter is from 1989. By 1998 it was reasonable to mandate > infrastructure that could handle 1280-byte datagrams. This has become > more true, not less in the 15 years since RFC 2460. Pretty much all > networks today can carry IPv6, and any network that can carry > 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4 > packets. I don't think there's any point in still making this > distinction today. > > This draft is about broken networks/devices that are unable to handle IPv4 fragments. Can we really assume that they can carry IPv6 traffic? Yes, RFC 1122 is very old, but if we recommend a larger size I would like to see better justification. Thanks, Yaron From ynir@checkpoint.com Fri Oct 25 13:52:22 2013 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 49DB321F9CF3 for ; Fri, 25 Oct 2013 13:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.455 X-Spam-Level: X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWdJNq8V2UGW for ; Fri, 25 Oct 2013 13:52:16 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1E111E8219 for ; Fri, 25 Oct 2013 13:52:10 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9PKpppR020547; Fri, 25 Oct 2013 23:51:51 +0300 X-CheckPoint: {526AD929-2-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Fri, 25 Oct 2013 23:51:34 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation Thread-Index: AQHO0ZH3tqC6ozrmIkG6vSPVxBH/VpoFpdUAgAAE5YCAAAfkgA== Date: Fri, 25 Oct 2013 20:51:32 +0000 Message-ID: <6CDEBB3C-68C1-4D33-BB61-A3263BBFFCB2@checkpoint.com> References: <043754AD-BA58-4C9A-8491-114EE28E9F0E@vpnc.org> <664172B4-1C5D-46BA-BBEE-5C232D964EF5@vpnc.org> <0CBA2879-0369-4853-BE01-2235E28A48AB@checkpoint.com> <526AD347.8040304@gmail.com> In-Reply-To: <526AD347.8040304@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.169] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <5FF94523C9680543816827638E86626A@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" , Paul Hoffman Subject: Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation 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, 25 Oct 2013 20:52:22 -0000 On Oct 25, 2013, at 11:23 PM, Yaron Sheffer wrote: >>=20 >> Section 2.5.1 recommends using 1280-byte max IP datagram size for >> IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big >> difference between those two RFCs is not some technical difference >> between IPv6 and IPv4, but that the former was written in 1998 while >> the latter is from 1989. By 1998 it was reasonable to mandate >> infrastructure that could handle 1280-byte datagrams. This has become >> more true, not less in the 15 years since RFC 2460. Pretty much all >> networks today can carry IPv6, and any network that can carry >> 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4 >> packets. I don't think there's any point in still making this >> distinction today. >>=20 >>=20 > This draft is about broken networks/devices that are unable to handle IPv= 4 fragments. Can we really assume that they can carry IPv6 traffic? >=20 > Yes, RFC 1122 is very old, but if we recommend a larger size I would like= to see better justification. The original IKEv1 fragments were inspired by broken home routers that woul= dn't keep enough state to NAT fragments. They still worked on Ethernet and = 802.11 and had 1500-byte MTU. The current work was inspired by CGNs doing the same thing. They also deal = with 1500-byte Ethernet. 1280 leaves room for various tunnels, encapsulations and what not.=20 Of course, if your implementation is running in some constrained environmen= t (like the Internet of Things on 802.15.4) you may need different MTUs. Bu= t on the open Internet? You just don't see PMTUs that small anymore. Yoav From yaronf.ietf@gmail.com Sat Oct 26 02:15:23 2013 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 A59EE11E8149 for ; Sat, 26 Oct 2013 02:15:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz12d2c0D-19 for ; Sat, 26 Oct 2013 02:15:17 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 053F011E810F for ; Sat, 26 Oct 2013 02:15:02 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so4836105wes.1 for ; Sat, 26 Oct 2013 02:15:01 -0700 (PDT) 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=L/Kv/7tJIahLXesOTba2mRAg+lEQC01zZuarLkG4xpU=; b=vheXDIo4DzookO29b+YKDnYDyXz5qlir/mxG6tCacTax7I+lF7ikeChHW17mr2ZcHm vMKLdU1UjbYk/6XXi/A2ZlEYmyaPZjvu/0GQ3aBalI0EJRSD5OiH15iSP9CJOvNUr7oT 4qNtpcY1U0qg4/usbPqOwrSQXHWEMJeRWgUnbpDJO52Iw+ASiAmeC4R3Fjz0lihSyEKP tb+nVad9c3FhLNDdzG1bPFtmJS9kap5zGdLuLHz4yUDf93Z7q4MgINXACiP935iBzSjL gOzG7rrPASOkyM9rmclf8tQVktTF+x7GMaBrfofiwsdJ+IS+3yCpcBJNvhDgkCt3N8Hx xD7w== X-Received: by 10.194.94.167 with SMTP id dd7mr10783702wjb.43.1382778901376; Sat, 26 Oct 2013 02:15:01 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-177-145-22.red.bezeqint.net. [79.177.145.22]) by mx.google.com with ESMTPSA id fb4sm14221471wib.8.2013.10.26.02.15.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Oct 2013 02:15:00 -0700 (PDT) Message-ID: <526B8811.40107@gmail.com> Date: Sat, 26 Oct 2013 12:14:57 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Yoav Nir References: <043754AD-BA58-4C9A-8491-114EE28E9F0E@vpnc.org> <664172B4-1C5D-46BA-BBEE-5C232D964EF5@vpnc.org> <0CBA2879-0369-4853-BE01-2235E28A48AB@checkpoint.com> <526AD347.8040304@gmail.com> <6CDEBB3C-68C1-4D33-BB61-A3263BBFFCB2@checkpoint.com> In-Reply-To: <6CDEBB3C-68C1-4D33-BB61-A3263BBFFCB2@checkpoint.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "ipsec@ietf.org WG" , Paul Hoffman Subject: Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation 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, 26 Oct 2013 09:15:23 -0000 On 2013-10-25 23:51, Yoav Nir wrote: > > On Oct 25, 2013, at 11:23 PM, Yaron Sheffer wrote: > >>> >>> Section 2.5.1 recommends using 1280-byte max IP datagram size for >>> IPv6 (based on RFC 2460), and 576 bytes (based on RFC 1122). The big >>> difference between those two RFCs is not some technical difference >>> between IPv6 and IPv4, but that the former was written in 1998 while >>> the latter is from 1989. By 1998 it was reasonable to mandate >>> infrastructure that could handle 1280-byte datagrams. This has become >>> more true, not less in the 15 years since RFC 2460. Pretty much all >>> networks today can carry IPv6, and any network that can carry >>> 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4 >>> packets. I don't think there's any point in still making this >>> distinction today. >>> >>> >> This draft is about broken networks/devices that are unable to handle IPv4 fragments. Can we really assume that they can carry IPv6 traffic? >> >> Yes, RFC 1122 is very old, but if we recommend a larger size I would like to see better justification. > > The original IKEv1 fragments were inspired by broken home routers that wouldn't keep enough state to NAT fragments. They still worked on Ethernet and 802.11 and had 1500-byte MTU. > > The current work was inspired by CGNs doing the same thing. They also deal with 1500-byte Ethernet. > > 1280 leaves room for various tunnels, encapsulations and what not. > > Of course, if your implementation is running in some constrained environment (like the Internet of Things on 802.15.4) you may need different MTUs. But on the open Internet? You just don't see PMTUs that small anymore. > > Yoav > If we give a recommendation, I think it should be based on measured data. See for example Sec. 5.5 of http://nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf‎ Thanks, Yaron From ynir@checkpoint.com Sat Oct 26 04:26:35 2013 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 CD6CE11E8112 for ; Sat, 26 Oct 2013 04:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.459 X-Spam-Level: X-Spam-Status: No, score=-10.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izx2K6Oa9w-q for ; Sat, 26 Oct 2013 04:26:28 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A77FB21F9FAE for ; Sat, 26 Oct 2013 04:26:22 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9QBQIxf020500; Sat, 26 Oct 2013 14:26:18 +0300 X-CheckPoint: {526BA612-12-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sat, 26 Oct 2013 14:26:01 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation Thread-Index: AQHO0ZH3tqC6ozrmIkG6vSPVxBH/VpoFpdUAgAAE5YCAAAfkgIAAz6GAgAAktoA= Date: Sat, 26 Oct 2013 11:25:58 +0000 Message-ID: <90FF1C19-6D3F-4019-82E2-A9BD480C24FB@checkpoint.com> References: <043754AD-BA58-4C9A-8491-114EE28E9F0E@vpnc.org> <664172B4-1C5D-46BA-BBEE-5C232D964EF5@vpnc.org> <0CBA2879-0369-4853-BE01-2235E28A48AB@checkpoint.com> <526AD347.8040304@gmail.com> <6CDEBB3C-68C1-4D33-BB61-A3263BBFFCB2@checkpoint.com> <526B8811.40107@gmail.com> In-Reply-To: <526B8811.40107@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.3] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" , Paul Hoffman Subject: Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation 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, 26 Oct 2013 11:26:35 -0000 DQpPbiBPY3QgMjYsIDIwMTMsIGF0IDEyOjE0IFBNLCBZYXJvbiBTaGVmZmVyIDx5YXJvbmYuaWV0 ZkBnbWFpbC5jb20+IHdyb3RlOg0KDQo+IA0KPiANCj4gT24gMjAxMy0xMC0yNSAyMzo1MSwgWW9h diBOaXIgd3JvdGU6DQo+PiANCj4+IE9uIE9jdCAyNSwgMjAxMywgYXQgMTE6MjMgUE0sIFlhcm9u IFNoZWZmZXIgPHlhcm9uZi5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+PiANCj4+Pj4gDQo+Pj4+ IFNlY3Rpb24gMi41LjEgcmVjb21tZW5kcyB1c2luZyAxMjgwLWJ5dGUgbWF4IElQIGRhdGFncmFt IHNpemUgZm9yDQo+Pj4+IElQdjYgKGJhc2VkIG9uIFJGQyAyNDYwKSwgYW5kIDU3NiBieXRlcyAo YmFzZWQgb24gUkZDIDExMjIpLiBUaGUgYmlnDQo+Pj4+IGRpZmZlcmVuY2UgYmV0d2VlbiB0aG9z ZSB0d28gUkZDcyBpcyBub3Qgc29tZSB0ZWNobmljYWwgZGlmZmVyZW5jZQ0KPj4+PiBiZXR3ZWVu IElQdjYgYW5kIElQdjQsIGJ1dCB0aGF0IHRoZSBmb3JtZXIgd2FzIHdyaXR0ZW4gaW4gMTk5OCB3 aGlsZQ0KPj4+PiB0aGUgbGF0dGVyIGlzIGZyb20gMTk4OS4gQnkgMTk5OCBpdCB3YXMgcmVhc29u YWJsZSB0byBtYW5kYXRlDQo+Pj4+IGluZnJhc3RydWN0dXJlIHRoYXQgY291bGQgaGFuZGxlIDEy ODAtYnl0ZSBkYXRhZ3JhbXMuIFRoaXMgaGFzIGJlY29tZQ0KPj4+PiBtb3JlIHRydWUsIG5vdCBs ZXNzIGluIHRoZSAxNSB5ZWFycyBzaW5jZSBSRkMgMjQ2MC4gUHJldHR5IG11Y2ggYWxsDQo+Pj4+ IG5ldHdvcmtzIHRvZGF5IGNhbiBjYXJyeSBJUHY2LCBhbmQgYW55IG5ldHdvcmsgdGhhdCBjYW4g Y2FycnkNCj4+Pj4gMTI4MC1ieXRlIElQdjYgcGFja2V0cywgY2FuIGp1c3QgYXMgd2VsbCBjYXJy eSAxMjgwLWJ5dGUgSVB2NA0KPj4+PiBwYWNrZXRzLiBJIGRvbid0IHRoaW5rIHRoZXJlJ3MgYW55 IHBvaW50IGluIHN0aWxsIG1ha2luZyB0aGlzDQo+Pj4+IGRpc3RpbmN0aW9uIHRvZGF5Lg0KPj4+ PiANCj4+Pj4gDQo+Pj4gVGhpcyBkcmFmdCBpcyBhYm91dCBicm9rZW4gbmV0d29ya3MvZGV2aWNl cyB0aGF0IGFyZSB1bmFibGUgdG8gaGFuZGxlIElQdjQgZnJhZ21lbnRzLiBDYW4gd2UgcmVhbGx5 IGFzc3VtZSB0aGF0IHRoZXkgY2FuIGNhcnJ5IElQdjYgdHJhZmZpYz8NCj4+PiANCj4+PiBZZXMs IFJGQyAxMTIyIGlzIHZlcnkgb2xkLCBidXQgaWYgd2UgcmVjb21tZW5kIGEgbGFyZ2VyIHNpemUg SSB3b3VsZCBsaWtlIHRvIHNlZSBiZXR0ZXIganVzdGlmaWNhdGlvbi4NCj4+IA0KPj4gVGhlIG9y aWdpbmFsIElLRXYxIGZyYWdtZW50cyB3ZXJlIGluc3BpcmVkIGJ5IGJyb2tlbiBob21lIHJvdXRl cnMgdGhhdCB3b3VsZG4ndCBrZWVwIGVub3VnaCBzdGF0ZSB0byBOQVQgZnJhZ21lbnRzLiBUaGV5 IHN0aWxsIHdvcmtlZCBvbiBFdGhlcm5ldCBhbmQgODAyLjExIGFuZCBoYWQgMTUwMC1ieXRlIE1U VS4NCj4+IA0KPj4gVGhlIGN1cnJlbnQgd29yayB3YXMgaW5zcGlyZWQgYnkgQ0dOcyBkb2luZyB0 aGUgc2FtZSB0aGluZy4gVGhleSBhbHNvIGRlYWwgd2l0aCAxNTAwLWJ5dGUgRXRoZXJuZXQuDQo+ PiANCj4+IDEyODAgbGVhdmVzIHJvb20gZm9yIHZhcmlvdXMgdHVubmVscywgZW5jYXBzdWxhdGlv bnMgYW5kIHdoYXQgbm90Lg0KPj4gDQo+PiBPZiBjb3Vyc2UsIGlmIHlvdXIgaW1wbGVtZW50YXRp b24gaXMgcnVubmluZyBpbiBzb21lIGNvbnN0cmFpbmVkIGVudmlyb25tZW50IChsaWtlIHRoZSBJ bnRlcm5ldCBvZiBUaGluZ3Mgb24gODAyLjE1LjQpIHlvdSBtYXkgbmVlZCBkaWZmZXJlbnQgTVRV cy4gQnV0IG9uIHRoZSBvcGVuIEludGVybmV0PyBZb3UganVzdCBkb24ndCBzZWUgUE1UVXMgdGhh dCBzbWFsbCBhbnltb3JlLg0KPj4gDQo+PiBZb2F2DQo+PiANCj4gSWYgd2UgZ2l2ZSBhIHJlY29t bWVuZGF0aW9uLCBJIHRoaW5rIGl0IHNob3VsZCBiZSBiYXNlZCBvbiBtZWFzdXJlZCBkYXRhLiBT ZWUgZm9yIGV4YW1wbGUgU2VjLiA1LjUgb2YgaHR0cDovL25sbmV0bGFicy5ubC9kb3dubG9hZHMv cHVibGljYXRpb25zL3BtdHUtYmxhY2staG9sZXMtbXNjLXRoZXNpcy5wZGbigI4NCj4gDQoNClRo YW5rcyBmb3IgdGhlIGxpbmsuIEFuZCBvbmx5IDEgKG91dCBvZiA+MTE1MCkgcHJvYmVzIGZvdW5k IGEgUE1UVSBpbiBJUHY0IHNtYWxsZXIgdGhhbiAxMjgwLCBhbmQgdGhhdCB3YXMgMTI4MC4gTW9y ZSB0aGFuIDIvMyB3ZXJlIGV4YWN0bHkgMTUwMCwgYW5kIHRoZSB2YXN0IG1ham9yaXR5IHdhcyBv dmVyIDE0MDAuDQoNClNtYWxsZXN0IHRoZXkgZm91bmQgd2FzIDEyNDAuIEFueSByZWFzb24gdG8g c2V0IHRoZSBsaW1pdCAobXVjaCkgYmVsb3cgdGhhdD8NCg0KWW9hdg0KDQo= From ynir@checkpoint.com Sat Oct 26 05:52:59 2013 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 0B01011E8117 for ; Sat, 26 Oct 2013 05:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvrgBnlrEInW for ; Sat, 26 Oct 2013 05:52:54 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 58BAE11E817F for ; Sat, 26 Oct 2013 05:52:53 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9QCqosv029695; Sat, 26 Oct 2013 15:52:50 +0300 X-CheckPoint: {526BBA5A-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sat, 26 Oct 2013 15:52:33 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation Thread-Index: AQHO0ZH3tqC6ozrmIkG6vSPVxBH/VpoFpdUAgAAE5YCAAAfkgIAAz6GAgAAktoCAABgsAA== Date: Sat, 26 Oct 2013 12:52:29 +0000 Message-ID: <1A851EB9-072E-4593-A94D-9A4FC5920CA0@checkpoint.com> References: <043754AD-BA58-4C9A-8491-114EE28E9F0E@vpnc.org> <664172B4-1C5D-46BA-BBEE-5C232D964EF5@vpnc.org> <0CBA2879-0369-4853-BE01-2235E28A48AB@checkpoint.com> <526AD347.8040304@gmail.com> <6CDEBB3C-68C1-4D33-BB61-A3263BBFFCB2@checkpoint.com> <526B8811.40107@gmail.com> <90FF1C19-6D3F-4019-82E2-A9BD480C24FB@checkpoint.com> In-Reply-To: <90FF1C19-6D3F-4019-82E2-A9BD480C24FB@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.3] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="utf-8" Content-ID: <7DCF9FD013E6B14FBCBC7E605488F611@ad.checkpoint.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" , Paul Hoffman Subject: Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation 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, 26 Oct 2013 12:52:59 -0000 DQpPbiBPY3QgMjYsIDIwMTMsIGF0IDI6MjUgUE0sIFlvYXYgTmlyIDx5bmlyQGNoZWNrcG9pbnQu Y29tPiB3cm90ZToNCg0KPiANCj4gT24gT2N0IDI2LCAyMDEzLCBhdCAxMjoxNCBQTSwgWWFyb24g U2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+PiANCj4+IA0KPj4g T24gMjAxMy0xMC0yNSAyMzo1MSwgWW9hdiBOaXIgd3JvdGU6DQo+Pj4gDQo+Pj4gT24gT2N0IDI1 LCAyMDEzLCBhdCAxMToyMyBQTSwgWWFyb24gU2hlZmZlciA8eWFyb25mLmlldGZAZ21haWwuY29t PiB3cm90ZToNCj4+PiANCj4+Pj4+IA0KPj4+Pj4gU2VjdGlvbiAyLjUuMSByZWNvbW1lbmRzIHVz aW5nIDEyODAtYnl0ZSBtYXggSVAgZGF0YWdyYW0gc2l6ZSBmb3INCj4+Pj4+IElQdjYgKGJhc2Vk IG9uIFJGQyAyNDYwKSwgYW5kIDU3NiBieXRlcyAoYmFzZWQgb24gUkZDIDExMjIpLiBUaGUgYmln DQo+Pj4+PiBkaWZmZXJlbmNlIGJldHdlZW4gdGhvc2UgdHdvIFJGQ3MgaXMgbm90IHNvbWUgdGVj aG5pY2FsIGRpZmZlcmVuY2UNCj4+Pj4+IGJldHdlZW4gSVB2NiBhbmQgSVB2NCwgYnV0IHRoYXQg dGhlIGZvcm1lciB3YXMgd3JpdHRlbiBpbiAxOTk4IHdoaWxlDQo+Pj4+PiB0aGUgbGF0dGVyIGlz IGZyb20gMTk4OS4gQnkgMTk5OCBpdCB3YXMgcmVhc29uYWJsZSB0byBtYW5kYXRlDQo+Pj4+PiBp bmZyYXN0cnVjdHVyZSB0aGF0IGNvdWxkIGhhbmRsZSAxMjgwLWJ5dGUgZGF0YWdyYW1zLiBUaGlz IGhhcyBiZWNvbWUNCj4+Pj4+IG1vcmUgdHJ1ZSwgbm90IGxlc3MgaW4gdGhlIDE1IHllYXJzIHNp bmNlIFJGQyAyNDYwLiBQcmV0dHkgbXVjaCBhbGwNCj4+Pj4+IG5ldHdvcmtzIHRvZGF5IGNhbiBj YXJyeSBJUHY2LCBhbmQgYW55IG5ldHdvcmsgdGhhdCBjYW4gY2FycnkNCj4+Pj4+IDEyODAtYnl0 ZSBJUHY2IHBhY2tldHMsIGNhbiBqdXN0IGFzIHdlbGwgY2FycnkgMTI4MC1ieXRlIElQdjQNCj4+ Pj4+IHBhY2tldHMuIEkgZG9uJ3QgdGhpbmsgdGhlcmUncyBhbnkgcG9pbnQgaW4gc3RpbGwgbWFr aW5nIHRoaXMNCj4+Pj4+IGRpc3RpbmN0aW9uIHRvZGF5Lg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4g VGhpcyBkcmFmdCBpcyBhYm91dCBicm9rZW4gbmV0d29ya3MvZGV2aWNlcyB0aGF0IGFyZSB1bmFi bGUgdG8gaGFuZGxlIElQdjQgZnJhZ21lbnRzLiBDYW4gd2UgcmVhbGx5IGFzc3VtZSB0aGF0IHRo ZXkgY2FuIGNhcnJ5IElQdjYgdHJhZmZpYz8NCj4+Pj4gDQo+Pj4+IFllcywgUkZDIDExMjIgaXMg dmVyeSBvbGQsIGJ1dCBpZiB3ZSByZWNvbW1lbmQgYSBsYXJnZXIgc2l6ZSBJIHdvdWxkIGxpa2Ug dG8gc2VlIGJldHRlciBqdXN0aWZpY2F0aW9uLg0KPj4+IA0KPj4+IFRoZSBvcmlnaW5hbCBJS0V2 MSBmcmFnbWVudHMgd2VyZSBpbnNwaXJlZCBieSBicm9rZW4gaG9tZSByb3V0ZXJzIHRoYXQgd291 bGRuJ3Qga2VlcCBlbm91Z2ggc3RhdGUgdG8gTkFUIGZyYWdtZW50cy4gVGhleSBzdGlsbCB3b3Jr ZWQgb24gRXRoZXJuZXQgYW5kIDgwMi4xMSBhbmQgaGFkIDE1MDAtYnl0ZSBNVFUuDQo+Pj4gDQo+ Pj4gVGhlIGN1cnJlbnQgd29yayB3YXMgaW5zcGlyZWQgYnkgQ0dOcyBkb2luZyB0aGUgc2FtZSB0 aGluZy4gVGhleSBhbHNvIGRlYWwgd2l0aCAxNTAwLWJ5dGUgRXRoZXJuZXQuDQo+Pj4gDQo+Pj4g MTI4MCBsZWF2ZXMgcm9vbSBmb3IgdmFyaW91cyB0dW5uZWxzLCBlbmNhcHN1bGF0aW9ucyBhbmQg d2hhdCBub3QuDQo+Pj4gDQo+Pj4gT2YgY291cnNlLCBpZiB5b3VyIGltcGxlbWVudGF0aW9uIGlz IHJ1bm5pbmcgaW4gc29tZSBjb25zdHJhaW5lZCBlbnZpcm9ubWVudCAobGlrZSB0aGUgSW50ZXJu ZXQgb2YgVGhpbmdzIG9uIDgwMi4xNS40KSB5b3UgbWF5IG5lZWQgZGlmZmVyZW50IE1UVXMuIEJ1 dCBvbiB0aGUgb3BlbiBJbnRlcm5ldD8gWW91IGp1c3QgZG9uJ3Qgc2VlIFBNVFVzIHRoYXQgc21h bGwgYW55bW9yZS4NCj4+PiANCj4+PiBZb2F2DQo+Pj4gDQo+PiBJZiB3ZSBnaXZlIGEgcmVjb21t ZW5kYXRpb24sIEkgdGhpbmsgaXQgc2hvdWxkIGJlIGJhc2VkIG9uIG1lYXN1cmVkIGRhdGEuIFNl ZSBmb3IgZXhhbXBsZSBTZWMuIDUuNSBvZiBodHRwOi8vbmxuZXRsYWJzLm5sL2Rvd25sb2Fkcy9w dWJsaWNhdGlvbnMvcG10dS1ibGFjay1ob2xlcy1tc2MtdGhlc2lzLnBkZuKAjg0KPj4gDQo+IA0K PiBUaGFua3MgZm9yIHRoZSBsaW5rLiBBbmQgb25seSAxIChvdXQgb2YgPjExNTApIHByb2JlcyBm b3VuZCBhIFBNVFUgaW4gSVB2NCBzbWFsbGVyIHRoYW4gMTI4MCwgYW5kIHRoYXQgd2FzIDEyODAu IE1vcmUgdGhhbiAyLzMgd2VyZSBleGFjdGx5IDE1MDAsIGFuZCB0aGUgdmFzdCBtYWpvcml0eSB3 YXMgb3ZlciAxNDAwLg0KPiANCj4gU21hbGxlc3QgdGhleSBmb3VuZCB3YXMgMTI0MC4gQW55IHJl YXNvbiB0byBzZXQgdGhlIGxpbWl0IChtdWNoKSBiZWxvdyB0aGF0Pw0KPiANCg0Kcy9hbmQgdGhh dCB3YXMgMTI4MC9hbmQgdGhhdCB3YXMgMTI0MC8NCg0KDQo= From yaronf.ietf@gmail.com Sat Oct 26 06:17:14 2013 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 9857D21F9F31 for ; Sat, 26 Oct 2013 06:17:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmUecmPDMFd0 for ; Sat, 26 Oct 2013 06:17:13 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7913611E814C for ; Sat, 26 Oct 2013 06:17:11 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t60so4869358wes.16 for ; Sat, 26 Oct 2013 06:17:10 -0700 (PDT) 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=gYPX/saFHHeropV7k8KIPZByXAPDznBwEBe6hVRDyxw=; b=hWO2snH9TxdZQNRZZCLwloUclRUF4MTEMJB6D6NYmUSI5BT3CVy/f2IAQray8UJdL3 Xc3buEpxT6oM9HKMjRTLgeInK1srg6u0t0H5ZsemkM76RTsE0zO4ZAH0/EcEHs6b2v+p wXFsz1TGP9xhtWn0u57T5HaujyYQ2zj4iKC0InJW81gUPTRxHnhyWnnRra5rNXjhOqiI tQuuh+oWgQc3sPiXIWfBU/S+jtnPsZ4YCKyjDqDbqbTiWgunrS4fGiNaBjrZn1NRekI/ DBAKg2oUWmpb4jG6ibXnvNDkdtPdxVrzU98kjSLmy9aNR3MymihKOKpxefajnLYO4Sj9 zRVQ== X-Received: by 10.194.20.170 with SMTP id o10mr11355576wje.4.1382793430381; Sat, 26 Oct 2013 06:17:10 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-177-145-22.red.bezeqint.net. [79.177.145.22]) by mx.google.com with ESMTPSA id ma3sm16084988wic.1.2013.10.26.06.17.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 26 Oct 2013 06:17:10 -0700 (PDT) Message-ID: <526BC0D2.6020101@gmail.com> Date: Sat, 26 Oct 2013 16:17:06 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Yoav Nir References: <043754AD-BA58-4C9A-8491-114EE28E9F0E@vpnc.org> <664172B4-1C5D-46BA-BBEE-5C232D964EF5@vpnc.org> <0CBA2879-0369-4853-BE01-2235E28A48AB@checkpoint.com> <526AD347.8040304@gmail.com> <6CDEBB3C-68C1-4D33-BB61-A3263BBFFCB2@checkpoint.com> <526B8811.40107@gmail.com> <90FF1C19-6D3F-4019-82E2-A9BD480C24FB@checkpoint.com> <1A851EB9-072E-4593-A94D-9A4FC5920CA0@checkpoint.com> In-Reply-To: <1A851EB9-072E-4593-A94D-9A4FC5920CA0@checkpoint.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "ipsec@ietf.org WG" , Paul Hoffman Subject: Re: [IPsec] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation 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, 26 Oct 2013 13:17:14 -0000 >>>> >>> If we give a recommendation, I think it should be based on >>> measured data. See for example Sec. 5.5 of >>> http://nlnetlabs.nl/downloads/publications/pmtu-black-holes-msc-thesis.pdf‎ >>> >> >> >>> Thanks for the link. And only 1 (out of >1150) probes found a PMTU in IPv4 smaller than 1280, and that was 1280. More than 2/3 were exactly 1500, and the vast majority was over 1400. >> >> Smallest they found was 1240. Any reason to set the limit (much) >> below that? >> > > s/and that was 1280/and that was 1240/ > > If we think this experiment is serious (e.g. that it covers much of the Internet, note that 1150 probes is a very small number), then we can recommend 1280 and cite this reference. Alternatively, we could ask the folks at TSVWG or IPPM. I am not familiar with current large scale Internet measurement efforts. But you an I have one such project nearby: http://www.netdimes.org/new/. I will ping them. Thanks, Yaron From mattmathis@google.com Fri Oct 25 13:41:08 2013 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 266AF11E8152 for ; Fri, 25 Oct 2013 13:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5AP9F+tHbabU for ; Fri, 25 Oct 2013 13:41:07 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A4EF411E8108 for ; Fri, 25 Oct 2013 13:41:06 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id x13so7555904ief.9 for ; Fri, 25 Oct 2013 13:41:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UQTVFtRNXd9LQbN5lbw7sNy8vGgA4GqkNfJUSR/ZJ+g=; b=Xnw2CTlxmWL9z7tJLINkk/w+F+orLF0qqd3MDVo26ijBUVU0L7Ht7pbJXdpxlcYgSW nZ/CKSTmLy2bmTdLdzlanLjQV1sqLRQzC3ymdMQ46s4vWgP6mpq1j7vR307UVnGanw0e u4yQKiZpdnsc7e8xJ1o1TWE29Ga1pDQtahplT0exlouZzogiIiigp6LcMcr3AWGSI1Ky ayg7n5Vx47jugHJNIiNY1Uq0UaR/p40VH2ou5BpajPeplGwZkU2Rs79Parp1Xrxt+N9q G0f9xoQ0bsDmgxECBbEg054md++C4BWxWvhMo4LEAzfUzTiy9KPLayJO1vjPqf1Un1eZ NxUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UQTVFtRNXd9LQbN5lbw7sNy8vGgA4GqkNfJUSR/ZJ+g=; b=m+fWtuBA1XDkBRoAw5BIWaTgfKCqo/M5kntOf6kfbIbmGbr/v3GXc8Cxgf/b529XXv DIAu6vKznpvTr5Yw1bEtPoCAmUqS8npgjNucNoDP3X7l8QQV+E4vVE40UX4PnL7Tvb65 Nv0VoxhqzxcY8GvEzllq6hmMbMWfhhuQ92pfNYTyv7TrSNagy1fIPHL+oUOx6UHopxYe 0e4aj/7y2hUIBCDoRoHB63TiZ1/BQYMLLt8m8UVxlue/bDdWml/n2JfzwdQoTHOSkqkV dsXHowqW6lQPw86OQp+MVqjcsVYYfo9/Sv5EV4avMOI6kfqTwkMBa+nVN7czlYDk+7sm kouA== X-Gm-Message-State: ALoCoQmmBnEJ5MGzh0FTbATVn05bvTZM/N4CPSGgh8WjcrODFnJHotyPAVc2D4lVLYhrRs4dHPZAHNuQpAUKdFTLod5Qpxm97ZFkPp/Xp2gJOqJwShne6OSSF9VtcY0JmRX1A2EJuwE5tbz9ekP3pegfruHWjtxOAgfcdTmccNagLfSSl1Qje7Pm5SHIUPJwthBL7ZV0dJ0S MIME-Version: 1.0 X-Received: by 10.50.23.16 with SMTP id i16mr110704igf.50.1382733666033; Fri, 25 Oct 2013 13:41:06 -0700 (PDT) Received: by 10.64.243.66 with HTTP; Fri, 25 Oct 2013 13:41:05 -0700 (PDT) In-Reply-To: <526AD233.3090109@isi.edu> References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> Date: Fri, 25 Oct 2013 13:41:05 -0700 Message-ID: From: Matt Mathis To: Valery Smyslov Content-Type: multipart/alternative; boundary=089e0158a9aafbfe5404e996c45d X-Mailman-Approved-At: Sat, 26 Oct 2013 11:05:54 -0700 Cc: tsvwg , Joe Touch , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, "tsv-dir@ietf.org" Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 25 Oct 2013 20:41:08 -0000 --089e0158a9aafbfe5404e996c45d Content-Type: text/plain; charset=ISO-8859-1 I concur with Joe: once you have enough machinery work well with IPv6 fragmentation semantics, you should use it for IPv4 too, and unconditionally set DF. This probably applies to *all* protocols. IPv4 reassembly is hopelessly out of scale. IP ID wrap times are likely to be sub second for any large CGN connecting to any large service..... They might even be shorter than the queuing times. I suspect that if you re-review decade old papers on fragmentation, you will find some scale assumptions that are no longer correct. In that time the Internet has moved at least another two orders of magnitude in packet rates. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch wrote: > > > On 10/24/2013 10:45 PM, Valery Smyslov wrote: > ... > >> You're using existing IKE messages *and* existing timeouts to >>> determine when there is a problem. A separate timer would be useful, >>> if only to allow you to decouple fragment retransmission from IKE >>> transaction retries. >>> >> >> No, the timeouts are different. I should have made it more expplicit in >> the draft. >> > > That'd be useful. > > ... > >> Always setting DF bit in this case will probably increase the delay >> before IKE SA is set up (as more probes will need to be done). >> > > Except that if you continue to allow IP fragmentation, you can't claim > your solution is robust to IP fragment poisoning. > > Note, that this approach is in line with advices, given for IKE in the >>>> paper >>>> >>>> C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection >>>> for UDP-based protocols", ACM Conference on Computer and >>>> Communications Security, October 2003. >>>> >>> >>> That paper doesn't consider IKE-level fragmentation, which you're >>> introducing. I agree that DF=0 for IKE without IKE-level fragmentation. >>> >> >> It does, in Section 3.3. >> > > Sorry - I missed that. But that section also gives good reasons why this > is a bad idea in IKE too. > > Joe > --089e0158a9aafbfe5404e996c45d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I concur with Joe: once you have enough machinery work wel= l with IPv6 fragmentation semantics, you should use it for IPv4 too, and un= conditionally set DF. =A0 This probably applies to *all* protocols.
IPv4 reassembly is hopelessly out of scale. =A0IP ID wrap times = are likely to be sub second for any large CGN connecting to any large servi= ce..... =A0They might even be shorter than the queuing times.

I suspect that if you re-review decade old papers on fragmentation, yo= u will find some scale assumptions that are no longer correct. =A0In that t= ime the Internet has moved at least another two orders of magnitude in pack= et rates.

Thanks,
--MM--
The best way to predict the future is to cr= eate it. =A0- Alan Kay

Privacy matters! =A0We know from recent event= s that people are using our services to speak in defiance of unjust governm= ents. =A0 We treat privacy and security as matters of life and death, becau= se for some users, they are.


On Fri, Oct 25, 2013 at 1:18 PM, Joe Tou= ch <touch@isi.edu> wrote:


On 10/24/2013 10:45 PM, Valery Smyslov wrote:
...
You're using existing IKE messages *and* existing timeouts to
determine when there is a problem. A separate timer would be useful,
if only to allow you to decouple fragment retransmission from IKE
transaction retries.

No, the timeouts are different. I should have made it more expplicit in
the draft.

That'd be useful.

...
Always setting DF bit in this case will probably increase the delay
before IKE SA is set up (as more probes will need to be done).

Except that if you continue to allow IP fragmentation, you can't claim = your solution is robust to IP fragment poisoning.

Note, that this approach is in line with advices, given for IKE in the
paper

C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection
=A0 =A0 =A0 =A0 =A0 =A0 =A0 for UDP-based protocols", ACM Conference o= n Computer and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Communications Security, October 2003.

That paper doesn't consider IKE-level fragmentation, which you're introducing. I agree that DF=3D0 for IKE without IKE-level fragmentation.

It does, in Section 3.3.

Sorry - I missed that. But that section also gives good reasons why this is= a bad idea in IKE too.

Joe

--089e0158a9aafbfe5404e996c45d-- From svanru@gmail.com Sun Oct 27 22:03:59 2013 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 9BB8111E8314 for ; Sun, 27 Oct 2013 22:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxXqkU+EsIdh for ; Sun, 27 Oct 2013 22:03:59 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 968CC11E8320 for ; Sun, 27 Oct 2013 22:03:56 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id ep20so4866577lab.3 for ; Sun, 27 Oct 2013 22:03:55 -0700 (PDT) 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; bh=leXLp4YjgwgUG/G4kk0rrB6LLrLToxzWpgkGxQPhKAQ=; b=vC6GbolhGbgzbG8Dbx+nqjLtyCiv+f6VfEVb8wL7w8TL1t9iaBUs0Z/kcOZHwgfb6k z/ov2z0a3Cvqhwu6DqABwZ5W41jmNGkcSNjvZBpO/zHmb87+QJ06L3hawOhRdvQBju00 1I7SoF9+8zYd7TV9Wu/Gv/2fRoeAgixTiNSnj1bQSOTQJCrhnU0CpjfFDE97o4W4Grzt WcmCuCtBS+8mx6K+RMkBHCqvYbpqAUjyTWNDUuOoTJUHT2SUtW3gEuaX5BFoE3rEfpKA gtLtIcml8h5McY2FHkfwJSkwVpR8f5zfwr5gw8oNxfsclHYDTIiJvLuc1/fShjByTwzi Kiww== X-Received: by 10.152.4.38 with SMTP id h6mr13638868lah.12.1382936635472; Sun, 27 Oct 2013 22:03:55 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id u18sm11691520lbp.4.2013.10.27.22.03.53 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 27 Oct 2013 22:03:54 -0700 (PDT) Message-ID: <0197CB8659DF46A78075A08DAFF7A05A@buildpc> From: "Valery Smyslov" To: "Yoav Nir" , "Paul Hoffman" References: <043754AD-BA58-4C9A-8491-114EE28E9F0E@vpnc.org><664172B4-1C5D-46BA-BBEE-5C232D964EF5@vpnc.org> <0CBA2879-0369-4853-BE01-2235E28A48AB@checkpoint.com> Date: Mon, 28 Oct 2013 09:03:42 +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] More WG Last Call on draft-ietf-ipsecme-ikev2-fragmentation 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, 28 Oct 2013 05:03:59 -0000 Hi Yoav, thank you for your review. > I think the draft is in good shape and is almost ready for publication. > There is a bunch of grammatical issues with it, but I think the RFC editor > is much better at fixing those than most of us. > > Section 2.5.1 recommends using 1280-byte max IP datagram size for IPv6 > (based on RFC 2460), and 576 bytes (based on RFC 1122). The big difference > between those two RFCs is not some technical difference between IPv6 and > IPv4, > but that the former was written in 1998 while the latter is from 1989. By > 1998 it was > reasonable to mandate infrastructure that could handle 1280-byte > datagrams. > This has become more true, not less in the 15 years since RFC 2460. > Pretty much all networks today can carry IPv6, and any network that can > carry > 1280-byte IPv6 packets, can just as well carry 1280-byte IPv4 packets. > I don't think there's any point in still making this distinction today. I tried to be conservative here. > Lastly, some nits: > > Section 2.1: > OLD: > The idea of the protocol is to split large IKE message into the set > of smaller ones, calling IKE Fragment Messages. > NEW: > The idea of the protocol is to split large IKE message into a set > of smaller ones, called IKE Fragment Messages. Fixed. > Section 2.5: > OLD: > o Total Fragments (2 octets) - number of fragments original message > was divided into. With PMTU discovery this field plays additional > role. See Section 2.5.2 for details. This field MUST NOT be > zero. > NEW: > o Total Fragments (2 octets) - number of fragments original message > was divided into. With PMTU discovery this field plays additional > role. See Section 2.5.2 for details. This field MUST NOT be > zero or one. I disagree. Total Fragments of one is perfectly valid. It makes sense in situations, when short request could generate large response (consider request of some parameters via Configuration Payload). In this case initiator may send fragmented message (even if there will be the only fragment) to quickly kick off responder to send fragmented response. And in general nothing in the draft prohibits some simple implementation from always sending messages in fragmented form even the short ones. From svanru@gmail.com Sun Oct 27 22:41:58 2013 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 78D5A11E8100; Sun, 27 Oct 2013 22:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuIYQ6Vt3clu; Sun, 27 Oct 2013 22:41:55 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id B045711E810D; Sun, 27 Oct 2013 22:41:53 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id w6so2436337lbh.38 for ; Sun, 27 Oct 2013 22:41:52 -0700 (PDT) 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; bh=7gB5O9o3GzZGGi1FojL3ZDChwj7y69b/7Lj9D2cACxs=; b=aeDUrKmAxJVo9KnZcF8HiHbrBH1/03nV8iVv+zdv0ZmHU9IRz7ppdNEBlUryrmXmsP CDPrBgM5oqVJgHsVcmVTfFPoxbVWk13k6CMDHqAR2EXfBt1eiMtG22ihmEYNflc+ZNOy XJFNsG/3SOcJsYoB0DBnugJzxNqu0fu7A3VLKs/jnP2AsYfCFNn0/ycOnVwq+EMmtVUx kgJl8T5E27GboLfpH+900BH/4AzzxvJOoCdW9Nm7zpk92rheGhNSEr/WS7ud6i26ZU/v tCRQ4p82BEKcFZq6gbZnCnQGS6xr7GKHGCbVtci0Bw5PpxtxMBryRTaV3yX4v8xBnnHc 8AQg== X-Received: by 10.112.132.70 with SMTP id os6mr267776lbb.38.1382938912619; Sun, 27 Oct 2013 22:41:52 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id oc1sm11790715lbb.3.2013.10.27.22.41.51 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 27 Oct 2013 22:41:51 -0700 (PDT) Message-ID: <9535B3BF68684F65992AEF03F3263FEA@buildpc> From: "Valery Smyslov" To: "Joe Touch" References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> Date: Mon, 28 Oct 2013 09:41:39 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response 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: tsvwg , tsv-ads@tools.ietf.org, Martin Stiemerling , ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 28 Oct 2013 05:41:58 -0000 >> Always setting DF bit in this case will probably increase the delay >> before IKE SA is set up (as more probes will need to be done). > > Except that if you continue to allow IP fragmentation, you can't claim > your solution is robust to IP fragment poisoning. I think it is. Consider the situation when IKE responder is under attack via IP fragmentation (no matter which - poisoning attack or memory exhausting attack). In any case responder will not be able to reply. After some (short) timeout initiator will try to apply IKE Fragmentation. Then, if those new messages are not fragmented on the path, they will bypass reassembly code on responder and the attack will be thwarted. If those messages are fragmented, even with their smallest allowed size, then it doesn't matter whether DF bit is set or not. If it is set, fragmenting device will drop messages, if it is not set, than attack will not be thwarted. Nothing can be done. Resume: setting DF bit in situation when even the smallest IKE Fragment messages are still fragmented by IP will definitely prevent IKE to work. Unsetting it will leave a chance (as with any DoS attack). >> It does, in Section 3.3. > > Sorry - I missed that. But that section also gives good reasons why this > is a bad idea in IKE too. It lists some drawbacks: added complexity and lack of individual ACKs. They were discussed by WG and found acceptable. It suggests using TCP instead. That was considered by WG, but rejected due to numerous issues. Valery. From svanru@gmail.com Sun Oct 27 22:50:59 2013 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 E813B11E80F5; Sun, 27 Oct 2013 22:50:59 -0700 (PDT) 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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHGmxccldPoe; Sun, 27 Oct 2013 22:50:59 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 48B0B11E8333; Sun, 27 Oct 2013 22:50:56 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id eo20so4748504lab.40 for ; Sun, 27 Oct 2013 22:50:55 -0700 (PDT) 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; bh=/9iLgF5L18FlRoA8KWUZ/I81cN7sXQIb+d6pkVi9a4g=; b=pUzyjKRcCRhy9ALIsPt2sdXN2FAk59IuLs2o6TveysLsWyAnwe++M7caremg1d580B Y0O2G+WbQMyW9vleKiV0On6VVaEDerJE+fM7ZI8DNmUEa7hKf/6OVTpBJmCYt3jrHcDz po/g6izb2JvlATxVdVLJTwATsOoV/ZaBL+oy07BLDY0z6MMbghIcSuVQzzKLGgWBCLew P1AwIpGDNSA3YqOkomOnCJ2k4bUEcLVVwSuRon7zA6vasHHWch3sCra2SJJTPoxQBShR Cm/eFkAQf1zfO8nSPIaFdw/zBPDe5W2zbJLs8y6N/UV7N91p6ZbhHs77olmAOmz365te Kjkg== X-Received: by 10.112.13.72 with SMTP id f8mr122749lbc.40.1382939455200; Sun, 27 Oct 2013 22:50:55 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id vx8sm11800471lbb.8.2013.10.27.22.50.53 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 27 Oct 2013 22:50:54 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Matt Mathis" References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu><14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu><5268060B.4060604@isi.edu><81953CE6126542A8AD40207921B8E018@buildpc><52695365.4070803@isi.edu><526AD233.3090109@isi.edu> Date: Mon, 28 Oct 2013 09:50:42 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0467_01CED3C3.2A8ED410" 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: tsvwg , Joe Touch , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 28 Oct 2013 05:51:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0467_01CED3C3.2A8ED410 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Matt, the whole idea of the draft is avoiding IP fragmentation for IKE when it prevents IKE to work. What about DF bit - I don't see how setting it=20 would help IKE to work. Regards, Valery. ----- Original Message -----=20 From: Matt Mathis=20 To: Valery Smyslov=20 Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; = draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org ; tsv-dir@ietf.org = ; Joe Touch=20 Sent: Saturday, October 26, 2013 12:41 AM Subject: Re: [tsvwg] [IPsec] TSVDIR-ish = reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 I concur with Joe: once you have enough machinery work well with IPv6 = fragmentation semantics, you should use it for IPv4 too, and = unconditionally set DF. This probably applies to *all* protocols. IPv4 reassembly is hopelessly out of scale. IP ID wrap times are = likely to be sub second for any large CGN connecting to any large = service..... They might even be shorter than the queuing times. I suspect that if you re-review decade old papers on fragmentation, = you will find some scale assumptions that are no longer correct. In = that time the Internet has moved at least another two orders of = magnitude in packet rates. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our = services to speak in defiance of unjust governments. We treat privacy = and security as matters of life and death, because for some users, they = are. On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch wrote: On 10/24/2013 10:45 PM, Valery Smyslov wrote: ... You're using existing IKE messages *and* existing timeouts to determine when there is a problem. A separate timer would be = useful, if only to allow you to decouple fragment retransmission from = IKE transaction retries. No, the timeouts are different. I should have made it more = expplicit in the draft. That'd be useful. ... Always setting DF bit in this case will probably increase the = delay before IKE SA is set up (as more probes will need to be done). Except that if you continue to allow IP fragmentation, you can't = claim your solution is robust to IP fragment poisoning. Note, that this approach is in line with advices, given for = IKE in the paper C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection for UDP-based protocols", ACM Conference on = Computer and Communications Security, October 2003. That paper doesn't consider IKE-level fragmentation, which = you're introducing. I agree that DF=3D0 for IKE without IKE-level = fragmentation. It does, in Section 3.3. Sorry - I missed that. But that section also gives good reasons why = this is a bad idea in IKE too. Joe ------=_NextPart_000_0467_01CED3C3.2A8ED410 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Matt,
 
the whole idea of the draft is avoiding IP = fragmentation for=20 IKE when
it prevents IKE to work. What = about DF bit=20 - I don't see how setting it
would help IKE to work.
 
Regards,
Valery.
 
----- Original Message -----
From:=20 Matt=20 Mathis
Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; dra= ft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org=20 ; tsv-dir@ietf.org ; Joe Touch
Sent: Saturday, October 26, = 2013 12:41=20 AM
Subject: Re: [tsvwg] [IPsec] = TSVDIR-ish=20 reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

I concur with Joe: once you have enough machinery work = well with=20 IPv6 fragmentation semantics, you should use it for IPv4 too, and=20 unconditionally set DF.   This probably applies to *all* = protocols.

IPv4 reassembly is hopelessly out of scale.  IP ID wrap = times are=20 likely to be sub second for any large CGN connecting to any large = service.....=20  They might even be shorter than the queuing times.

I suspect that if you re-review decade old papers on = fragmentation, you=20 will find some scale assumptions that are no longer correct.  In = that=20 time the Internet has moved at least another two orders of magnitude = in packet=20 rates.

Thanks,
--MM--
The best way to predict the future is to = create=20 it.  - Alan Kay

Privacy matters!  We know from recent = events=20 that people are using our services to speak in defiance of unjust = governments.=20   We treat privacy and security as matters of life and death, = because for=20 some users, they are.


On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch = <touch@isi.edu> wrote:


On 10/24/2013 10:45 PM, Valery Smyslov=20 wrote:
...
You're using existing IKE messages *and* = existing=20 timeouts to
determine when there is a problem. A separate = timer would=20 be useful,
if only to allow you to decouple fragment = retransmission=20 from IKE
transaction retries.

No, = the=20 timeouts are different. I should have made it more expplicit = in
the=20 draft.

That'd be useful.

...
Always setting DF bit in this case will probably = increase the delay
before IKE SA is set up (as more probes will = need to=20 be done).

Except that if you continue to allow = IP=20 fragmentation, you can't claim your solution is robust to IP = fragment=20 poisoning.

Note, that this approach is in line with = advices,=20 given for IKE in the
paper

C. Kaufman, R. Perlman, = and B.=20 Sommerfeld, "DoS protection
        =  =20     for UDP-based protocols", ACM Conference on = Computer=20 and
              = Communications=20 Security, October 2003.

That paper doesn't = consider=20 IKE-level fragmentation, which you're
introducing. I agree = that DF=3D0=20 for IKE without IKE-level = fragmentation.

It=20 does, in Section 3.3.

Sorry - I missed that. = But that=20 section also gives good reasons why this is a bad idea in IKE = too.

Joe

------=_NextPart_000_0467_01CED3C3.2A8ED410-- From ynir@checkpoint.com Sun Oct 27 23:21:20 2013 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 E4D5321E8085; Sun, 27 Oct 2013 23:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hV9ESyeXmWz; Sun, 27 Oct 2013 23:21:12 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1871311E8331; Sun, 27 Oct 2013 23:21:07 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9S6Ksqj011022; Mon, 28 Oct 2013 08:20:54 +0200 X-CheckPoint: {526E0164-5-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Mon, 28 Oct 2013 08:20:35 +0200 From: Yoav Nir To: Valery Smyslov Thread-Topic: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 Thread-Index: AQHO06GjEWbxzVDlyUWyTasGrxZ2zpoJgu+A Date: Mon, 28 Oct 2013 06:20:30 +0000 Message-ID: <0E72C765-82CF-4A2C-BE6A-31735954A9BB@checkpoint.com> References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu><14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu><5268060B.4060604@isi.edu><81953CE6126542A8AD40207921B8E018@buildpc><52695365.4070803@isi.edu><526AD233.3090109@isi.edu> 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.225] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_0E72C76582CF4A2CBE6A31735954A9BBcheckpointcom_" MIME-Version: 1.0 Cc: tsvwg , Joe Touch , "" , "" , "" , Matt Mathis , "" Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 28 Oct 2013 06:21:20 -0000 --_000_0E72C76582CF4A2CBE6A31735954A9BBcheckpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I guess the idea is that if the packet is still bigger than the PMTU, then = the IKE host gets back a "fragmentation needed" ICMP, and the IKE daemon le= arns of that and resends packets with appropriately small size. There are some issues with this: 1. It requires yet another retransmission 2. There's a lot of things on the IPv4 Internet that drop ICMP messages. I= Pv6 simply doesn't work without them, but IPv4 usually manages. 3. While the TCP stack has access to these ICMP packets and the PMTU that = they convey, a userspace IKE daemon usually doesn't. See [1] for how people= suggest doing it in C#. IKE is supposed to be done in two round-trips. It would be better to just p= ick 576 and send way too many IKE fragments then to try PMTU discovery. Yoav [1] http://stackoverflow.com/questions/4142080/path-mtu-discovery-in-c-shar= p On Oct 28, 2013, at 7:50 AM, Valery Smyslov > wrote: Hi Matt, the whole idea of the draft is avoiding IP fragmentation for IKE when it prevents IKE to work. What about DF bit - I don't see how setting it would help IKE to work. Regards, Valery. ----- Original Message ----- From: Matt Mathis To: Valery Smyslov Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; draft-ietf-ipsecme-= ikev2-fragmentation@tools.ietf.org ; tsv-dir@ietf.org ; Joe Tou= ch Sent: Saturday, October 26, 2013 12:41 AM Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fr= agmentation-04 I concur with Joe: once you have enough machinery work well with IPv6 fragm= entation semantics, you should use it for IPv4 too, and unconditionally set= DF. This probably applies to *all* protocols. IPv4 reassembly is hopelessly out of scale. IP ID wrap times are likely to= be sub second for any large CGN connecting to any large service..... They= might even be shorter than the queuing times. I suspect that if you re-review decade old papers on fragmentation, you wil= l find some scale assumptions that are no longer correct. In that time the= Internet has moved at least another two orders of magnitude in packet rate= s. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our serv= ices to speak in defiance of unjust governments. We treat privacy and sec= urity as matters of life and death, because for some users, they are. On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch > wrote: On 10/24/2013 10:45 PM, Valery Smyslov wrote: ... You're using existing IKE messages *and* existing timeouts to determine when there is a problem. A separate timer would be useful, if only to allow you to decouple fragment retransmission from IKE transaction retries. No, the timeouts are different. I should have made it more expplicit in the draft. That'd be useful. ... Always setting DF bit in this case will probably increase the delay before IKE SA is set up (as more probes will need to be done). Except that if you continue to allow IP fragmentation, you can't claim your= solution is robust to IP fragment poisoning. Note, that this approach is in line with advices, given for IKE in the paper C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection for UDP-based protocols", ACM Conference on Computer and Communications Security, October 2003. That paper doesn't consider IKE-level fragmentation, which you're introducing. I agree that DF=3D0 for IKE without IKE-level fragmentation. It does, in Section 3.3. Sorry - I missed that. But that section also gives good reasons why this is= a bad idea in IKE too. Joe _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_0E72C76582CF4A2CBE6A31735954A9BBcheckpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0F175F27AD02A84080DA1735FD1304D7@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable I guess the idea is that if the packet is still bigger than the PMTU, then = the IKE host gets back a "fragmentation needed" ICMP, and the IKE= daemon learns of that and resends packets with appropriately small size.

There are some issues with this:
 1. It requires yet another retransmission
 2. There's a lot of things on the IPv4 Internet that drop ICMP m= essages. IPv6 simply doesn't work without them, but IPv4 usually manages.
 3. While the TCP stack has access to these ICMP packets and the = PMTU that they convey, a userspace IKE daemon usually doesn't. See [1] for = how people suggest doing it in C#.

IKE is supposed to be done in two round-trips. It would be better to j= ust pick 576 and send way too many IKE fragments then to try PMTU discovery= .

Yoav


On Oct 28, 2013, at 7:50 AM, Valery Smyslov <svanru@gmail.com> wrote:

Hi Matt,
 
the whole idea of the draft is avoiding IP fragmentat= ion for IKE when
it prevents IKE to work. What about DF bit - I don't&n= bsp;see how setting it
would help IKE to work.
 
Regards,
Valery.
 
----- Original Message -----
From: Matt Mathis
Sent: Saturday, Oc= tober 26, 2013 12:41 AM
Subject: Re: [tsvw= g] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

I concur with Joe: once you have enough machinery work wel= l with IPv6 fragmentation semantics, you should use it for IPv4 too, and un= conditionally set DF.   This probably applies to *all* protocols.

IPv4 reassembly is hopelessly out of scale.  IP ID wrap times are= likely to be sub second for any large CGN connecting to any large service.= ....  They might even be shorter than the queuing times.

I suspect that if you re-review decade old papers on fragmentation, yo= u will find some scale assumptions that are no longer correct.  In tha= t time the Internet has moved at least another two orders of magnitude in p= acket rates.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our= services to speak in defiance of unjust governments.   We treat priva= cy and security as matters of life and death, because for some users, they = are.


On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch <touch@isi.edu> wrote:


On 10/24/2013 10:45 PM, Valery Smyslov wrote:
...
You're using existing IKE messages *and* existing timeouts to
determine when there is a problem. A separate timer would be useful,
if only to allow you to decouple fragment retransmission from IKE
transaction retries.

No, the timeouts are different. I should have made it more expplicit in
the draft.

That'd be useful.

...
Always setting DF bit in this case will probably increase the delay
before IKE SA is set up (as more probes will need to be done).

Except that if you continue to allow IP fragmentation, you can't claim your= solution is robust to IP fragment poisoning.

Note, that this approach is in line with advices, given for IKE in the
paper

C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection
              for UDP-based protocols&qu= ot;, ACM Conference on Computer and
              Communications Security, O= ctober 2003.

That paper doesn't consider IKE-level fragmentation, which you're
introducing. I agree that DF=3D0 for IKE without IKE-level fragmentation.

It does, in Section 3.3.

Sorry - I missed that. But that section also gives good reasons why this is= a bad idea in IKE too.

Joe

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.or= g/mailman/listinfo/ipsec

--_000_0E72C76582CF4A2CBE6A31735954A9BBcheckpointcom_-- From kivinen@iki.fi Mon Oct 28 06:15:28 2013 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 4E75F11E8274 for ; Mon, 28 Oct 2013 06:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWWeriRqLp6N for ; Mon, 28 Oct 2013 06:15:27 -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 9278B11E8278 for ; Mon, 28 Oct 2013 06:15:09 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9SDEwm6020582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Oct 2013 15:14:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9SDEwQN003236; Mon, 28 Oct 2013 15:14:58 +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: <21102.25426.68704.450938@fireball.kivinen.iki.fi> Date: Mon, 28 Oct 2013 15:14:58 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <5268055E.4000804@gmail.com> <876DF97CB1AF4CA7B96634DDE3D51B1B@buildpc> <21097.16245.405563.467088@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 20 min Cc: IPsecme WG Subject: Re: [IPsec] Working Group LastCall:draft-kivinen-ipsecme-signature-auth-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: Mon, 28 Oct 2013 13:15:28 -0000 Valery Smyslov writes: > > And you can always retry when you notice that you get authentication > > error after using private key, provided you have multiple types of > > keys. > > In general you can't if it is responder who selected wrong key. That is something I realized on our way home, but it is easy to fix. We add suggestion to the draft that the responder should use same type of key than what initiator used. I.e Initiator selects algorithm based on the CERTREQ and his own preferences (and one of those might be algorithms already used previously, or previously tried). The Responder should select same type of key that was used by initiator, provided he has the that type of private key. If not, then he picks a key based on his policy. > I admit, that such situations are rare but not non-existent. > And manual configuration is not an option for large VPNs. Large VPNs should use centralized management systems anyways, and all of this is also avoidable by using suitable sub CA keys. You do not need to change the root CA, it is enough to change the sub CA used to signing the EE cert, and send CERTREQ containg that key instead. > Retry is not always possible and is a hack anyway. For initiator it is possiblity, for responder adding the text which says it should use same algoritm than other end will solve the issue. I do not think it as a hack, we already do that in IKEv2 with Diffie-Hellman group negotiation. On the other hand we do not want to complicate the IKEv2 more by making the retry inside the exchange like we do with INVALID_KE_PAYLOAD, but we could add new error notify that the responder can send which says INVALID_AUTH_KEY_TYPE, and we could even add supported key types in that notify. Or we can simply use the AUTHENTICATION_FAILED notify and assume that it might have been because of wrong key type, and as we do not have anything better to do, we can simply retry. Nothing will go through the tunnel anyways unless we do something... > There might also be implementations, that supports only md5, > but we do not consider them, do we? As I said in draft, MD5 is not considered safe enough to be used in the signatures. It is OK to use in HMAC etc cases, but not with signatures. > And the problem with the current SIGNATURE_HASH_ALGORITHMS > is that it decouples hash from signature, assuming that any hash > could be used with any signature algorithm. This is feature, not bug as pointed out Johannes Merkle. > Actually this is not true, as some algorithms are administratively > defined only in conjunction with particular hash function. For > example GOST signature algorithm is defined ONLY with GOST hash. Which is not problem, as the same policy is in both ends. I.e. if one end supports GOST it will send GOST hash. If the other end does not support, it will ignore GOST hash and use some other has (and some other type of key too). If both ends support GOST hash, and pick GOST key, they will use GOST hash, as that is only one that is allowed by their policy. If one end uses GOST key with any other hash algorithm it is violating the GOST specification, and it is not expected to work. > And even if you could use DSA with SHA-2 or even SHA-3, You can use DSA with SHA-2. You cannot use it in IKEv2, as the current DSS signature method is defined to always use SHA-1. This is one of the reasons we initially started this work. > I would more likely expect the existence of crypto > that supports DSA only with SHA-1, than the crypto, > that supports only RSA with 1024 bit keys and no other RSA key sizes. Agree on that, but it is easy to see that some implementations supporting RSA keys do support SHA-1, some support SHA-1 and SHA-2 and so on, so the hash negotiation is also needed there. The implementation which supports both SHA-1 and 2 for RSA cannot use RSA with SHA-2 unless it knows the other end can support SHA-2. I agree that my example with 1024-bit RSA support was not good, but the problem is that there are no good examples of why people would want to do implementations which only support some features. I.e. it makes my point stronger that this problem is not seen in real world. -- kivinen@iki.fi From kivinen@iki.fi Mon Oct 28 06:24:13 2013 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 A94FA11E8273 for ; Mon, 28 Oct 2013 06:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lunGi8jnuWA for ; Mon, 28 Oct 2013 06:24:13 -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 EB73D21F9EF2 for ; Mon, 28 Oct 2013 06:24:06 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9SDO4d5006872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Oct 2013 15:24:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9SDO4Ql002979; Mon, 28 Oct 2013 15:24:04 +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: <21102.25972.504744.209565@fireball.kivinen.iki.fi> Date: Mon, 28 Oct 2013 15:24:04 +0200 From: Tero Kivinen To: Pekka Riikonen In-Reply-To: References: <5268055E.4000804@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 7 min Cc: IPsecme WG Subject: Re: [IPsec] Working Group Last Call: draft-kivinen-ipsecme-signature-auth-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: Mon, 28 Oct 2013 13:24:13 -0000 Pekka Riikonen writes: > > The ASN.1 used here are the same ASN.1 which is used in the > AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]). The > > It should specify encoding rules, even though it references RFC5280. So > this could say something like: > > The ASN.1 used here are the same ASN.1 which is used in the > AlgorithmIdentifier of the PKIX (Section 4.1.1.2 of [RFC5280]) > encoded using distinguished encoding rules (DER) [X.690]. Added. > the authentication methods are not negotiated in the IKEv2, the peer > is only allowed to use this authentication method if the > SIGNATURE_HASH_ALGORITHMS Notify Payload has been sent and received. > > I think I said this already for -00 version, that I'd still prefer to > allow the use of the new authentication method even if the hashes weren't > negotiated (the hash is is indicated in the ASN.1). I get why we want to > negotiate them, but it's not always necessary, necessarily. And if it > isn't allowed should it be MUST NOT? If you do not send SIGNATURE_HASH_ALGORITHMS you can use the old types of the authentication methods. That notify has dual meaning. It notifices that we support this new types of authentication method, and the list of hash algoritms supported. There is no other negotiation of this feature, i.e. the version number stays same and there is no other notifies to indicate support for this draft. -- kivinen@iki.fi From kivinen@iki.fi Mon Oct 28 06:56:10 2013 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 2E6AA11E8276 for ; Mon, 28 Oct 2013 06:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muX7TFbs7MWL for ; Mon, 28 Oct 2013 06:56:06 -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 0F71B11E810E for ; Mon, 28 Oct 2013 06:55:48 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9SDtjkj013411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Oct 2013 15:55:45 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9SDtjPY023852; Mon, 28 Oct 2013 15:55: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: <21102.27873.547147.66648@fireball.kivinen.iki.fi> Date: Mon, 28 Oct 2013 15:55:45 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 14 min Subject: [IPsec] draft-ietf-ipsecme-ikev2-fragmentation-04 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, 28 Oct 2013 13:56:10 -0000 I have reviewed this draft again. I tihnk we should add bit more in to the introduction. I.e explain the common case for this protocol is to fragment exactly ONE message pair (IKE_AUTH), and those messages are most commonly around 500-3000 bytes long. For example to do proper PMTU for sending exactly one 3000 byte packet is quite much overhead. -- In section 2.6. Receiving IKE Fragment Message: ---------------------------------------------------------------------- * check that Fragment Number and Total Fragments fields are non- zero * check that Fragment Number field is less than or equal to Total Fragments field * if reassembling has already started, check that Total Fragments field is equal to or greater than Total Fragments field in fragments, that have already received If either of this tests fails message MUST be silently discarded. ---------------------------------------------------------------------- Replace /If either of this tests/If any of these tests/. ---------------------------------------------------------------------- When all IKE Fragment Messages (as indicated in the Total Fragments field) are received, content of their Encrypted Fragment Payloads is decrypted and merged together to form content of original Encrypted Payload, and, therefore, along with IKE Header and unencrypted Payloads (if any), original message. Then it is processed as if it was received, verified and decrypted as regular unfragmented message. ---------------------------------------------------------------------- This text might cause confusion as it talks that when we have all fragments, we "...Encrypted Fragment Payloads is decrypted and merged ...", when actually the Encrypted Fragment Payloads are already decrypted when we initially received them. So changing that to: ---------------------------------------------------------------------- When all IKE Fragment Messages (as indicated in the Total Fragments field) are received, content of their already decrypted Encrypted Fragment Payloads is merged together to form content of original Encrypted Payload, and, therefore, along with IKE Header and unencrypted Payloads (if any), original message. Then it is processed as if it was received, verified and decrypted as regular unfragmented message. ---------------------------------------------------------------------- -- kivinen@iki.fi From kivinen@iki.fi Mon Oct 28 07:05:26 2013 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 DF06611E8144; Mon, 28 Oct 2013 07:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+1wIcOtxRKV; Mon, 28 Oct 2013 07:05:26 -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 D1BDC11E833F; Mon, 28 Oct 2013 07:05:19 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9SE5Cru002667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Oct 2013 16:05:12 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9SE5A4g004758; Mon, 28 Oct 2013 16:05:10 +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: <21102.28438.340833.664427@fireball.kivinen.iki.fi> Date: Mon, 28 Oct 2013 16:05:10 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <0E72C765-82CF-4A2C-BE6A-31735954A9BB@checkpoint.com> References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> <0E72C765-82CF-4A2C-BE6A-31735954A9BB@checkpoint.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Cc: tsvwg , Joe Touch , "" , "" , "" , Matt Mathis , "" , Valery Smyslov Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 28 Oct 2013 14:05:27 -0000 Yoav Nir writes: > 3. While the TCP stack has access to these ICMP packets and the > PMTU that they convey, a userspace IKE daemon usually doesn't. See > [1] for how people suggest doing it in C#. Actually for example our code tries to get ICMP messages for IKE packets, mostly so that we can make timeout shorter if we start to receive ICMP messages saying the other end is not going to responded. If we get ICMP port unreachable for every single IKE packet we send, there is no point of waiting for 2 minutes and 15 retranmissions to realize that the other end is not responding, 20 seconds and 5 retries might be better... > IKE is supposed to be done in two round-trips. It would be better to > just pick 576 and send way too many IKE fragments then to try PMTU > discovery. Yes. We are talking here about sending one 500-300 byte message from initiator to responder, and getting about same sized message back. After that we will only use few hundred bytes long exchanges. Doing PMTU for sending and receiving one packet is bit overkill. -- kivinen@iki.fi From ynir@checkpoint.com Mon Oct 28 07:28:17 2013 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 8C1AD11E8306; Mon, 28 Oct 2013 07:28:17 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+j7DBdQw35K; Mon, 28 Oct 2013 07:28:11 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9008411E8276; Mon, 28 Oct 2013 07:28:06 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9SERvQG011748; Mon, 28 Oct 2013 16:27:57 +0200 X-CheckPoint: {526E7385-B-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Mon, 28 Oct 2013 16:27:57 +0200 From: Yoav Nir To: Tero Kivinen Thread-Topic: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 Thread-Index: AQHO0+bd0LfaEbGSDEaJqrSL9NUM7ZoKKuuA Date: Mon, 28 Oct 2013 14:27:55 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772121AB0070@IL-EX10.ad.checkpoint.com> References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> <0E72C765-82CF-4A2C-BE6A-31735954A9BB@checkpoint.com> <21102.28438.340833.664427@fireball.kivinen.iki.fi> In-Reply-To: <21102.28438.340833.664427@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.27] 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: tsvwg , Joe Touch , "" , "" , "" , Matt Mathis , "" , Valery Smyslov Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 28 Oct 2013 14:28:17 -0000 OK, you convinced me. 576 is the right value to recommend for initiator. No= t sure if for responder it's also preferable to use 576, or to go with the = idea in 2.5.1 of using the fragment size from the request. Yoav -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: Monday, October 28, 2013 4:05 PM To: Yoav Nir Cc: Valery Smyslov; tsvwg; Joe Touch; ; ; ; Matt Mathis= ; Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fr= agmentation-04 Yoav Nir writes: > 3. While the TCP stack has access to these ICMP packets and the PMTU=20 > that they convey, a userspace IKE daemon usually doesn't. See [1] for=20 > how people suggest doing it in C#. Actually for example our code tries to get ICMP messages for IKE packets, m= ostly so that we can make timeout shorter if we start to receive ICMP messa= ges saying the other end is not going to responded. If we get ICMP port unreachable for every single IKE packet we send, there = is no point of waiting for 2 minutes and 15 retranmissions to realize that = the other end is not responding, 20 seconds and 5 retries might be better..= . > IKE is supposed to be done in two round-trips. It would be better to=20 > just pick 576 and send way too many IKE fragments then to try PMTU=20 > discovery. Yes. We are talking here about sending one 500-300 byte message from initia= tor to responder, and getting about same sized message back. After that we will only use few hundred bytes long exchanges. Doing PMTU for sending and receiving one packet is bit overkill. -- kivinen@iki.fi Email secured by Check Point From touch@isi.edu Mon Oct 28 09:22:57 2013 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 D06F711E8232; Mon, 28 Oct 2013 09:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GHtHf51vZP9; Mon, 28 Oct 2013 09:22:52 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 08C7E11E8192; Mon, 28 Oct 2013 09:22:52 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r9SGLZrk028562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Oct 2013 09:21:44 -0700 (PDT) Message-ID: <526E8F14.7050308@isi.edu> Date: Mon, 28 Oct 2013 09:21:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yoav Nir References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu><14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu><5268060B.4060604@isi.edu><81953CE6126542A8AD40207921B8E018@buildpc><52695365.4070803@isi.edu><526AD233.3090109@isi.edu> <0E72C765-82CF-4A2C-BE6A-31735954A9BB@checkpoint.com> In-Reply-To: <0E72C765-82CF-4A2C-BE6A-31735954A9BB@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg , "" , "" , "" , Matt Mathis , "" , Valery Smyslov Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 28 Oct 2013 16:22:57 -0000 On 10/27/2013 11:20 PM, Yoav Nir wrote: > I guess the idea is that if the packet is still bigger than the PMTU, > then the IKE host gets back a "fragmentation needed" ICMP, and the IKE > daemon learns of that and resends packets with appropriately small size. > > There are some issues with this: You proceed to describe how PMTUD works, but this is intended (AFAICT) to be more like PLMUTD - which does not rely on ICMPs. Joe From touch@isi.edu Mon Oct 28 09:28:39 2013 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 21E2521E80D8; Mon, 28 Oct 2013 09:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXAei6pzgyDB; Mon, 28 Oct 2013 09:28:33 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 93CD121E80C9; Mon, 28 Oct 2013 09:28:32 -0700 (PDT) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r9SGPo8c029826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Oct 2013 09:25:59 -0700 (PDT) Message-ID: <526E9013.9020103@isi.edu> Date: Mon, 28 Oct 2013 09:25:55 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Valery Smyslov References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> <9535B3BF68684F65992AEF03F3263FEA@buildpc> In-Reply-To: <9535B3BF68684F65992AEF03F3263FEA@buildpc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg , tsv-ads@tools.ietf.org, Martin Stiemerling , ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 28 Oct 2013 16:28:39 -0000 On 10/27/2013 10:41 PM, Valery Smyslov wrote: >>> Always setting DF bit in this case will probably increase the delay >>> before IKE SA is set up (as more probes will need to be done). >> >> Except that if you continue to allow IP fragmentation, you can't claim >> your solution is robust to IP fragment poisoning. > > I think it is. > > Consider the situation when IKE responder is under attack > via IP fragmentation (no matter which - poisoning attack or memory > exhausting attack). In any case responder will not be able to reply. > After some (short) timeout initiator will try to apply IKE Fragmentation. > Then, if those new messages are not fragmented on the path, they > will bypass reassembly code on responder and the attack will > be thwarted. If those messages are fragmented, even with their > smallest allowed size, then it doesn't matter whether DF bit is set or not. > If it is set, fragmenting device will drop messages, if it is not set, > than attack will not be thwarted. Nothing can be done. You're not proposing to use the smallest size, which would be 68 bytes. So by not setting DF, you're enabling a fragmentation attack. If you set DF, a receiver could drop all fragments from addresses it wants to protect against IKE fragment poisoning. Joe From mls@cisco.com Mon Oct 28 17:58:24 2013 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 924DC11E81B8 for ; Mon, 28 Oct 2013 17:58:03 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOSJBlXlmUAv for ; Mon, 28 Oct 2013 17:57:50 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8D98711E81BA for ; Mon, 28 Oct 2013 17:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11435; q=dns/txt; s=iport; t=1383008207; x=1384217807; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=O/XBFcBzFThaqcLRArtFqP+1axYpdGuJHNEY2Xo087E=; b=AdZG/ccvURDgAQjtZGpaWfydxqMLPh75NH1jQJW83QV8aH0DHZeCLyu5 BkNLuHhFfDKE9XnaMC1tEBJnicrII8UJhpy9ZxiS2eIsLSf7R5qkTaQUL J0WX5H4wJACUedpUKDD5QKWbau1B/8OIcI09EVRXkHbbjWWhPB1CR55mw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAGoHb1KtJXG+/2dsb2JhbABZgwc4VL5pgSoWdIIlAQEBAwEBAQFrCwwEAgEIDgMEAQEBCh0HJwsUCQgCBA4FCBOHZgYNuFMEjyQxBwaDGYENA4kHiyOVZ4Mmgio X-IronPort-AV: E=Sophos;i="4.93,589,1378857600"; d="scan'208";a="274790763" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 29 Oct 2013 00:56:31 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9T0uV34017886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 00:56:31 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.176]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 28 Oct 2013 19:56:31 -0500 From: "Mike Sullenberger (mls)" To: Lou Berger Thread-Topic: [IPsec] Some comments on draft-detienne-dmvpn-00 Thread-Index: AQHO0NGz7SlGC2HHbUSuHZRmgXWXdZoK1QnA Date: Tue, 29 Oct 2013 00:56:30 +0000 Message-ID: <9D83DE546CB6DC47A3AE04086FDE35F523FB1719@xmb-aln-x06.cisco.com> References: <5261B62A.4020209@labn.net> <9D83DE546CB6DC47A3AE04086FDE35F523FADE2D@xmb-aln-x06.cisco.com> <5269434E.3050109@labn.net> In-Reply-To: <5269434E.3050109@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.66.29] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , "draft-detienne-dmvpn@tools.ietf.org" , "Mike Sullenberger \(mls\)" Subject: Re: [IPsec] Some comments on draft-detienne-dmvpn-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: Tue, 29 Oct 2013 00:58:24 -0000 Lou, Thanks, again answer inline :-). Mike. Mike Sullenberger, DSE mls@cisco.com=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 .:|:.:|:. Customer Advocacy=A0=A0=A0=A0=A0=A0=A0=A0=A0 CISCO > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, October 24, 2013 8:57 AM > To: Mike Sullenberger (mls) > Cc: IPsecme WG; draft-detienne-dmvpn@tools.ietf.org > Subject: Re: [IPsec] Some comments on draft-detienne-dmvpn-00 >=20 > Hi Mike, >=20 > Thanks for the response. See below... >=20 > On 10/23/2013 2:54 PM, Mike Sullenberger (mls) wrote: > > Lou, > > > > Thank you for your comments, more inline. > > > > Mike. > > > > Mike Sullenberger, DSE > > mls@cisco.com .:|:.:|:. > > Customer Advocacy CISCO > > > > > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: Friday, October 18, 2013 3:29 PM > >> To: draft-detienne-dmvpn@tools.ietf.org > >> Cc: IPsecme WG > >> Subject: Some comments on draft-detienne-dmvpn-00 > >> > >> Hi, > >> I have the following comments/questions on the draft: > >> > >> - Why allow IPsec tunnel mode? Is there a case where it provides some = value? > > > > [Mike Sullenberger] > > You are correct that IPsec tunnel mode is not really needed and > > transport mode is far recommended and preferred. There are a couple of > > rare situations where tunnel-mode could help, like when separating the > > GRE/NHRP tunneling and IPsec encryption onto separate nodes, these > > cases are not recommended, but we thought we should leave in the > > possibility. > > >=20 > How does this work? >=20 > As I understand it, NHRP is run inside the GRE tunnel so this means that = the > IPsec and GRE endpoints now need some way to communicate (for e.g., > public ("NBMA") addresses and GRE/IPsec tunnel creation/removal > coordination). >=20 > Am I missing something? > [Mike Sullenberger]=20 You have this correct, and basically we don't coordinate the NHRP and IPsec= databases in this case. It is expected that the IPsec node will create IP= sec SAs on demand due to GRE tunnel traffic and will remove them when ther= e is no more=20 GRE tunnel traffic. This is basically why we don't recommend this type of = setup, but since I don't know the future I hate to remove this possibility = so that is why supporting IPsec tunnel-mode is a "MAY" in the draft.=20 >=20 > >> - Do you want to recommend omitting the GRE checksum? > > > > [Mike Sullenberger] > > Good idea, we definitely don't use the GRE checksum, and I don't think > > it provides any value so we should recommend omitting it. I think > > this is also the case for most of the other optional GRE header > > attributes. >=20 >=20 > > Though, the GRE Tunnel Key must be allowed, handled and provided. > > >=20 > I missed that the tunnel key MUST be "provided". Can you elaborate on > this? I only see one oblique reference to it in the draft. [Mike Sullenberger]=20 For a node to support a single DMVPN you don't need a GRE tunnel key and if= the node supports multiple DMVPNs and each one has a different tunnel sour= ce (NBMA) address, then again you don't need a GRE tunnel key. Only if a s= ingle node is supporting multiple DMVPNs and is using the same tunnel sourc= e (NBMA) address on them then you would need a something to differentiate t= he GRE tunnel packets and logically that would be the tunnel key. So give= n that perhaps supporting a GRE tunnel key would be a "SHOULD" or "MAY". T= his could be an implementation detail, but we could still clarify this in t= he draft. >=20 > >> - I think the draft should discuss what happens when the best route > >> moves from one spoke to another spoke. Both the cases where the > >> host/prefix is still reachable via the original spoke and when it > >> isn't should be covered. As should avoiding blackholes, and any period= s > of suboptimal forwarding. > > > > [Mike Sullenberger] > > We can add some more discussion around this point. The main feature > > here is that this is handled by the routing protocol that is running > > over the DMVPN tunnels. >=20 > For clarification: routing runs over the configured DMVPN topology, but n= ot > shortcuts, right? [Mike Sullenberger]=20 That is correct. The reason that we don't run the routing protocol over the= shortcuts, is because the routing protocol has constant traffic (hellos) w= hich would tend to keep the shortcuts up and these packets are a bit of a p= ain to filter out if needed. Also in this case the routing protocol on the= spokes would tend to get many routing neighbors which could overwhelm the = spoke, CPU-wise, and overwhelm the routing protocol with too many forwardin= g options. >=20 > > The routing protocol will redirect the data packets via different > > tunnels and/or spokes as the routing is updated. >=20 > I think your answer to my next question actually helps answer this one. >=20 > So Section 6.1 of RFC2332 says: > ... In such > circumstances, NHRP should not be used. This situation can be > avoided if there are no "back door" paths between the entry and > egress router outside of the NBMA subnetwork. Protocol mechanisms to > relax these restrictions are under investigation. >=20 > Do you believe this restriction still applies? [Mike Sullenberger]=20 I do not believe that this restriction applies. I have never seen an issue= along these lines where there wasn't a mis-design or mis-configuration of = the routing protocol. In DMVPN, NHRP uses the routing protocol as the fina= l source of truth for destinations reachable through the VPN. If the routin= g protocol changes routing to now not route packets through the VPN then NH= RP needs to clear any routing/forwarding/shortcuts that would forward to th= at destination via the VPN. I think the mechanism to detect something like= this is implementation dependent, but we probably should mention that such= a mechanism may/should be provided. >=20 > > Note, if static routing is used then you lose this capability. >=20 > Sure. > > > >> - I think the draft is missing a description of how/when NHRP Purges > >> are used, e.g., resulting from interactions with routing. (Yes there > >> is an overlap with the above, but it depends a bit on your solution.) > > > > [Mike Sullenberger] > > As you have noted, NHRP purges are used to keep the distributed NHRP > > database in sync. If a local node loses access to a destination that > > it has previously replied with itself as the egress point in an NHRP > > mapping (and the entry hasn't timed out yet) then it will generate an > > NHRP purge and send a copy to each requester (recorded when it sent > > the original reply). This will then clear out these now invalid > > mapping entries on the remote nodes and trigger them to find an > > alternate path if available. Note, this is basically what is > > described in NHRP (RFC2332), we didn't really want to duplicate this > > in this RFC, but it could be added. > > >=20 > okay, I think this comes back to where the draft says: > > In this document, we will depart the > > underlying notion of a centralized NHS. >=20 > I think the part that's missing (or perhaps I just missed) is an explicit > statement that an egress must follow the NHS procedures related to any > issued Resolution Reply. >=20 [Mike Sullenberger]=20 I think this is a place where we need to point to the NHRP RFC to follow fo= r these procedures and any differences if any.=20 Is this what you are getting at? > >> - I the draft should discuss the NHRP scaling considerations that are > >> important in implementation and deployment/operation. (Basically the > >> solution is proposing network wide ARP.) You already have a teaser > >> on this when you mention rate limiting. > > > > [Mike Sullenberger] > > We can certainly do so. In DMVPN deployments we haven't really found > > that NHRP scaling has been an issue. Usually we ran into either > > Routing protocol or IPsec scaling issues first. It is correct we do > > mention a couple of places about rate limiting triggering or sending > > of NHRP messages, mainly because it wasn't felt that it was useful to > > continue to "bother" another node if it was working on the previous > > request, which was the same as the one to be sent again. Note, we do > > have mechanisms for retransmission and back-off of messages. Again > > some of this is covered in the NHRP RFC. > > >=20 > I guess it all depends on the number of routes in the system and > reachability pattern at a particular spoke. I think when both are large,= the > use of per prefix soft state refreshes will prove problematic. I'm a bit > surprised you've run into routing protocol scaling issues though, but tha= t's > certainly out of scope. [Mike Sullenberger]=20 Routing protocol scaling is only seen on the Hubs (NHSs), since they are ba= sically the route reflectors for the spokes. We don't normally see any rout= ing issues on the spokes. Spokes in general don't build that many shortcut= s and therefore don't have many per prefix refreshes. Though in cases wher= e a spoke may build out a 1000 shortcuts, the refreshes since they are usua= lly on the order of 10s of minutes apart don't cause a scaling issue on the= spoke. Also such a spoke is normally a larger box, since it has to handle= 1000+ ISAKMP/IPsec SAs and the presumably the traffic that goes with it. > >> - NIT/editorial: If section 4 is your "Solution Overview", where is > >> the solution specification? More seriously, I found parts of this > >> section more of a narrative of an example than a protocol specificatio= n. > > > > [Mike Sullenberger] > > Yes, I think this needs to be cleaned up. Since a lot of what we do > > with NHRP is covered in the NHRP RFC we didn't want to duplicate too > > much here, but we can certainly make a more clear solution > > specification. I think the solution overview section is also useful > > since, a walk through can help people to understand how the solution > > is intended to work. Many times I find it hard with just solution > > specifications to get a real feel for how things go together. > > >=20 > Avoiding duplicate specification is certainly goodness, but I think some > additional pointers to when standard NHRP procedures are to be followed > (or not) would be a valuable addition as part of the cleanup. [Mike Sullenberger]=20 Yes, we can add in more guidance along these lines. =20 Your comments are a great help in solidifying what needs to be done for the= next and following drafts.=20 Thanks, Mike. >=20 > Much thanks, > Lou >=20 > >> - NIT: Assuming the Indirection Notification described in section 4.3 > >> is the same as the NHRP Traffic Indication covered in 5.1, can you > >> align the names and fix the reference in 4.3? > > > > [Mike Sullenberger] > > Yes, thanks for noting this. We tend to use those terms interchangeabl= y, > > but we should be more consistent here. > > > >> > >> Thanks, > >> Lou > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > From svanru@gmail.com Mon Oct 28 22:53:37 2013 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 D83BF11E80FC; Mon, 28 Oct 2013 22:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mxXp+gdNYfz; Mon, 28 Oct 2013 22:53:37 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A1E7E11E810D; Mon, 28 Oct 2013 22:53:36 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id q8so3641864lbi.33 for ; Mon, 28 Oct 2013 22:53:35 -0700 (PDT) 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; bh=nLJB3N1ji/Duiz++eMvCOaUKlBAXiWgsWyYKrR2QvHo=; b=cbQYDzwTWDoVWTATXw6XcqCoVZx1wcuUoty4jYAnNr+4/FAIZ2Z9jIPBpTp7Pipaii CNxgUo8P/vZVpMnRZqPUw2EUqEUs4CGg6PkOb0SDNhXfAaQNCxkKSJDq27YXZRSiQKBQ UIha9QwAX0/VOrqAGtOrjI1aOw5H6OikznNjIEB+3yqVlG8uf2l+dtlxTxAYEFVO/nGi SqcaRIMOyaSEC5Pxb4Tj6pu+SdhLLwZOwk+8UP4pMc+cPHEAMG8j4wV28Vs0sF1aiFwc YMnOAyegl8clv3mBpAZs9+uyEoBZEAm4MaJHIJSbQ8p1AeohZPObWvE8DPjId/eUsgv/ IVjQ== X-Received: by 10.152.36.170 with SMTP id r10mr530132laj.48.1383026015499; Mon, 28 Oct 2013 22:53:35 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id m13sm15332337lbo.11.2013.10.28.22.53.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 28 Oct 2013 22:53:34 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Joe Touch" References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> <9535B3BF68684F65992AEF03F3263FEA@buildpc> <526E9013.9020103@isi.edu> Date: Tue, 29 Oct 2013 09:53:31 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response 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: tsvwg , tsv-ads@tools.ietf.org, Martin Stiemerling , ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 29 Oct 2013 05:53:38 -0000 >> Consider the situation when IKE responder is under attack >> via IP fragmentation (no matter which - poisoning attack or memory >> exhausting attack). In any case responder will not be able to reply. >> After some (short) timeout initiator will try to apply IKE Fragmentation. >> Then, if those new messages are not fragmented on the path, they >> will bypass reassembly code on responder and the attack will >> be thwarted. If those messages are fragmented, even with their >> smallest allowed size, then it doesn't matter whether DF bit is set or >> not. >> If it is set, fragmenting device will drop messages, if it is not set, >> than attack will not be thwarted. Nothing can be done. > > You're not proposing to use the smallest size, which would be 68 bytes. No, as it is not possible with this solution. Depending on algorithms involved the smallest IP packet containing IKE message is about 100 bytes, and it is almost useless as in this case it contains only a few bytes of useful data. The minimum IP packet size still useful would be about 256 bytes. > So by not setting DF, you're enabling a fragmentation attack. If you set > DF, a receiver could drop all fragments from addresses it wants to protect > against IKE fragment poisoning. Yes. But if even the smallest IKE messages are to be fragmented by intermediate node, then setting DF bit (or dropping all IP fragments) will just not enable IKE to succeed. By not setting it we give IKE a chance. From svanru@gmail.com Mon Oct 28 23:27:31 2013 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 EC5E921F9E44; Mon, 28 Oct 2013 23:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0HVwrVYUQco; Mon, 28 Oct 2013 23:27:30 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2013911E81C1; Mon, 28 Oct 2013 23:27:24 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id x18so3649588lbi.2 for ; Mon, 28 Oct 2013 23:27:24 -0700 (PDT) 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; bh=FP/sXu7k+fMseXEr0In8S9/+VgfMv3VavZlVCXm5aFI=; b=FtQBf7CXwJfsvv72A7mGg0E+cwhqziX+ExTPLbO/OxKyywXwklVG8Ti1es3JPmWy2l PYCS6QHBCOICl+cehYNPk46BA7G0rOpzxmVl++owNxHiIlAbodOTvv0K2cqYNhnLxTUY auGSFzNTrChEpgha76KbNzvNPxcNFtcq3PoH2V39Ew1JkHhs++kcKUK7t8myUAUwG1mb NkPUN14tF4HHeu2Mvp5wuO4KOcX+wiNsQ2pdufDYSvin6PNa2RvVHqH5jws3xhInJ11J hG50ULO/N49Gdi4AF0W7c5SpH4lLMfSwIWkmD0ruaxdQY08r6WSVd/c19o0DCQCOXiCY 3Viw== X-Received: by 10.152.10.99 with SMTP id h3mr14514449lab.13.1383028044056; Mon, 28 Oct 2013 23:27:24 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id vo1sm15441589lbb.1.2013.10.28.23.27.22 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 28 Oct 2013 23:27:23 -0700 (PDT) Message-ID: <336D6D662DB0470DBFB3A576FFCB8E7F@buildpc> From: "Valery Smyslov" To: "Matt Mathis" References: <51FA6A6C.8090803@gmail.com><523CB65D.1090904@neclab.eu><523CB9CB.7060507@isi.edu><5265C19B.30108@isi.edu><14DB3765679C45D283869DC9010F0084@buildpc><52669960.1000706@isi.edu><5268060B.4060604@isi.edu><81953CE6126542A8AD40207921B8E018@buildpc><52695365.4070803@isi.edu><526AD233.3090109@isi.edu> Date: Tue, 29 Oct 2013 10:27:20 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_056F_01CED491.732A1FD0" 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: tsvwg , Joe Touch , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, tsv-dir@ietf.org Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 29 Oct 2013 06:27:32 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_056F_01CED491.732A1FD0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable While I agree with you in general, I think that IKE has its own = peculiarity, that makes things a bit different. There is a difference between IPv6 and IPv4. In IPv6 one can assume, that packets below 1280 bytes will not be fragmented en route. This = leaves enough room to make IKE level fragmentation and be sure, that no IP fragmentation = will take place. With IPv4 any IP packet greater 68 bytes is fragmentable. Due to IKE = message construction restrictions you cannot make IKE fragments that small, so you always have a possibility, that packets will still be fragmented = by IP level. If you send them with DF=3D1 and intermediate device still wants to = fragment them, then you will just prevent IKE to succeed with 100% probability. If in = this case DF=3D0, then it might work. If, as you suggest, originating host performs IP fragmentation and sends = IP fragments with DF=3D1, then we have exactly the problem the draft is intended to = solve -=20 the presence of IP fragments on the whole path. Draft introduces = IKE-level fragmentation=20 to avoid IP fragmentation whenever possible and to only let it be if it = is impossible. But if it=20 is unavoidable, then there are more chances for IKE to work if IP = fragments exist only on the part of the path, i.e. when fragmentation is done by = intermediate device. ----- Original Message -----=20 From: Matt Mathis=20 To: Valery Smyslov=20 Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; = draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org ; tsv-dir@ietf.org = ; Joe Touch=20 Sent: Tuesday, October 29, 2013 2:22 AM Subject: Re: [tsvwg] [IPsec] TSVDIR-ish = reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 Setting DF is supposed to prevent some midpath IPv4 device from = silently "fixing" a MTU problem by doing you a favor that you don't = want. IPv4 fragmentation can be used in a mode that mimics IPv6: Only = fragment on the originating host, always set DF on on all outbound = packets, even if they are already fragmented. Any protocol or = application that does not work in this configuration will also fail on = IPv6. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our = services to speak in defiance of unjust governments. We treat privacy = and security as matters of life and death, because for some users, they = are. On Sun, Oct 27, 2013 at 10:50 PM, Valery Smyslov = wrote: Hi Matt, the whole idea of the draft is avoiding IP fragmentation for IKE = when it prevents IKE to work. What about DF bit - I don't see how setting = it=20 would help IKE to work. Regards, Valery. ----- Original Message -----=20 From: Matt Mathis=20 To: Valery Smyslov=20 Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; = draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org ; tsv-dir@ietf.org = ; Joe Touch=20 Sent: Saturday, October 26, 2013 12:41 AM Subject: Re: [tsvwg] [IPsec] TSVDIR-ish = reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 I concur with Joe: once you have enough machinery work well with = IPv6 fragmentation semantics, you should use it for IPv4 too, and = unconditionally set DF. This probably applies to *all* protocols.=20 IPv4 reassembly is hopelessly out of scale. IP ID wrap times are = likely to be sub second for any large CGN connecting to any large = service..... They might even be shorter than the queuing times.=20 I suspect that if you re-review decade old papers on = fragmentation, you will find some scale assumptions that are no longer = correct. In that time the Internet has moved at least another two = orders of magnitude in packet rates. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using = our services to speak in defiance of unjust governments. We treat = privacy and security as matters of life and death, because for some = users, they are. On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch wrote: On 10/24/2013 10:45 PM, Valery Smyslov wrote: ... You're using existing IKE messages *and* existing timeouts = to determine when there is a problem. A separate timer would be = useful, if only to allow you to decouple fragment retransmission = from IKE transaction retries. No, the timeouts are different. I should have made it more = expplicit in the draft. That'd be useful. ... Always setting DF bit in this case will probably increase the = delay before IKE SA is set up (as more probes will need to be done). Except that if you continue to allow IP fragmentation, you can't = claim your solution is robust to IP fragment poisoning. Note, that this approach is in line with advices, given = for IKE in the paper C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection for UDP-based protocols", ACM Conference on = Computer and Communications Security, October 2003. That paper doesn't consider IKE-level fragmentation, which = you're introducing. I agree that DF=3D0 for IKE without IKE-level = fragmentation. It does, in Section 3.3. Sorry - I missed that. But that section also gives good reasons = why this is a bad idea in IKE too. Joe ------=_NextPart_000_056F_01CED491.732A1FD0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
While I agree with you in general, I think that IKE = has its=20 own peculiarity,
that makes things a bit different.
 
There is a difference between IPv6 and IPv4. In IPv6 = one can=20 assume,
that packets below 1280 bytes will not be fragmented = en route.=20 This leaves enough room
to make IKE level fragmentation and be sure, that no = IP=20 fragmentation will take place.
With IPv4 any IP packet greater 68 bytes is = fragmentable. Due=20 to IKE message
construction restrictions you cannot make IKE = fragments that=20 small,
so you always have a possibility, that packets will = still be=20 fragmented by IP level.
If you send them with DF=3D1 and intermediate device = still wants=20 to fragment them,
then you will just prevent IKE to succeed with 100%=20 probability. If in this case DF=3D0,
then it might work.
 
If, as you suggest, originating host performs IP = fragmentation=20 and sends IP fragments
with DF=3D1, then we have exactly the problem the = draft is=20 intended to solve -
the presence of IP fragments on the whole path. = Draft=20 introduces IKE-level fragmentation
to avoid IP fragmentation whenever=20 possible and to only let it be if it is impossible. But if it =
is unavoidable, then there are more chances for IKE = to work if=20 IP fragments exist
only on the part of the path, i.e. when=20 fragmentation is done by intermediate device.
 
----- Original Message -----
From:=20 Matt=20 Mathis
Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; dra= ft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org=20 ; tsv-dir@ietf.org ; Joe Touch
Sent: Tuesday, October 29, 2013 = 2:22=20 AM
Subject: Re: [tsvwg] [IPsec] = TSVDIR-ish=20 reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

Setting DF is supposed to prevent some midpath IPv4 = device from=20 silently "fixing" a MTU problem by doing you a favor that you don't = want.

IPv4 fragmentation can be used in a mode that mimics IPv6: Only = fragment=20 on the originating host, always set DF on on all outbound packets, = even if=20 they are already fragmented.     Any protocol or application = that=20 does not work in this configuration will also fail on = IPv6.

Thanks,
--MM--
The best way to predict the future is to = create=20 it.  - Alan Kay

Privacy matters!  We know from recent = events=20 that people are using our services to speak in defiance of unjust = governments.=20   We treat privacy and security as matters of life and death, = because for=20 some users, they are.


On Sun, Oct 27, 2013 at 10:50 PM, Valery = Smyslov <svanru@gmail.com> wrote:
Hi Matt,
 
the whole idea of the draft is avoiding IP = fragmentation=20 for IKE when
it prevents IKE to work. What about=20 DF bit - I don't see how setting it
would help IKE to work.
 
Regards,
Valery.
 
----- Original Message ----- =
From: = Matt Mathis
Cc: tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org = ; draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org= ;=20 tsv-dir@ietf.org ; Joe Touch
Sent: Saturday, October 26, = 2013=20 12:41 AM
Subject: Re: [tsvwg] = [IPsec]=20 TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

I concur with Joe: once you have enough machinery = work well=20 with IPv6 fragmentation semantics, you should use it for IPv4 too, = and=20 unconditionally set DF.   This probably applies to *all* = protocols.=20

IPv4 reassembly is hopelessly out of scale.  IP ID wrap = times=20 are likely to be sub second for any large CGN connecting to any = large=20 service.....  They might even be shorter than the queuing = times.=20

I suspect that if you re-review decade old papers on = fragmentation,=20 you will find some scale assumptions that are no longer correct. =  In=20 that time the Internet has moved at least another two orders of = magnitude=20 in packet rates.

Thanks,
--MM--
The best way to predict the future is = to=20 create it.  - Alan Kay

Privacy matters!  We know = from=20 recent events that people are using our services to speak in = defiance of=20 unjust governments.   We treat privacy and security as = matters of=20 life and death, because for some users, they = are.


On Fri, Oct 25, 2013 at 1:18 PM, Joe = Touch <touch@isi.edu> wrote:


On 10/24/2013 10:45 PM, Valery Smyslov = wrote:
...
You're using existing IKE messages *and* = existing=20 timeouts to
determine when there is a problem. A separate = timer=20 would be useful,
if only to allow you to decouple = fragment=20 retransmission from IKE
transaction=20 retries.

No, the timeouts are = different. I=20 should have made it more expplicit in
the=20 draft.

That'd be useful.

...
Always setting DF bit in this case will = probably=20 increase the delay
before IKE SA is set up (as more probes = will=20 need to be done).

Except that if you = continue to=20 allow IP fragmentation, you can't claim your solution is robust = to IP=20 fragment poisoning.

Note, that this approach is in line with = advices, given for IKE in the
paper

C. Kaufman, = R.=20 Perlman, and B. Sommerfeld, "DoS protection
  =  =20           for UDP-based = protocols", ACM=20 Conference on Computer and
        =  =20     Communications Security, October=20 2003.

That paper doesn't consider = IKE-level=20 fragmentation, which you're
introducing. I agree that = DF=3D0 for=20 IKE without IKE-level = fragmentation.

It=20 does, in Section 3.3.

Sorry - I missed = that. But=20 that section also gives good reasons why this is a bad idea in = IKE=20 too.

Joe


------=_NextPart_000_056F_01CED491.732A1FD0-- From svanru@gmail.com Tue Oct 29 00:06:27 2013 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 75B1811E81A7 for ; Tue, 29 Oct 2013 00:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHDS1bD6yujb for ; Tue, 29 Oct 2013 00:06:24 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 65C4F21F9FE9 for ; Tue, 29 Oct 2013 00:06:02 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id o14so3620616lbi.23 for ; Tue, 29 Oct 2013 00:06:01 -0700 (PDT) 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; bh=+E0p3yHKRmWRFtevVzBtajrgJPXEvQOH3azGK1O/3Wk=; b=aePiZ5QQ14VqZ9KP4aG7hxZM1k6MKhKVyXFQfnsMBaUJytPRY+Kd+UHtUCaBPWMJuv 3G7YVnz+l3sxRT56xVU7g38nUEgomBEUIeUD+9CzC0obsDvKSPlI94SeULqNKkTCZtju Vbnv+1X+ZhJniFyA7h1ved9wRj/N/5YMMT6F156577utMGvrsx0yxIh+V9QE09tcTp9E eIW/Ul2THKn3Sfu5zhM17xzdhI9gA9XwAVNbNWoxgEV1j8D3m46ki4aL6pQ3mj/hgW/S i0MWLYgLaeIVD0aNxZbBPq/K0UtLOWHCcxAL6WMOmrCcduhgO/mjPvOZRmvdoWCRDEk9 anYw== X-Received: by 10.112.130.138 with SMTP id oe10mr13685161lbb.1.1383030361117; Tue, 29 Oct 2013 00:06:01 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id vk8sm15538722lbb.0.2013.10.29.00.05.59 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 29 Oct 2013 00:06:00 -0700 (PDT) Message-ID: <8399B5EEED824D05B1ED9B1FF42A4810@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <5268055E.4000804@gmail.com><876DF97CB1AF4CA7B96634DDE3D51B1B@buildpc><21097.16245.405563.467088@fireball.kivinen.iki.fi> <21102.25426.68704.450938@fireball.kivinen.iki.fi> Date: Tue, 29 Oct 2013 11:05:57 +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: IPsecme WG Subject: Re: [IPsec] Working GroupLastCall:draft-kivinen-ipsecme-signature-auth-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: Tue, 29 Oct 2013 07:06:27 -0000 >> > And you can always retry when you notice that you get authentication >> > error after using private key, provided you have multiple types of >> > keys. >> >> In general you can't if it is responder who selected wrong key. > > That is something I realized on our way home, but it is easy to fix. > We add suggestion to the draft that the responder should use same type > of key than what initiator used. That will not work in case of EAP. >> I admit, that such situations are rare but not non-existent. >> And manual configuration is not an option for large VPNs. > > Large VPNs should use centralized management systems anyways, and all > of this is also avoidable by using suitable sub CA keys. You do not > need to change the root CA, it is enough to change the sub CA used to > signing the EE cert, and send CERTREQ containg that key instead. Usually corporate CA infrastructure is used not only for IPsec, and changing CA hierarchy will influence other services too. Sometimes it is unacceptable. >> Retry is not always possible and is a hack anyway. > > For initiator it is possiblity, for responder adding the text which > says it should use same algoritm than other end will solve the issue. > > I do not think it as a hack, we already do that in IKEv2 with > Diffie-Hellman group negotiation. On the other hand we do not want to > complicate the IKEv2 more by making the retry inside the exchange like > we do with INVALID_KE_PAYLOAD, but we could add new error notify that > the responder can send which says INVALID_AUTH_KEY_TYPE, and we could > even add supported key types in that notify. Or we can simply use the It is a good idea, but it will not work in case of EAP. If responder picks a wrong key, then initiator may send this notification, but it will require responder to keep this information somewhere untill initiator retries (if ever). Or we neet to complicate IKE_AUTH to make retry inside the exchange (as with INVALID_KE_PAYLOAD), this way it might work. But in this case it is more complex, than just announcing supported signature algorithms in IKE_SA_INIT. > AUTHENTICATION_FAILED notify and assume that it might have been > because of wrong key type, and as we do not have anything better to > do, we can simply retry. Nothing will go through the tunnel anyways > unless we do something... Not this way, please. That is a real protocol hack, IMHO... Valery. From lberger@labn.net Tue Oct 29 04:58:50 2013 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 D7FA421E812D for ; Tue, 29 Oct 2013 04:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USWHNQi1V-JO for ; Tue, 29 Oct 2013 04:58:45 -0700 (PDT) Received: from outbound-ss-1429.hostmonster.com (outbound-ss-1429.hostmonster.com [74.220.221.129]) by ietfa.amsl.com (Postfix) with SMTP id 6D08911E816B for ; Tue, 29 Oct 2013 04:58:12 -0700 (PDT) Received: (qmail 3403 invoked by uid 0); 29 Oct 2013 11:57:47 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.mail.unifiedlayer.com with SMTP; 29 Oct 2013 11:57:47 -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=a8nBeLjZq5op2t/qmjaloigrXu+8JIApAeOJ8l3wPmg=; b=YuuJpnFd3K5J3rD9DbCZ+qA/by/ZCSvNFVoJNiJj04YwQwrUWSl19dKNnpQyA7i27PQ5w/zQ2GA7k3lpY1ut9RZQBt33GsA3DKIIWPE1peYJcAmWF4fRiExXqlerTvT0; Received: from box313.bluehost.com ([69.89.31.113]:40303 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Vb7vf-0005jE-Fy; Tue, 29 Oct 2013 05:57:47 -0600 Message-ID: <526FA2BA.8080008@labn.net> Date: Tue, 29 Oct 2013 07:57:46 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Mike Sullenberger (mls)" References: <5261B62A.4020209@labn.net> <9D83DE546CB6DC47A3AE04086FDE35F523FADE2D@xmb-aln-x06.cisco.com> <5269434E.3050109@labn.net> <9D83DE546CB6DC47A3AE04086FDE35F523FB1719@xmb-aln-x06.cisco.com> In-Reply-To: <9D83DE546CB6DC47A3AE04086FDE35F523FB1719@xmb-aln-x06.cisco.com> X-Enigmail-Version: 1.5.2 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 , "draft-detienne-dmvpn@tools.ietf.org" Subject: Re: [IPsec] Some comments on draft-detienne-dmvpn-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: Tue, 29 Oct 2013 11:58:51 -0000 Mike, See below... Thanks, Lou On 10/28/2013 08:56 PM, Mike Sullenberger (mls) wrote: > Lou, > > Thanks, again answer inline :-). > > Mike. > > Mike Sullenberger, DSE > mls@cisco.com .:|:.:|:. > Customer Advocacy CISCO > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Thursday, October 24, 2013 8:57 AM >> To: Mike Sullenberger (mls) >> Cc: IPsecme WG; draft-detienne-dmvpn@tools.ietf.org >> Subject: Re: [IPsec] Some comments on draft-detienne-dmvpn-00 >> >> Hi Mike, >> >> Thanks for the response. See below... >> >> On 10/23/2013 2:54 PM, Mike Sullenberger (mls) wrote: >>> Lou, >>> >>> Thank you for your comments, more inline. >>> >>> Mike. >>> >>> Mike Sullenberger, DSE >>> mls@cisco.com .:|:.:|:. >>> Customer Advocacy CISCO >>> >>> >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: Friday, October 18, 2013 3:29 PM >>>> To: draft-detienne-dmvpn@tools.ietf.org >>>> Cc: IPsecme WG >>>> Subject: Some comments on draft-detienne-dmvpn-00 >>>> >>>> Hi, >>>> I have the following comments/questions on the draft: >>>> >>>> - Why allow IPsec tunnel mode? Is there a case where it provides some value? >>> >>> [Mike Sullenberger] >>> You are correct that IPsec tunnel mode is not really needed and >>> transport mode is far recommended and preferred. There are a couple of >>> rare situations where tunnel-mode could help, like when separating the >>> GRE/NHRP tunneling and IPsec encryption onto separate nodes, these >>> cases are not recommended, but we thought we should leave in the >>> possibility. >>> >> >> How does this work? >> >> As I understand it, NHRP is run inside the GRE tunnel so this means that the >> IPsec and GRE endpoints now need some way to communicate (for e.g., >> public ("NBMA") addresses and GRE/IPsec tunnel creation/removal >> coordination). >> >> Am I missing something? >> > > [Mike Sullenberger] > You have this correct, and basically we don't coordinate the NHRP and > IPsec databases in this case. It is expected that the IPsec node > will create IPsec SAs on demand due to GRE tunnel traffic and will > remove them when there is no more GRE tunnel traffic. This is > basically why we don't recommend this type of setup, but since I > don't know the future I hate to remove this possibility so that is > why supporting IPsec tunnel-mode is a "MAY" in the draft. > Sounds to me like this would be a different, and perhaps non-interoperable modes/solutions. Seems to me tunnel mode should be left out until the full solution is specified... >> >>>> - Do you want to recommend omitting the GRE checksum? >>> >>> [Mike Sullenberger] >>> Good idea, we definitely don't use the GRE checksum, and I don't think >>> it provides any value so we should recommend omitting it. I think >>> this is also the case for most of the other optional GRE header >>> attributes. >> >> >>> Though, the GRE Tunnel Key must be allowed, handled and provided. >>> >> >> I missed that the tunnel key MUST be "provided". Can you elaborate on >> this? I only see one oblique reference to it in the draft. > > [Mike Sullenberger] > For a node to support a single DMVPN you don't need a GRE tunnel key > and if the node supports multiple DMVPNs and each one has a different > tunnel source (NBMA) address, then again you don't need a GRE tunnel > key. Only if a single node is supporting multiple DMVPNs and is > using the same tunnel source (NBMA) address on them then you would > need a something to differentiate the GRE tunnel packets and > logically that would be the tunnel key. So given that perhaps > supporting a GRE tunnel key would be a "SHOULD" or "MAY". > This could > be an implementation detail, but we could still clarify this in the > draft. Clarifying it makes sense, particularly as it's applicability/need differs based on usage environment. >> >>>> - I think the draft should discuss what happens when the best route >>>> moves from one spoke to another spoke. Both the cases where the >>>> host/prefix is still reachable via the original spoke and when it >>>> isn't should be covered. As should avoiding blackholes, and any periods >> of suboptimal forwarding. >>> >>> [Mike Sullenberger] >>> We can add some more discussion around this point. The main feature >>> here is that this is handled by the routing protocol that is running >>> over the DMVPN tunnels. >> >> For clarification: routing runs over the configured DMVPN topology, but not >> shortcuts, right? > > [Mike Sullenberger] > That is correct. The reason that we don't run the routing protocol > over the shortcuts, is because the routing protocol has constant > traffic (hellos) which would tend to keep the shortcuts up and these > packets are a bit of a pain to filter out if needed. Also in this > case the routing protocol on the spokes would tend to get many > routing neighbors which could overwhelm the spoke, CPU-wise, and > overwhelm the routing protocol with too many forwarding options. > I think the dynamic adjacency issue could also be problematic for some routing protocols (and/or implementations) so this is good, but it does come at the cost of NHRP needing to carry / indicate all routes reachable over a shortcut. >> >>> The routing protocol will redirect the data packets via different >>> tunnels and/or spokes as the routing is updated. >> >> I think your answer to my next question actually helps answer this one. >> >> So Section 6.1 of RFC2332 says: >> ... In such >> circumstances, NHRP should not be used. This situation can be >> avoided if there are no "back door" paths between the entry and >> egress router outside of the NBMA subnetwork. Protocol mechanisms to >> relax these restrictions are under investigation. >> >> Do you believe this restriction still applies? > > [Mike Sullenberger] > I do not believe that this restriction applies. I have never seen an > issue along these lines where there wasn't a mis-design or > mis-configuration of the routing protocol. In DMVPN, NHRP uses the > routing protocol as the final source of truth for destinations > reachable through the VPN. If the routing protocol changes routing to > now not route packets through the VPN then NHRP needs to clear any > routing/forwarding/shortcuts that would forward to that destination > via the VPN. I think the mechanism to detect something like this is > implementation dependent, but we probably should mention that such a > mechanism may/should be provided. > Agreed. Also, I think you have to address the quoted text directly or assume that it applies here too. >> >>> Note, if static routing is used then you lose this capability. >> >> Sure. >>> >>>> - I think the draft is missing a description of how/when NHRP Purges >>>> are used, e.g., resulting from interactions with routing. (Yes there >>>> is an overlap with the above, but it depends a bit on your solution.) >>> >>> [Mike Sullenberger] >>> As you have noted, NHRP purges are used to keep the distributed NHRP >>> database in sync. If a local node loses access to a destination that >>> it has previously replied with itself as the egress point in an NHRP >>> mapping (and the entry hasn't timed out yet) then it will generate an >>> NHRP purge and send a copy to each requester (recorded when it sent >>> the original reply). This will then clear out these now invalid >>> mapping entries on the remote nodes and trigger them to find an >>> alternate path if available. Note, this is basically what is >>> described in NHRP (RFC2332), we didn't really want to duplicate this >>> in this RFC, but it could be added. >>> >> >> okay, I think this comes back to where the draft says: >>> In this document, we will depart the >>> underlying notion of a centralized NHS. >> >> I think the part that's missing (or perhaps I just missed) is an explicit >> statement that an egress must follow the NHS procedures related to any >> issued Resolution Reply. >> > > [Mike Sullenberger] > I think this is a place where we need to point to the NHRP RFC to follow for these procedures and any differences if any. > Is this what you are getting at? > Yes, that certainly would address my comment. >>>> - I the draft should discuss the NHRP scaling considerations that are >>>> important in implementation and deployment/operation. (Basically the >>>> solution is proposing network wide ARP.) You already have a teaser >>>> on this when you mention rate limiting. >>> >>> [Mike Sullenberger] >>> We can certainly do so. In DMVPN deployments we haven't really found >>> that NHRP scaling has been an issue. Usually we ran into either >>> Routing protocol or IPsec scaling issues first. It is correct we do >>> mention a couple of places about rate limiting triggering or sending >>> of NHRP messages, mainly because it wasn't felt that it was useful to >>> continue to "bother" another node if it was working on the previous >>> request, which was the same as the one to be sent again. Note, we do >>> have mechanisms for retransmission and back-off of messages. Again >>> some of this is covered in the NHRP RFC. >>> >> >> I guess it all depends on the number of routes in the system and >> reachability pattern at a particular spoke. I think when both are large, the >> use of per prefix soft state refreshes will prove problematic. I'm a bit >> surprised you've run into routing protocol scaling issues though, but that's >> certainly out of scope. > > [Mike Sullenberger] > Routing protocol scaling is only seen on the Hubs (NHSs), since they > are basically the route reflectors for the spokes. We don't normally > see any routing issues on the spokes. Spokes in general don't build > that many shortcuts and therefore don't have many per prefix > refreshes. Though in cases where a spoke may build out a 1000 > shortcuts, the refreshes since they are usually on the order of 10s > of minutes apart don't cause a scaling issue on the spoke. Also such > a spoke is normally a larger box, since it has to handle 1000+ > ISAKMP/IPsec SAs and the presumably the traffic that goes with it. > This all makes sense in simple topologies which match the RFC stated limitation and also are probably the most common. All good stuff for a scaling considerations section. How are you avoiding blackholes on shortcut failures that don't match any route/router changes? Are you assuming any keepalives/failure detection on the shortcuts? >>>> - NIT/editorial: If section 4 is your "Solution Overview", where is >>>> the solution specification? More seriously, I found parts of this >>>> section more of a narrative of an example than a protocol specification. >>> >>> [Mike Sullenberger] >>> Yes, I think this needs to be cleaned up. Since a lot of what we do >>> with NHRP is covered in the NHRP RFC we didn't want to duplicate too >>> much here, but we can certainly make a more clear solution >>> specification. I think the solution overview section is also useful >>> since, a walk through can help people to understand how the solution >>> is intended to work. Many times I find it hard with just solution >>> specifications to get a real feel for how things go together. >>> >> >> Avoiding duplicate specification is certainly goodness, but I think some >> additional pointers to when standard NHRP procedures are to be followed >> (or not) would be a valuable addition as part of the cleanup. > > [Mike Sullenberger] > Yes, we can add in more guidance along these lines. > > Your comments are a great help in solidifying what needs to be done for the next and following drafts. > Thanks, Lou > Thanks, > > Mike. > >> >> Much thanks, >> Lou >> >>>> - NIT: Assuming the Indirection Notification described in section 4.3 >>>> is the same as the NHRP Traffic Indication covered in 5.1, can you >>>> align the names and fix the reference in 4.3? >>> >>> [Mike Sullenberger] >>> Yes, thanks for noting this. We tend to use those terms interchangeably, >>> but we should be more consistent here. >>> >>>> >>>> Thanks, >>>> Lou >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> >>> > From paul@cypherpunks.ca Tue Oct 29 06:19:33 2013 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 7BF6A11E8233 for ; Tue, 29 Oct 2013 06:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMESLb2v+951 for ; Tue, 29 Oct 2013 06:19:27 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 41A3421E8113 for ; Tue, 29 Oct 2013 06:19:26 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d8D0R3k20zC4j; Tue, 29 Oct 2013 09:19:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id tSz5zCRgarRO; Tue, 29 Oct 2013 09:19:17 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 29 Oct 2013 09:19:17 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id BACC0807CA; Tue, 29 Oct 2013 09:19:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B3EDF800A9; Tue, 29 Oct 2013 09:19:17 -0400 (EDT) Date: Tue, 29 Oct 2013 09:19:17 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "ipsec@ietf.org WG" Subject: [IPsec] 5996bis 3.3.1 proposal structure 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, 29 Oct 2013 13:19:33 -0000 >From the 5996 bis 02 draft: 3.3.1. Proposal Substructure 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) or 2 | RESERVED | Proposal Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposal Num | Protocol ID | SPI Size |Num Transforms| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ SPI (variable) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Proposal Substructure o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the last Proposal Substructure in the SA. This syntax is inherited from ISAKMP, but is unnecessary because the last Proposal could be identified from the length of the SA. The value (2) corresponds to a payload type of Proposal in IKEv1, and the first four octets of the Proposal structure are designed to look somewhat like the header of a payload. It's a little confusing to me whether the first octet should be interpreted as a "flags" field with two (of eight) bit flags assigned or as a single octet that can have two values (0 or 2) and it will never get updated to contain other values. Are we ever planning on having values other then 0 or 2 ? If a byte, could we give this byte a "name" like we have done for the other proposal pieces? If bits, could we give this octet a name (proposal flags) and these bits names? (bit 0 being reserved and MUST be 0, bit 1 being "non-last proposal") Paul From kivinen@iki.fi Tue Oct 29 07:03:20 2013 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 796AB11E815F; Tue, 29 Oct 2013 07:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OB4BA36gGTkF; Tue, 29 Oct 2013 07:03: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 7536711E8258; Tue, 29 Oct 2013 07:03:19 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9TE3BN8021593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Oct 2013 16:03:11 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9TE3AFW029376; Tue, 29 Oct 2013 16:03:10 +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: <21103.49182.48692.325305@fireball.kivinen.iki.fi> Date: Tue, 29 Oct 2013 16:03:10 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <336D6D662DB0470DBFB3A576FFCB8E7F@buildpc> References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> <336D6D662DB0470DBFB3A576FFCB8E7F@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Cc: tsvwg , Joe Touch , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, Matt Mathis , tsv-dir@ietf.org Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 29 Oct 2013 14:03:20 -0000 Valery Smyslov writes: > Draft introduces IKE-level fragmentation to avoid IP fragmentation > whenever possible and to only let it be if it is impossible. Actually the first preference is to use IP fragmentation, and if that works, it is what we use, and we do not try IKE fragmentation at all. Only if the large packets do not go through then we try to enable IKE fragmentation and so on... So all of this draft is used only if there is some device on the path that will drop at least some fragments somewhere. And yes, we might miscategorize some network errors as IP fragments getting lost, as we have no indication from the network whether the packet was lost because it got fragmented on the IP level, or for some reasons. There is no way IKEv2 could even get that information, so we assume that if multiple full size retransmission of IKEv2 packets are lost, then there might be fragmentation issue, and we enable IKE fragmentation. > But if it is unavoidable, then there are more chances for IKE to > work if IP fragments exist only on the part of the path, i.e. when > fragmentation is done by intermediate device. Yep. -- kivinen@iki.fi From kivinen@iki.fi Tue Oct 29 07:12:19 2013 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 3277411E823E for ; Tue, 29 Oct 2013 07:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhS+KpStWAFS for ; Tue, 29 Oct 2013 07:12:18 -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 5C53611E815F for ; Tue, 29 Oct 2013 07:12:15 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9TECDHD010100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Oct 2013 16:12:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9TECDZ5001641; Tue, 29 Oct 2013 16:12:13 +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: <21103.49725.643646.153092@fireball.kivinen.iki.fi> Date: Tue, 29 Oct 2013 16:12:13 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <8399B5EEED824D05B1ED9B1FF42A4810@buildpc> References: <5268055E.4000804@gmail.com> <876DF97CB1AF4CA7B96634DDE3D51B1B@buildpc> <21097.16245.405563.467088@fireball.kivinen.iki.fi> <21102.25426.68704.450938@fireball.kivinen.iki.fi> <8399B5EEED824D05B1ED9B1FF42A4810@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Cc: IPsecme WG Subject: Re: [IPsec] Working GroupLastCall:draft-kivinen-ipsecme-signature-auth-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: Tue, 29 Oct 2013 14:12:19 -0000 Valery Smyslov writes: > >> > And you can always retry when you notice that you get authentication > >> > error after using private key, provided you have multiple types of > >> > keys. > >> > >> In general you can't if it is responder who selected wrong key. > > > > That is something I realized on our way home, but it is easy to fix. > > We add suggestion to the draft that the responder should use same type > > of key than what initiator used. > > That will not work in case of EAP. True, so in that case the Initiator needs to use proper CERTREQ or IDr payload to indicate to which responder key he wants other end to pick. If you are not happy with CERTREQs doing that you can also use the IDr in the IKE_AUTH request to tell from the initiator which key should be used by the responder. > Usually corporate CA infrastructure is used not only for IPsec, > and changing CA hierarchy will influence other services too. > Sometimes it is unacceptable. So then use IDr. That is what it is meant for. I.e. for the initiator to tell the responder which of multiple identities the responder has it is connecting to. If responder has multiple keys with different algorithms, you can configure each of them having different identity and use that to separate them. > It is a good idea, but it will not work in case of EAP. If responder picks > a wrong key, then initiator may send this notification, but it will > require responder to keep this information somewhere untill > initiator retries (if ever). Yes, it only works if the initiator picked wrong key. On the other hand as I pointed out there are already 3 ways for the responder to pick right key (optional IDr in initiators IKE_AUTH request, CERTREQ, and AUTH payload sent by the initiator). > Or we neet to complicate IKE_AUTH > to make retry inside the exchange (as with INVALID_KE_PAYLOAD), > this way it might work. But in this case it is more complex, than just > announcing supported signature algorithms in IKE_SA_INIT. Or we just say it is local implementation issue, as I do not really belive this will happen in real world that often. Or we just say that implementations having multiple types of public keys SHOULD use different IDr for each of the keys if there is any possibility that initiators do not support all of the public key types. -- kivinen@iki.fi From kivinen@iki.fi Tue Oct 29 07:18:43 2013 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 EC28711E825F for ; Tue, 29 Oct 2013 07:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Re1U8VzCev-9 for ; Tue, 29 Oct 2013 07:18:43 -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 F262111E825C for ; Tue, 29 Oct 2013 07:18:42 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9TEIb2D022790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Oct 2013 16:18:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9TEIbpM019344; Tue, 29 Oct 2013 16:18:37 +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: <21103.50109.281784.791771@fireball.kivinen.iki.fi> Date: Tue, 29 Oct 2013 16:18:37 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Cc: "ipsec@ietf.org WG" Subject: [IPsec] 5996bis 3.3.1 proposal structure 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, 29 Oct 2013 14:18:44 -0000 Paul Wouters writes: > 3.3.1. Proposal Substructure > > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 0 (last) or 2 | RESERVED | Proposal Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Proposal Num | Protocol ID | SPI Size |Num Transforms| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ SPI (variable) ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 7: Proposal Substructure > > o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the > last Proposal Substructure in the SA. This syntax is inherited > from ISAKMP, but is unnecessary because the last Proposal could be > identified from the length of the SA. The value (2) corresponds > to a payload type of Proposal in IKEv1, and the first four octets > of the Proposal structure are designed to look somewhat like the > header of a payload. > > > It's a little confusing to me whether the first octet should be > interpreted as a "flags" field with two (of eight) bit flags assigned > or as a single octet that can have two values (0 or 2) and it will never > get updated to contain other values. It is one octect, and it used to have name called Next Payload, but as we use that already in the IKEv2 we do not want to reuse it here. The text quite clearly says "1 octect", which indicates it is not bitfield or flags, but one byte having values of 0 or 2. > Are we ever planning on having values other then 0 or 2 ? No. > If a byte, could we give this byte a "name" like we have done for the other > proposal pieces? I think the name was explictly removed to make it clear that we do not assume this to be Next Payload structure of the embedded payloads having embedded payloads. Same thing with the Transforms substructure. > If bits, could we give this octet a name (proposal flags) and these bits names? > (bit 0 being reserved and MUST be 0, bit 1 being "non-last proposal") I do not think we want to change this part of the text. The text tells that this was supposed to look somewhat like the header of the payload and I think that should make the payload clear enough. -- kivinen@iki.fi From paul@cypherpunks.ca Tue Oct 29 07:51:37 2013 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 2D19B11E82B7 for ; Tue, 29 Oct 2013 07:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNpdJ5nU8Hee for ; Tue, 29 Oct 2013 07:51:31 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 73C8B11E8136 for ; Tue, 29 Oct 2013 07:46:52 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d8Fwq702ZzC4t; Tue, 29 Oct 2013 10:46:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id D_aihlQs6Ot2; Tue, 29 Oct 2013 10:46:18 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 29 Oct 2013 10:46:18 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 0FE2C807CA; Tue, 29 Oct 2013 10:46:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E2D4C800A9; Tue, 29 Oct 2013 10:46:18 -0400 (EDT) Date: Tue, 29 Oct 2013 10:46:18 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: <21103.50109.281784.791771@fireball.kivinen.iki.fi> Message-ID: References: <21103.50109.281784.791771@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] 5996bis 3.3.1 proposal structure 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, 29 Oct 2013 14:51:37 -0000 On Tue, 29 Oct 2013, Tero Kivinen wrote: > The text quite clearly says "1 octect", which indicates it is not > bitfield or flags, but one byte having values of 0 or 2. It does say that clearly, but I wanted to confirm it was not a mistake, >> Are we ever planning on having values other then 0 or 2 ? > > No. Ok good. > I think the name was explictly removed to make it clear that we do not > assume this to be Next Payload structure of the embedded payloads > having embedded payloads. Same thing with the Transforms substructure. > >> If bits, could we give this octet a name (proposal flags) and these bits names? >> (bit 0 being reserved and MUST be 0, bit 1 being "non-last proposal") > > I do not think we want to change this part of the text. The text tells > that this was supposed to look somewhat like the header of the > payload and I think that should make the payload clear enough. Implementors still need to name that struct. Instead of everyone coming up with their own name it would be good to have a standard name for it. For example, the reason I'm looking at this was because the openswan implementation actually called the struct isap_np and when it failed to map an IKEv2 next payload type to it, failed. Libreswan is now calling it isap_lp for "last proposal" and it will no longer accept IKEv1 next payload types, which openswan was doing. In a way, I think we did a disservce to implementors by re-using these values and clunking it into ikev1 values. It may lead to other ikev1 values (eg for Next Payload Type) bleeding into ikev2 by accident by agile implementors :P So just naming it in the RFC like we do for the other IKEv2 proposal fields would be useful. I would suggest "last payload". Paul From mattmathis@google.com Mon Oct 28 15:22:35 2013 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 5813611E82B2 for ; Mon, 28 Oct 2013 15:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEQk0pxr-vQS for ; Mon, 28 Oct 2013 15:22:34 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE0111E82AA for ; Mon, 28 Oct 2013 15:22:30 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id aq17so12767903iec.34 for ; Mon, 28 Oct 2013 15:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LEELEPVdHe9MAVJj8IkJ5cZ7hDWuKIdbeg64dIBHDv8=; b=TEUHFdy52Luns3VBMfV/zVq1VGixeDsTV1/wPvXaNUyi0xdBNVTwkXyw/Ace1Pcxo3 OFyaZj8GNqmpUDbepvQEkdzYrq2X4gW96xfluVAZTbp1EAtsfwzK3psnzlQKFkx5mt+x 433jxsy1ie1kWycWBE3zwz38un7A03H1TuQafXo1exHWqp6bFfgIwdnoPdqn+iuzTHnk Xl8yDCCJEVZC+ZDd/aR/VdKuReIWSZs9ed5SUs9v7vwyY2bSqK9UZo41JRne/hBCdSIm NFkfIXcW8cZ0/+QK1fRgKSD+66FilsQt/IyDy2IeViNfagKwuPEr3iuv2DgqTWeuEUYH zlRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LEELEPVdHe9MAVJj8IkJ5cZ7hDWuKIdbeg64dIBHDv8=; b=EGCzzDFZNWJGSO8wrEYJMwsEBA1qTelgI7ZIhzPH9/buRFGmTHizWhtCP6RVDm9HeR h90n775cJbIPosNC+/5+HcxqYtlcJ5zJaFUHMYuS3qXhxsDI3ex32J6xCRuvsz99sDTp //ez+j5mjr+BNg73r7flwTZBoRETigXoPH5frncoeOfm94W2lB0GChAORKp2hU0hHLLI KiAcj/2x2OKP+6rUyZT2o9CSzjgRpbrnsGc4zQG1lwYC9LlUoSW3NkDK5j6DSoJ7/S1z pQE9pNQBPFq8xpY7rJRBfjWWtm7MQ4Is69NkmdYbRw5zuGvYoiTsTHgbEq6JOhVue3yG GxKA== X-Gm-Message-State: ALoCoQmF2wKvpxlxtire7WSmZo8HQXYI6Xo/lCsrmlO6iPXoUhF1+6MzHXv8JlaWGXYSXs3Jm1IL2UPUqfqifU0LtWV+2jfdGmWxlCnFxvyqiEpNch50Y0vKVHmww2GmptKGmZXrHIsQC/fMc9P5B/6ZybN9y3hVOi8qBhpmnIeCb0uMvBO4x3sD2yO7YuiR/zzcCWd0lGuO MIME-Version: 1.0 X-Received: by 10.50.23.16 with SMTP id i16mr10191213igf.50.1382998950018; Mon, 28 Oct 2013 15:22:30 -0700 (PDT) Received: by 10.64.243.66 with HTTP; Mon, 28 Oct 2013 15:22:29 -0700 (PDT) In-Reply-To: References: <51FA6A6C.8090803@gmail.com> <523CB65D.1090904@neclab.eu> <523CB9CB.7060507@isi.edu> <5265C19B.30108@isi.edu> <14DB3765679C45D283869DC9010F0084@buildpc> <52669960.1000706@isi.edu> <5268060B.4060604@isi.edu> <81953CE6126542A8AD40207921B8E018@buildpc> <52695365.4070803@isi.edu> <526AD233.3090109@isi.edu> Date: Mon, 28 Oct 2013 15:22:29 -0700 Message-ID: From: Matt Mathis To: Valery Smyslov Content-Type: multipart/alternative; boundary=089e0158a9aa24304c04e9d489eb X-Mailman-Approved-At: Tue, 29 Oct 2013 08:40:24 -0700 Cc: tsvwg , Joe Touch , tsv-ads@tools.ietf.org, ipsec@ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org, "tsv-dir@ietf.org" Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 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, 28 Oct 2013 22:22:35 -0000 --089e0158a9aa24304c04e9d489eb Content-Type: text/plain; charset=ISO-8859-1 Setting DF is supposed to prevent some midpath IPv4 device from silently "fixing" a MTU problem by doing you a favor that you don't want. IPv4 fragmentation can be used in a mode that mimics IPv6: Only fragment on the originating host, always set DF on on all outbound packets, even if they are already fragmented. Any protocol or application that does not work in this configuration will also fail on IPv6. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Sun, Oct 27, 2013 at 10:50 PM, Valery Smyslov wrote: > ** > Hi Matt, > > the whole idea of the draft is avoiding IP fragmentation for IKE when > it prevents IKE to work. What about DF bit - I don't see how setting it > would help IKE to work. > > Regards, > Valery. > > > ----- Original Message ----- > *From:* Matt Mathis > *To:* Valery Smyslov > *Cc:* tsvwg ; tsv-ads@tools.ietf.org ; ipsec@ietf.org ; > draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org ; tsv-dir@ietf.org; Joe > Touch > *Sent:* Saturday, October 26, 2013 12:41 AM > *Subject:* Re: [tsvwg] [IPsec] TSVDIR-ish > reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 > > I concur with Joe: once you have enough machinery work well with IPv6 > fragmentation semantics, you should use it for IPv4 too, and > unconditionally set DF. This probably applies to *all* protocols. > > IPv4 reassembly is hopelessly out of scale. IP ID wrap times are likely > to be sub second for any large CGN connecting to any large service..... > They might even be shorter than the queuing times. > > I suspect that if you re-review decade old papers on fragmentation, you > will find some scale assumptions that are no longer correct. In that time > the Internet has moved at least another two orders of magnitude in packet > rates. > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > > Privacy matters! We know from recent events that people are using our > services to speak in defiance of unjust governments. We treat privacy and > security as matters of life and death, because for some users, they are. > > > On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch wrote: > >> >> >> On 10/24/2013 10:45 PM, Valery Smyslov wrote: >> ... >> >>> You're using existing IKE messages *and* existing timeouts to >>>> determine when there is a problem. A separate timer would be useful, >>>> if only to allow you to decouple fragment retransmission from IKE >>>> transaction retries. >>>> >>> >>> No, the timeouts are different. I should have made it more expplicit in >>> the draft. >>> >> >> That'd be useful. >> >> ... >> >>> Always setting DF bit in this case will probably increase the delay >>> before IKE SA is set up (as more probes will need to be done). >>> >> >> Except that if you continue to allow IP fragmentation, you can't claim >> your solution is robust to IP fragment poisoning. >> >> Note, that this approach is in line with advices, given for IKE in the >>>>> paper >>>>> >>>>> C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection >>>>> for UDP-based protocols", ACM Conference on Computer and >>>>> Communications Security, October 2003. >>>>> >>>> >>>> That paper doesn't consider IKE-level fragmentation, which you're >>>> introducing. I agree that DF=0 for IKE without IKE-level fragmentation. >>>> >>> >>> It does, in Section 3.3. >>> >> >> Sorry - I missed that. But that section also gives good reasons why this >> is a bad idea in IKE too. >> >> Joe >> > > --089e0158a9aa24304c04e9d489eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Setting DF is supposed to prevent some midpath IPv4 device= from silently "fixing" a MTU problem by doing you a favor that y= ou don't want.

IPv4 fragmentation can be used in a m= ode that mimics IPv6: Only fragment on the originating host, always set DF = on on all outbound packets, even if they are already fragmented. =A0 =A0 An= y protocol or application that does not work in this configuration will als= o fail on IPv6.

Thanks,
--MM--
The best way to predict the future is to create i= t. =A0- Alan Kay

Privacy matters! =A0We know from recent events that= people are using our services to speak in defiance of unjust governments. = =A0 We treat privacy and security as matters of life and death, because for= some users, they are.


On Sun, Oct 27, 2013 at 10:50 PM, Valery= Smyslov <svanru@gmail.com> wrote:
Hi Matt,
=A0
the whole idea of the draft is avoiding IP fragmentation for=20 IKE when
it prevents IKE to work. What about DF bit=20 - I don't=A0see how setting it
would help IKE to work.
=A0
Regards,
Valery.
=A0
----- Original Message -----
From:=20 Matt=20 Mathis
Sent: Saturday, October 26, 2013 12= :41=20 AM
Subject: Re: [tsvwg] [IPsec] TSVDIR= -ish=20 reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

I concur with Joe: once you have enough machinery work w= ell with=20 IPv6 fragmentation semantics, you should use it for IPv4 too, and=20 unconditionally set DF. =A0 This probably applies to *all* protocols.

IPv4 reassembly is hopelessly out of scale. =A0IP ID wrap times are= =20 likely to be sub second for any large CGN connecting to any large service= .....=20 =A0They might even be shorter than the queuing times.

I suspect that if you re-review decade old papers on fragmentation, = you=20 will find some scale assumptions that are no longer correct. =A0In that= =20 time the Internet has moved at least another two orders of magnitude in p= acket=20 rates.

Thanks,
--MM--
The best way to predict the future is to crea= te=20 it. =A0- Alan Kay

Privacy matters! =A0We know from recent events= =20 that people are using our services to speak in defiance of unjust governm= ents.=20 =A0 We treat privacy and security as matters of life and death, because f= or=20 some users, they are.


On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch <touch= @isi.edu> wrote:


On 10/24/2013 10:45 PM, Val= ery Smyslov=20 wrote:
...
You're using existing IKE m= essages *and* existing=20 timeouts to
determine when there is a problem. A separate timer = would=20 be useful,
if only to allow you to decouple fragment retransmiss= ion=20 from IKE
transaction retries.

No, the= =20 timeouts are different. I should have made it more expplicit in
th= e=20 draft.

That'd be useful.

...
Always setting DF bit in this cas= e will probably=20 increase the delay
before IKE SA is set up (as more probes will ne= ed to=20 be done).

Except that if you continue to allow IP= =20 fragmentation, you can't claim your solution is robust to IP fragme= nt=20 poisoning.

Note, that this approach is i= n line with advices,=20 given for IKE in the
paper

C. Kaufman, R. Perlman, and = B.=20 Sommerfeld, "DoS protection
=A0 =A0 =A0 =A0 =A0=20 =A0 =A0 for UDP-based protocols", ACM Conference on Computer= =20 and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Communications=20 Security, October 2003.

That paper doesn'= t consider=20 IKE-level fragmentation, which you're
introducing. I agree t= hat DF=3D0=20 for IKE without IKE-level fragmentation.

= It=20 does, in Section 3.3.

Sorry - I missed that. But = that=20 section also gives good reasons why this is a bad idea in IKE too.

Joe

--089e0158a9aa24304c04e9d489eb-- From svanru@gmail.com Wed Oct 30 00:23:08 2013 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 5895A11E8105 for ; Wed, 30 Oct 2013 00:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbeYROSImaaG for ; Wed, 30 Oct 2013 00:23:07 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8934211E8168 for ; Wed, 30 Oct 2013 00:23:07 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id ea20so749922lab.10 for ; Wed, 30 Oct 2013 00:23:06 -0700 (PDT) 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; bh=TiNBS3Z4or2BaGEx32FKUt6ygQ8zCY0l4aFAYWuOFIw=; b=ix8T3+DK4Y4iMW1lbmNdLCMdUY6LGSas2L+B1N1FocAAds0iGjs1ldwW/2Xy+e1lMV PK0vLDsEH41TL/Y/Wm2rbooj6IzZvlvAiFIDc/ILhWQU6UGqZjNkWv9btzA4o8QjJtKo BJoMpzGBrhUbgfTHjdzm/Iy/KhnvqErBIm+FRHWrITo9hDJv4w5MRIoMMZYtx2xZK0I9 JJW9wsIM1hClRulZ2jrklIc1PIVFQMJ+6bmIIRsIl1czedKQQSHp/m6joZMc44oJYl/A 5VIZM5SDjdgwdkhwtiTz/gFjIUeEfTeGjvN4D1qftwu0ArVni5oRfoeaK76iUR2I4Rg5 cF/g== X-Received: by 10.152.88.74 with SMTP id be10mr2329323lab.4.1383117786401; Wed, 30 Oct 2013 00:23:06 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id b1sm29648626lah.6.2013.10.30.00.23.04 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 30 Oct 2013 00:23:05 -0700 (PDT) Message-ID: <2DDCD415D9D3403FA3A683EC19946106@buildpc> From: "Valery Smyslov" To: "Yoav Nir" , References: <20131015064906.2100.68545.idtracker@ietfa.amsl.com> Date: Wed, 30 Oct 2013 11:23:08 +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] Fwd: New Version Notification fordraft-nir-ipsecme-cafr-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: Wed, 30 Oct 2013 07:23:08 -0000 Hi Yoav, > Third version of this draft, now including Tero's comments. some comments on new version. First, some stuff seems to be left from previous version, which supposed that new IKE SPIs are sent in both directions: - third bullet in Section 2.2 - figure 2 in Section 3 Then, there is a related issue with re-authentication. Your draft says, that re-authentication is done as part of a risk management policy. Usually it is a security gateway, that enforces such a policy. The problem is, that with EAP authentication, gateway cannot initiate re-authentication. The only thing it can do - delete existing IKE SA in hope, that client will reestablich it anew. And with this behaviour you draft becomes much less useful. I think, that it could be solved, if we define new notification, that could be optionally sent from gateway to client, informing him that gateway is going to delete IKE SA in some time interval (indicating that interval in the notification). If cafr is supported by client and he is willing to use it, client will start re-authentication before the end of the interval. If not - gateway will just delete IKE SA after the interval has ended. Valery. From ynir@checkpoint.com Wed Oct 30 01:11:14 2013 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 95CA521E80E4 for ; Wed, 30 Oct 2013 01:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.48 X-Spam-Level: X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITgh16C74qbq for ; Wed, 30 Oct 2013 01:11:08 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CAFF421E80EB for ; Wed, 30 Oct 2013 01:11:06 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9U8B4In009213; Wed, 30 Oct 2013 10:11:04 +0200 X-CheckPoint: {5270BE15-2E-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 30 Oct 2013 10:11:04 +0200 From: Yoav Nir To: Valery Smyslov Thread-Topic: [IPsec] Fwd: New Version Notification fordraft-nir-ipsecme-cafr-03.txt Thread-Index: AQHO1UDs17hVkP4r6EqR4uUMeqXziZoMwxwA Date: Wed, 30 Oct 2013 08:11:03 +0000 Message-ID: <186950AC-4F7C-4A07-91BA-68C7D2004641@checkpoint.com> References: <20131015064906.2100.68545.idtracker@ietfa.amsl.com> <2DDCD415D9D3403FA3A683EC19946106@buildpc> In-Reply-To: <2DDCD415D9D3403FA3A683EC19946106@buildpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.34] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <24AA9E86D1810848B24AEEDAB764A6A7@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] Fwd: New Version Notification fordraft-nir-ipsecme-cafr-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: Wed, 30 Oct 2013 08:11:15 -0000 On Oct 30, 2013, at 9:23 AM, Valery Smyslov wrote: > Hi Yoav, >=20 >> Third version of this draft, now including Tero's comments. >=20 > some comments on new version. >=20 > First, some stuff seems to be left from previous version, which > supposed that new IKE SPIs are sent in both directions: > - third bullet in Section 2.2 > - figure 2 in Section 3 Right. Will fix. > Then, there is a related issue with re-authentication. > Your draft says, that re-authentication is done as part of a risk managem= ent > policy. Usually it is a security gateway, that enforces such a policy. > The problem is, that with EAP authentication, gateway cannot > initiate re-authentication. The only thing it can do - delete existing > IKE SA in hope, that client will reestablich it anew. And with > this behaviour you draft becomes much less useful. >=20 > I think, that it could be solved, if we define new notification, > that could be optionally sent from gateway to client, informing him > that gateway is going to delete IKE SA in some time > interval (indicating that interval in the notification). > If cafr is supported by client and he is willing to use it, > client will start re-authentication before the end of > the interval. If not - gateway will just delete IKE SA > after the interval has ended. Good idea! :-) http://tools.ietf.org/html/rfc4478 Think I should mention that in the draft? Yoav From svanru@gmail.com Wed Oct 30 03:32:34 2013 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 2FB3D11E8146 for ; Wed, 30 Oct 2013 03:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRvZjW2gpf4R for ; Wed, 30 Oct 2013 03:32:33 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 49CE111E8118 for ; Wed, 30 Oct 2013 03:32:22 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id ea20so906329lab.29 for ; Wed, 30 Oct 2013 03:32:21 -0700 (PDT) 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; bh=s0Bc0FUryrpn5Sd5+vTC8kQ7Zvma0tcptiDPIw5QgGE=; b=xwckSpjyD9SffWxcVCzGzRa7Cr0KL56jBvEj+IvNhy0v4SSJ2w1NH9ILuzz95R9XWa yq2AxOuRzmzlqUz8Fu0SBv7RCPVzns63O/NCeBH4r0czo+wNzJMT96McN3dSR3Jkku42 uRJ7sfksNxFkDoq1e8hGiJWoR9QSUxVFtcsSIGlVJ7CL9Xbc//YOiHuq3zVH1CIjiVlz 1WXCQzCLkR6g4GofNXJyBuuHaiyjTJi2FI+qbBsSUrKGUqxmK2v/Rt29Hsrw7zpmlUtQ ALi7ey2yJeWAQYNS8aaG/KZE8nlkuDhTn+ZkwGGpDFFIZE5DEkLFxHhiW9vyIl3SE6d7 fZsw== X-Received: by 10.112.136.195 with SMTP id qc3mr534906lbb.55.1383129141146; Wed, 30 Oct 2013 03:32:21 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id yr8sm27302360lab.4.2013.10.30.03.32.19 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 30 Oct 2013 03:32:20 -0700 (PDT) Message-ID: <75907DF3EB30475C958DE137EBFACFD0@buildpc> From: "Valery Smyslov" To: "Yoav Nir" References: <20131015064906.2100.68545.idtracker@ietfa.amsl.com> <2DDCD415D9D3403FA3A683EC19946106@buildpc> <186950AC-4F7C-4A07-91BA-68C7D2004641@checkpoint.com> Date: Wed, 30 Oct 2013 14:32:23 +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] Fwd: New Version Notificationfordraft-nir-ipsecme-cafr-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: Wed, 30 Oct 2013 10:32:34 -0000 >> I think, that it could be solved, if we define new notification, >> that could be optionally sent from gateway to client, informing him >> that gateway is going to delete IKE SA in some time >> interval (indicating that interval in the notification). >> If cafr is supported by client and he is willing to use it, >> client will start re-authentication before the end of >> the interval. If not - gateway will just delete IKE SA >> after the interval has ended. > > Good idea! :-) > > http://tools.ietf.org/html/rfc4478 Sorry, I completely forgot about this RFC. Happened funny :-) > Think I should mention that in the draft? I think yes. BTW, it is only experimental, while your draft's intended status is standards track. From ynir@checkpoint.com Wed Oct 30 03:59:46 2013 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 1FE6711E8151 for ; Wed, 30 Oct 2013 03:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.483 X-Spam-Level: X-Spam-Status: No, score=-10.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUSfOUKBrtNM for ; Wed, 30 Oct 2013 03:59:41 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9A09A11E8146 for ; Wed, 30 Oct 2013 03:59:37 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9UAxZID022305; Wed, 30 Oct 2013 12:59:35 +0200 X-CheckPoint: {5270E592-29-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 30 Oct 2013 12:59:34 +0200 From: Yoav Nir To: Valery Smyslov Thread-Topic: [IPsec] New Version Notificationfordraft-nir-ipsecme-cafr-03.txt Thread-Index: AQHO1V8evQjYqy6qB0aOnW0/TWHoUw== Date: Wed, 30 Oct 2013 10:59:34 +0000 Message-ID: <2FC25825-661B-4165-A7B4-7B4D02DFFE74@checkpoint.com> References: <20131015064906.2100.68545.idtracker@ietfa.amsl.com> <2DDCD415D9D3403FA3A683EC19946106@buildpc> <186950AC-4F7C-4A07-91BA-68C7D2004641@checkpoint.com> <75907DF3EB30475C958DE137EBFACFD0@buildpc> In-Reply-To: <75907DF3EB30475C958DE137EBFACFD0@buildpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.34] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7B54E70FFA4C3047AA67A2E2478C1DE6@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [IPsec] New Version Notificationfordraft-nir-ipsecme-cafr-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: Wed, 30 Oct 2013 10:59:46 -0000 On Oct 30, 2013, at 12:32 PM, Valery Smyslov wrote: >>> I think, that it could be solved, if we define new notification, >>> that could be optionally sent from gateway to client, informing him >>> that gateway is going to delete IKE SA in some time >>> interval (indicating that interval in the notification). >>> If cafr is supported by client and he is willing to use it, >>> client will start re-authentication before the end of >>> the interval. If not - gateway will just delete IKE SA >>> after the interval has ended. >>=20 >> Good idea! :-) >>=20 >> http://tools.ietf.org/html/rfc4478 >=20 > Sorry, I completely forgot about this RFC. > Happened funny :-) >=20 >> Think I should mention that in the draft? >=20 > I think yes.=20 > BTW, it is only experimental, while your draft's intended status is stand= ards track. At one time I asked Pasi (the security AD at the time) about updating it to= PS (there were 3-4 interoperating implementations at the time), and he sai= d that it wasn't worth the trouble because even full standards could refere= nce it - downrefs are allowed.= From svanru@gmail.com Wed Oct 30 04:40:32 2013 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 647D611E8115 for ; Wed, 30 Oct 2013 04:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyYD0bCVUSE1 for ; Wed, 30 Oct 2013 04:40:30 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id CD2EA11E8121 for ; Wed, 30 Oct 2013 04:40:28 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gx14so983612lab.27 for ; Wed, 30 Oct 2013 04:40:27 -0700 (PDT) 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; bh=SNduf/SwCvXMVoGVZfVqakJnNhqTgcj6Is4R/kDZoJU=; b=JhckcW7r/xKEGO8dJ1zLGwKqNLcgWUeAc1MnIe/jEQtK86TgFrjnWdQfr0VttLVReD R6k2veFjRJDmCB4ZLPcpANpGH+JX663j+6G/3GmkvaBpqDZmfOrY/Sif0qnZw2FogT/Z 7opHRPEZ67XytJBd9S+nVTpzx1Ez/a2Lp4zx652JIZl+ovviYJT5K3Wu8bIVRoMcxWuf uTZXfGWUgPcU5/9Xpm7tYuyyvCkqV/QF88lwcZvwLjw0uT06/Cn5l2iPs+nq2FU9L5cj CRGCxRsKh9SCJjLTC1mLWiJ0fkHxNUyb8amhHz3MUFIB1o77o+DQedBU9WQXJ3cIbJn8 s6vw== X-Received: by 10.152.180.139 with SMTP id do11mr2879942lac.23.1383133227806; Wed, 30 Oct 2013 04:40:27 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id oc1sm19779875lbb.3.2013.10.30.04.40.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 30 Oct 2013 04:40:26 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <5268055E.4000804@gmail.com><876DF97CB1AF4CA7B96634DDE3D51B1B@buildpc><21097.16245.405563.467088@fireball.kivinen.iki.fi><21102.25426.68704.450938@fireball.kivinen.iki.fi><8399B5EEED824D05B1ED9B1FF42A4810@buildpc> <21103.49725.643646.153092@fireball.kivinen.iki.fi> Date: Wed, 30 Oct 2013 15:40:28 +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: IPsecme WG Subject: Re: [IPsec] Working GroupLastCall:draft-kivinen-ipsecme-signature-auth-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: Wed, 30 Oct 2013 11:40:32 -0000 >> > We add suggestion to the draft that the responder should use same type >> > of key than what initiator used. >> >> That will not work in case of EAP. > > True, so in that case the Initiator needs to use proper CERTREQ or IDr > payload to indicate to which responder key he wants other end to pick. We already discussed CERTREQ, it may not always be an indicator. The same for IDr - IDs are supposed to remain the same with different keys. >> Usually corporate CA infrastructure is used not only for IPsec, >> and changing CA hierarchy will influence other services too. >> Sometimes it is unacceptable. > > So then use IDr. That is what it is meant for. I.e. for the initiator > to tell the responder which of multiple identities the responder has > it is connecting to. If responder has multiple keys with different > algorithms, you can configure each of them having different identity > and use that to separate them. Identities are usually linked to certificate's Subject (or AltSubject) field. And those fields will most probably be the same with different key types. >> It is a good idea, but it will not work in case of EAP. If responder >> picks >> a wrong key, then initiator may send this notification, but it will >> require responder to keep this information somewhere untill >> initiator retries (if ever). > > Yes, it only works if the initiator picked wrong key. On the other > hand as I pointed out there are already 3 ways for the responder to > pick right key (optional IDr in initiators IKE_AUTH request, CERTREQ, > and AUTH payload sent by the initiator). And none of them looks good. > Or we just say it is local implementation issue, as I do not really > belive this will happen in real world that often. Or we just say that > implementations having multiple types of public keys SHOULD use > different IDr for each of the keys if there is any possibility that > initiators do not support all of the public key types. Of course we can always leave it to implemetations by the cost of lacking interoperability in such situations. From eronenp@gmail.com Thu Oct 31 00:56:47 2013 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 BE9D011E8183 for ; Thu, 31 Oct 2013 00:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.311 X-Spam-Level: X-Spam-Status: No, score=-100.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7EximPBVWq5 for ; Thu, 31 Oct 2013 00:56:47 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0282C11E8133 for ; Thu, 31 Oct 2013 00:56:44 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id jz11so1819179veb.12 for ; Thu, 31 Oct 2013 00:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=HuCvMuFbWbigmliiMo7dL386/BcxcsfD4OOunAtLc8Y=; b=c1WhrLMP9BayXtgUxrBzAJJ6hxdv8c8qSAE1BaKXk3UOErBU34NxLSmmR3UCNqH5m7 RsD5Og/+LgGs3QwyqBZxWiQ6W27c6l8HNxdAsqRk/k+VIbX9eGWrB0VscI/YoS0nD1Cg KjxQmikh2Q8JhdtSueURHYNsR0Xh5HeRrViooruiLaX+LxH0Gcw2UuM5CoS/+EVAr09r zcy80ty1FnSMf/hU7xic8w6u/HkNIMQg/3LdY9IkkpDvMTTPF1TCjSBb6n+0swduB5B/ +pricEVM22vWFYgPMNJq6SFgRpuBtxNF/jlkmgmzcblgfAQ+oIqXIfq5f0ONzgDGVE7Y 8e6Q== MIME-Version: 1.0 X-Received: by 10.221.53.74 with SMTP id vp10mr141415vcb.54.1383206204525; Thu, 31 Oct 2013 00:56:44 -0700 (PDT) Sender: eronenp@gmail.com Received: by 10.220.202.199 with HTTP; Thu, 31 Oct 2013 00:56:44 -0700 (PDT) In-Reply-To: <52680567.2080204@gmail.com> References: <52680567.2080204@gmail.com> Date: Thu, 31 Oct 2013 09:56:44 +0200 X-Google-Sender-Auth: vLjdHPnBKUFQGk-g-vhPMipcEF4 Message-ID: From: Pasi Eronen To: IPsecme WG Content-Type: multipart/alternative; boundary=001a1133958878fdcc04ea04caa4 Subject: Re: [IPsec] Working Group Last Call: draft-kivinen-ipsecme-ikev2-rfc5996bis-01 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, 31 Oct 2013 07:56:47 -0000 --001a1133958878fdcc04ea04caa4 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed the diffs from RFC 5996 to rfc5996bis-01, and I'm fine with them. Best regards, Pasi On Wed, Oct 23, 2013 at 8:20 PM, Yaron Sheffer wrote: > Hi, this is to start a 3-week working group last call on the IKEv2-bis (or > -bis-bis) document, ending Nov. 13. > > The draft is at: http://tools.ietf.org/html/**draft-kivinen-ipsecme-ikev2- > **rfc5996bis. > > > The main motivation behind the draft is to progress IKEv2 from Proposed > Standard to Internet Standard based on its broad industry adoption, and > with a minimal number of changes. See RFC 6410 for the process details. We > are planning to progress a couple other of our foundational RFCs in the > near future. > > Please read this draft and send any comments to the WG mailing list, even > if the comments are "I see no problems". Comments such as "I do not > understand this part" or "this part could be explained better in this way" > are particularly useful at this point. Please pay special attention to > differences from RFC 5996, as listed in Sec. 1.8. > > Thanks, > Paul and Yaron > > ______________________________**_________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/**listinfo/ipsec > --001a1133958878fdcc04ea04caa4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed the diffs from RFC 5996 to rfc5996bis-01, = and I'm fine with them.

Best regards,
Pasi=


O= n Wed, Oct 23, 2013 at 8:20 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Hi, this is to start a 3-week working group = last call on the IKEv2-bis (or -bis-bis) document, ending Nov. 13.

The draft is at: http://tools.ietf.org/html/dra= ft-kivinen-ipsecme-ikev2-rfc5996bis. <http://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-rfc59= 96bis-01> The main motivation behind the draft is to progress IKEv2 = from Proposed Standard to Internet Standard based on its broad industry ado= ption, and with a minimal number of changes. See RFC 6410 for the process d= etails. We are planning to progress a couple other of our foundational RFCs= in the near future.

Please read this draft and send any comments to the WG mailing list, even i= f the comments are "I see no problems". Comments such as "I = do not understand this part" or "this part could be explained bet= ter in this way" are particularly useful at this point. Please pay spe= cial attention to differences from RFC 5996, as listed in Sec. 1.8.

Thanks,
=A0 =A0 Paul and Yaron

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

--001a1133958878fdcc04ea04caa4-- From yaronf.ietf@gmail.com Thu Oct 31 01:42:10 2013 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 1E5D711E81C1 for ; Thu, 31 Oct 2013 01:42:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYm+S+4B25pp for ; Thu, 31 Oct 2013 01:42:09 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCA411E80F1 for ; Thu, 31 Oct 2013 01:42:08 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so2368163wgg.4 for ; Thu, 31 Oct 2013 01:42:07 -0700 (PDT) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=vCcsfGjjG1j6sZ4kiIYouEs4+wgGGt1id8d9CNuefWI=; b=z4f6fxPfISDIOFwfYV5o4t4anhK87+hHJvUi7C+e5zyXxdJ4U6G9sHbE8DvU9SXAwf Az7rkVf/9eH/B88PSdnE1I5yigv+HfooAygyP2q89yp7ByMY6KQhfP7ZND9hutTXQ2UD iCNh3xJD5lM6Euc80YwaAti4fBR3WablY4DiBBJYufxrTCRNY1JjeKnEcrA4Hbxw9AAF bHKskJVWr8y8PGDf3v5hICugQ9XDD9Nd1EpBlBmQNfjFEcyMVAwJPejZ9I0gG8o+8CmZ dLpE3CgKZY68eIvoNnS6v9kZ+WJxc7QHCHXuGQOkAhkaLcq9Ffa29NYq2mbxw9OS+845 9UVw== X-Received: by 10.194.109.68 with SMTP id hq4mr1681128wjb.12.1383208927874; Thu, 31 Oct 2013 01:42:07 -0700 (PDT) Received: from [10.0.0.1] (93-172-31-195.bb.netvision.net.il. [93.172.31.195]) by mx.google.com with ESMTPSA id e1sm24034754wij.6.2013.10.31.01.42.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 01:42:06 -0700 (PDT) Message-ID: <527217DD.6040305@gmail.com> Date: Thu, 31 Oct 2013 10:42:05 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Tero Kivinen , IPsecme WG References: <52680567.2080204@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Working Group Last Call: draft-kivinen-ipsecme-ikev2-rfc5996bis-01 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, 31 Oct 2013 08:42:10 -0000 Hi Tero, I think RFC 6989 (additional tests when reusing DH values) should be a normative reference, and the text at the bottom of 2.12 should be strengthened to something like: In such cases, additional tests defined in [RFC6989] MUST be performed by the IKE peers. See this document, as well as [REUSE] for a security analysis of this practice. Rationale: even if EC groups (and the "DSA groups") are not defined in RFC 5996, they are a mainstream use case and the RFC 6989 tests are security critical for them. Also, process-wise, RFC 6989 is a Standards Track document so the normative reference is legit. Small typo: in Sec. 3.3.2, "do not need" -> "does not need", and "needs to have" -> "need to have". Thanks, Yaron From kivinen@iki.fi Thu Oct 31 05:31:52 2013 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 BD39A21F9E9C for ; Thu, 31 Oct 2013 05:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ud3LBwZLbnbp for ; Thu, 31 Oct 2013 05:31:51 -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 117EE21F9F85 for ; Thu, 31 Oct 2013 05:31:46 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id r9VCVi7K002396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 Oct 2013 14:31:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r9VCViQd003264; Thu, 31 Oct 2013 14:31: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: <21106.19887.722069.151541@fireball.kivinen.iki.fi> Date: Thu, 31 Oct 2013 14:31:43 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <5268055E.4000804@gmail.com> <876DF97CB1AF4CA7B96634DDE3D51B1B@buildpc> <21097.16245.405563.467088@fireball.kivinen.iki.fi> <21102.25426.68704.450938@fireball.kivinen.iki.fi> <8399B5EEED824D05B1ED9B1FF42A4810@buildpc> <21103.49725.643646.153092@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 9 min Cc: IPsecme WG Subject: Re: [IPsec] Working GroupLastCall:draft-kivinen-ipsecme-signature-auth-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: Thu, 31 Oct 2013 12:31:52 -0000 Valery Smyslov writes: > > Yes, it only works if the initiator picked wrong key. On the other > > hand as I pointed out there are already 3 ways for the responder to > > pick right key (optional IDr in initiators IKE_AUTH request, CERTREQ, > > and AUTH payload sent by the initiator). > > And none of them looks good. We do have 3 ways proposed to the implementors how they can pick key if they want to implement them. Some of those will require configuration changes, some might require external changes, some requires using certain authentication methods. For example IDr, IDr does NOT HAVE to come from certificate it can also have mapping from IDr -> certificate subject key. The RFC4301 says ID is used to find the PAD entry. The PAD entry is then used to find the X.509 certificate and private key: ---------------------------------------------------------------------- 4.4.3.2. IKE Peer Authentication Data ... This document does not require that the IKE ID asserted by a peer be syntactically related to a specific field in an end entity certificate that is employed to authenticate the identity of that peer. However, it often will be appropriate to impose such a requirement, e.g., when a single entry represents a set of peers each of whom may have a distinct SPD entry. ... ---------------------------------------------------------------------- > > Or we just say it is local implementation issue, as I do not really > > belive this will happen in real world that often. Or we just say that > > implementations having multiple types of public keys SHOULD use > > different IDr for each of the keys if there is any possibility that > > initiators do not support all of the public key types. > > Of course we can always leave it to implemetations by the cost > of lacking interoperability in such situations. This is implementation issue anyways. The implementations do have information (IDr, CERTREQ, AUTH payload algoritm other end sent, PAD entry, IP address etc) and then the implementation will pick the private key to be used and the associated certificate. I do not want to make this even more complex by adding yet another way to send the same information. I assume you problem is that implementations you are thinking of, are too limited in the way they can express the IDr -> PAD -> private key -> certificate mapping, and thats why you think that solution is not suitable. That does not have to be that way, as the RFC4301 already allows all kind of things there, and there is nothing for allowing implementations to implement that kind of code. The fact that current implementations do not do that, is most likely because implementors have not felt it would be important enough feature for them to implement. This document will require changes in the implementation anyways, so those implementors who feel this situation is common enough to require special coding can implement the IDr processing in their code... -- kivinen@iki.fi