From iesg-secretary@ietf.org Wed May 1 09:58: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 5840421F9A5D; Wed, 1 May 2013 09:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.071, 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 HlUG74ugHjPe; Wed, 1 May 2013 09:58:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3E421F9A4F; Wed, 1 May 2013 09:58:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130501165853.30517.27436.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2013 09:58:53 -0700 Cc: ipsec@ietf.org Subject: [IPsec] IPsecME Working Group Virtual Interim Meeting, May 16, 2013 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, 01 May 2013 16:58:54 -0000 The IPsecME Working Group will hold a virtual interim meeting on Thursday, May 16, 2013 via a phone bridge. The meeting will focus on whether solutions are needed for fragmentation of IKEv2 messages, and potential options in this space. For more background, see http://www.ietf.org/mail-archive/web/ipsec/current/msg08371.html. The time for the meeting is: 9:00am PDT 16:00 UTC 12:00 noon EDT 19:00 Israel Agenda and dial-in information will be posted on the mailing list: http://www.ietf.org/mail-archive/web/ipsec/current/maillist.html From yumao9@gmail.com Thu May 2 08:02: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 77B1521F8E87 for ; Thu, 2 May 2013 08:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYylvt0iBTGx for ; Thu, 2 May 2013 08:02:50 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0090721F8E7E for ; Thu, 2 May 2013 08:02:49 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id t10so342135eei.31 for ; Thu, 02 May 2013 08:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=d3qKWmH6a2IVuJ8A1J8FtM/d6DbAN72D3F4bpPD2qII=; b=dQBqyPwf7N2RKqlHvQfmi63GrW1G7GrHaCZWIVyHVbek2d8oqyXQpQMFAeXQjQQj89 D/ES8GdCaqpSic2skdQuiKvGajHO/hx4P/ZsBJO8r+YXXqsfCWZRG8hFCKtOIZNPYgaO gzEczQFm2aepDwnMVtCemzSd9GPDLGNZWTTlrEbZeStX4ujcELajTD/qlci9wlpt6SWU Yq2XqM82zeRlhbZlQfSDFaC+xO9fDLgFSPqcE3+pADCF02iHVLSOgRFJCj2b/eK6/Mwe 0eBWmy5M6TCRd9xA/ojKu3aoEXLm7ORzU+CHZTKWM6a77tm2TZXw7mMfR9PKD/QQvTC3 Wdhg== MIME-Version: 1.0 X-Received: by 10.14.115.131 with SMTP id e3mr20297312eeh.43.1367506968989; Thu, 02 May 2013 08:02:48 -0700 (PDT) Received: by 10.223.182.8 with HTTP; Thu, 2 May 2013 08:02:48 -0700 (PDT) In-Reply-To: <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org> References: <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org> Date: Thu, 2 May 2013 23:02:48 +0800 Message-ID: From: Toby Mao To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c29c5e1d759004dbbd878d Cc: IPsecme WG , "maoyu@h3c.com" Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.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, 02 May 2013 15:02:55 -0000 --001a11c29c5e1d759004dbbd878d Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman wrote: > These requirements might be useful to add in the next draft, but they need > to be refined. > > On Apr 26, 2013, at 8:10 PM, Toby Mao wrote: > > > The ADVPN solution SHOULD be able to implement Quality of Service (QoS) > to regulate the traffic in the ADVPN topology. > > Why is this statement needed? Do you see situations where an ADVPN > solution would be *prevented* from implementing some sort of QoS because it > was an ADVPN? > [Toby]: There is no situation that ADVPN solution could be prevented from implementing Qos. Actually, Qos is crucial on ADVPN, such as sharing network bandwidth, meeting the application latency requirement. Especially in the Hub, for each spoke, the Qos policy should be implemented individually , because different spoke has different link speed and data processing capability. Thus, in the ADVPN solution, the small spoke can not be overrun by hub by sending too much traffic, also the spoke which has large bandwidth cannot hog the hub's resources and starve other spokes. In addition, a unique Qos policy for each spoke in the hub could be cumbersome for administrator, some improvement could be implemented, such as the spokes with the same bandwidth can belong to the same group, the Qos policy can be implemented on a basis of group. > > > ADVPN peer SHOULD NOT send excessive traffic to the other members of > ADVPN. > > How would you define "excessive"? Where would that measurement be done? [Toby] The traffic to the ADVPN peer exceeding the actual peer bandwidth can be defined as "excessive". To solve this problem, the other ADVPN peer should apply Qos policy for this ADVPN peer. > The traffic for each ADVPN peer CAN be measured individually for shaping > and policing. > > Why is this statement needed? Do you see situations where an ADVPN > solution would be *prevented* from measuring individually? [Toby] The reason is explained in the first answer. > > --Paul Hoffman --001a11c29c5e1d759004dbbd878d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman <paul.hoffman@vpnc.org<= /a>> wrote:
These requirements might be useful to add in the next draf= t, but they need to be refined.

On Apr 26, 2013, at 8:10 PM, Toby Mao <yumao9@gmail.com> wrote:

> The ADVPN solution SHOULD be able to implement Quality of Service (QoS= ) to regulate the traffic in the ADVPN topology.

Why is this statement needed? Do you see situations where an ADVPN so= lution would be *prevented* from implementing some sort of QoS because it w= as an ADVPN?

=A0[Toby]:=A0<= span style=3D"font-family:arial,sans-serif;font-size:13px">There is no situ= ation that ADVPN solution could be prevented from implementing Qos. Actuall= y, Qos is crucial on ADVPN, such as sharing network bandwidth, meeting the = application latency requirement. Especially in the Hub, for each spoke, the= Qos policy should be implemented individually , because different spoke ha= s different link speed and data processing capability. Thus, in the ADVPN s= olution, the small spoke can not be overrun by hub by sending too much traf= fic, also the spoke which has large bandwidth cannot hog the hub's reso= urces and starve other spokes. In addition, a unique Qos policy for each sp= oke in the hub could be cumbersome for administrator, some improvement coul= d be implemented, such as the spokes with the same bandwidth can belong to = the same group, the Qos policy can be implemented on a basis of group.

> ADVPN peer SHOULD NOT send excessive traffic to the other members of A= DVPN.

How would you define "excessive"? Where would that measurem= ent be done?
=A0
[Toby] =A0The traffic to the ADVPN peer exceed= ing the actual peer bandwidth can be defined as "excessive". To s= olve this problem, the other ADVPN peer should apply Qos policy for this AD= VPN peer.=A0

> The traffic for each ADVPN peer CAN be measured individually for shapi= ng and policing.

Why is this statement needed? Do you see situations where an ADVPN so= lution would be *prevented* from measuring individually?
= =A0
[= Toby] =A0The reason is explained in the first answer.=A0

--Paul Hoffman

--001a11c29c5e1d759004dbbd878d-- From yumao9@gmail.com Thu May 2 08:08: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 7F10321F8EC1 for ; Thu, 2 May 2013 08:08: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=[BAYES_00=-2.599, 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 XgyNewuK2mE5 for ; Thu, 2 May 2013 08:08:15 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDBB21F8BE4 for ; Thu, 2 May 2013 08:08:15 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id z16so335094ead.41 for ; Thu, 02 May 2013 08:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QRNxJXEbVjs1pApAEw/3TONEFmccSa7uXbgOkIa61co=; b=k3cP78j0IB/obTDRIfYMFq0yb5bSmruL+IYVF/7EuAY87L4BzBq2hDsLLQrVxUEoio pRdqu63J7Hpod6Y7zqDsz3bUMd5L2Rctr2W+qh2rP7qE79SbexImFEKPL8BI9fisitA3 AioqcFWWt6lojDdlD7vPBC+mgvGGSpJ2ZHADUPJiLb1fQbKtKXg9jVEPdB9mKUn3hB2r cav1MtagFFLU/qji5/mkqPr0z2VkSNvFbrb2NCklwyf7EIppi3M2V8gQmX7xidHlGHqA DRGizjIWooqfsnBZXJOPuZ1mIuZXLViO6OpeahDCw1ysEK0DRF3qeNRlwlRDxBARh1+Y NVeg== MIME-Version: 1.0 X-Received: by 10.14.213.67 with SMTP id z43mr20579922eeo.16.1367507294419; Thu, 02 May 2013 08:08:14 -0700 (PDT) Received: by 10.223.182.8 with HTTP; Thu, 2 May 2013 08:08:14 -0700 (PDT) In-Reply-To: References: <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org> Date: Thu, 2 May 2013 23:08:14 +0800 Message-ID: From: Toby Mao To: Vishwas Manral Content-Type: multipart/alternative; boundary=047d7b603bac831fa504dbbd9abc Cc: IPsecme WG , "maoyu@h3c.com" , Paul Hoffman Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.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, 02 May 2013 15:08:16 -0000 --047d7b603bac831fa504dbbd9abc Content-Type: text/plain; charset=ISO-8859-1 Hi Vishwas: I agree with you. The Qos implementation in ADVPN is not different with traditional IPsec VPN at all, and this requirement is to specify Qos policy for each ADVPN peer in the hub. Best regards, Toby On Mon, Apr 29, 2013 at 12:00 PM, Vishwas Manral wrote: > Hi Toby, > > I absolutely understand the rational of where you are coming from. I agree > with questions raised by Paul - we need to be characterize the requirement > a bit further. > > I know QoS is important especially if there is an overload of traffic with > multiple different use cases. However do we see it any different from any > other VPN we currently run? I agree policing, shaping, marking etc are > mechanisms to implement QoS and are important. May be the requirement would > be to specify the capability to do fine grained QoS on a per peer basis on > the Hub. Sounds reasonable? > > Thanks, > Vishwas > > > On Sat, Apr 27, 2013 at 8:27 PM, Paul Hoffman wrote: > >> These requirements might be useful to add in the next draft, but they >> need to be refined. >> >> On Apr 26, 2013, at 8:10 PM, Toby Mao wrote: >> >> > The ADVPN solution SHOULD be able to implement Quality of Service (QoS) >> to regulate the traffic in the ADVPN topology. >> >> Why is this statement needed? Do you see situations where an ADVPN >> solution would be *prevented* from implementing some sort of QoS because it >> was an ADVPN? >> >> > ADVPN peer SHOULD NOT send excessive traffic to the other members of >> ADVPN. >> >> How would you define "excessive"? Where would that measurement be done? >> >> > The traffic for each ADVPN peer CAN be measured individually for >> shaping and policing. >> >> Why is this statement needed? Do you see situations where an ADVPN >> solution would be *prevented* from measuring individually? >> >> --Paul Hoffman >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > --047d7b603bac831fa504dbbd9abc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Vishwas:

I ag= ree with you. =A0The Qos implementation in ADVPN is not different with trad= itional IPsec VPN at all, and this requirement is to specify Qos policy for= each ADVPN peer in the hub.

Best regards,

Toby


On Mon, Apr 29, 2013 at 12:00 P= M, Vishwas Manral <vishwas.ietf@gmail.com> wrote:
Hi Toby,
=A0=
I absolutely understand the rational of where you are coming fro= m. I agree with questions raised by Paul - we need to be characterize the r= equirement a bit further.=A0
=A0
I know=A0QoS is important especially if there is an over= load of traffic with multiple different use cases. However do we see it any= different from any other VPN we currently run? I agree policing, shaping, = marking etc=A0are mechanisms to implement QoS and are important. May be the= requirement would be to specify the capability to do fine grained QoS on a= per peer basis on the Hub. Sounds reasonable?
=A0
Thanks,
Vishwas


On Sat, A= pr 27, 2013 at 8:27 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
These req= uirements might be useful to add in the next draft, but they need to be ref= ined.

On Apr 26, 2013, at 8:10 PM, Toby Mao <yumao9@gmail.com> wrote:

> The ADVPN solution SHOULD be able to implement Quality of Service (QoS= ) to regulate the traffic in the ADVPN topology.

Why is this statement needed? Do you see situations where an ADVPN so= lution would be *prevented* from implementing some sort of QoS because it w= as an ADVPN?

> ADVPN peer SHOULD NOT send excessive traffic to the other members of A= DVPN.

How would you define "excessive"? Where would that measurem= ent be done?

> The traffic for each ADVPN peer CAN be measured individually for shapi= ng and policing.

Why is this statement needed? Do you see situations where an ADVPN so= lution would be *prevented* from measuring individually?

--Paul Hoffman
_____________________= __________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec


--047d7b603bac831fa504dbbd9abc-- From ynir@checkpoint.com Thu May 2 13:12: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 977BC21F8E6B for ; Thu, 2 May 2013 13:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE-2qkp89ehk for ; Thu, 2 May 2013 13:12:00 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 379E821F8E87 for ; Thu, 2 May 2013 13:11:59 -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 r42KBhQU032160; Thu, 2 May 2013 23:11:43 +0300 X-CheckPoint: {5182C731-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 2 May 2013 23:11:42 +0300 From: Yoav Nir To: Toby Mao Thread-Topic: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt Thread-Index: AQHOQvTSzCtJfIFl80iVCJ3Hf4wLpZjp9voAgAfdCQCAAFZMAA== Date: Thu, 2 May 2013 20:11:42 +0000 Message-ID: <33E02A33-0EA1-4D48-BCA4-F436C6023423@checkpoint.com> References: <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org> 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.112] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 114b53c25ca129f0f5be5da2b91437cb0f8f49137e Content-Type: multipart/alternative; boundary="_000_33E02A330EA14D48BCA4F436C6023423checkpointcom_" MIME-Version: 1.0 Cc: IPsecme WG , "maoyu@h3c.com" , Paul Hoffman Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.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, 02 May 2013 20:12:05 -0000 --_000_33E02A330EA14D48BCA4F436C6023423checkpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Toby. Let's see if I understand the issue. I'll describe this with an example. Pl= ease let me know if I got it. Suppose we have satellite gateways A, B, C, D, and E. A through D each have= a bandwidth of 10 Mb/s, while E has 20 Mb/s. The center gateway, Z, has plenty of bandwidth and the appropriate QoS poli= cy. So if A, B, and C are simultaneously sending traffic to E through Z, Z = will do the QoS magic (maybe by dropping packets or playing with TCP ACKs) = to make sure the QoS goals are met. Now add ADVPN to the mix. A and E discover each other, and are able to bypa= ss Z. Initially A had no IPsec policy about E. There's no reason to think i= t had a QoS policy about E, and the same is true in the other direction. Un= less the QoS policy from Z somehow gets transmitted to the satellites, they= may reach congestion and have the QoS targets miss. So whereas before ADVPN the center gateway could be counted on to handle th= e QoS (because everything goes through it), as soon as you add ADVPN, that = policy has to be enforced on the spokes, or not at all. I'm not sure whether we can or should solve this issue as part of AD-VPN, b= ut I want to make sure that we understand the issue. Yoav On May 2, 2013, at 6:02 PM, Toby Mao > wrote: On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman > wrote: These requirements might be useful to add in the next draft, but they need = to be refined. On Apr 26, 2013, at 8:10 PM, Toby Mao > wrote: > The ADVPN solution SHOULD be able to implement Quality of Service (QoS) t= o regulate the traffic in the ADVPN topology. Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from implementing some sort of QoS because it was an = ADVPN? [Toby]: There is no situation that ADVPN solution could be prevented from = implementing Qos. Actually, Qos is crucial on ADVPN, such as sharing networ= k bandwidth, meeting the application latency requirement. Especially in the= Hub, for each spoke, the Qos policy should be implemented individually , b= ecause different spoke has different link speed and data processing capabil= ity. Thus, in the ADVPN solution, the small spoke can not be overrun by hub= by sending too much traffic, also the spoke which has large bandwidth cann= ot hog the hub's resources and starve other spokes. In addition, a unique Q= os policy for each spoke in the hub could be cumbersome for administrator, = some improvement could be implemented, such as the spokes with the same ban= dwidth can belong to the same group, the Qos policy can be implemented on a= basis of group. > ADVPN peer SHOULD NOT send excessive traffic to the other members of ADVP= N. How would you define "excessive"? Where would that measurement be done? [Toby] The traffic to the ADVPN peer exceeding the actual peer bandwidth c= an be defined as "excessive". To solve this problem, the other ADVPN peer s= hould apply Qos policy for this ADVPN peer. > The traffic for each ADVPN peer CAN be measured individually for shaping = and policing. Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from measuring individually? [Toby] The reason is explained in the first answer. --Paul Hoffman Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_33E02A330EA14D48BCA4F436C6023423checkpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4FE417CA9533F7448C23FA59D3198F4D@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Hi Toby.

Let's see if I understand the issue. I'll describe this with an exampl= e. Please let me know if I got it.

Suppose we have satellite gateways A, B, C, D, and E. A through D each= have a bandwidth of 10 Mb/s, while E has 20 Mb/s.

The center gateway, Z, has plenty of bandwidth and the appropriate QoS= policy. So if A, B, and C are simultaneously sending traffic to E through = Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP A= CKs) to make sure the QoS goals are met.

Now add ADVPN to the mix. A and E discover each other, and are able to= bypass Z. Initially A had no IPsec policy about E. There's no reason to th= ink it had a QoS policy about E, and the same is true in the other directio= n. Unless the QoS policy from Z somehow gets transmitted to the satellites, they may reach congestion and = have the QoS targets miss. 

So whereas before ADVPN the center gateway could be counted on to hand= le the QoS (because everything goes through it), as soon as you add ADVPN, = that policy has to be enforced on the spokes, or not at all.

I'm not sure whether we can or should solve this issue as part of AD-V= PN, but I want to make sure that we understand the issue.

Yoav
 
On May 2, 2013, at 6:02 PM, Toby Mao <yumao9@gmail.com> wrote:


On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman <= span dir=3D"ltr"> <paul.hoffman= @vpnc.org> wrote:
These requirements might be useful to add in the next draft, but they need = to be refined.

On Apr 26, 2013, at 8:10 PM, Toby Mao <yumao9@gmail.com> wrote:

> The ADVPN solution SHOULD be able to implement Quality of Service (QoS= ) to regulate the traffic in the ADVPN topology.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from implementing some sort of QoS because it was an = ADVPN?

 [Toby]: There is no situation that ADVPN solution could be prev= ented from implementing Qos. Actually, Qos is crucial on ADVPN, such as sha= ring network bandwidth, meeting the application latency requirement. Especially in the Hub, for each spoke, the Qos policy= should be implemented individually , because different spoke has different= link speed and data processing capability. Thus, in the ADVPN solution, th= e small spoke can not be overrun by hub by sending too much traffic, also the spoke which has large bandwid= th cannot hog the hub's resources and starve other spokes. In addition, a u= nique Qos policy for each spoke in the hub could be cumbersome for administ= rator, some improvement could be implemented, such as the spokes with the same bandwidth can belong to the = same group, the Qos policy can be implemented on a basis of group.

> ADVPN peer SHOULD NOT send excessive traffic to the other members of A= DVPN.

How would you define "excessive"? Where would that measurement be= done?
 
[Toby] &nb= sp;The traffic to the ADVPN peer exceeding the actual peer bandwidth can be= defined as "excessive". To solve this problem, the other ADVPN p= eer should apply Qos policy for this ADVPN peer. 

> The traffic for each ADVPN peer CAN be measured indi= vidually for shaping and policing.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from measuring individually?
 
[Toby] &nb= sp;The reason is explained in the first answer. 

--Paul Hoffman



Email secured by Check Point

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

--_000_33E02A330EA14D48BCA4F436C6023423checkpointcom_-- From internet-drafts@ietf.org Sat May 4 10:34: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 BBA9321F9686; Sat, 4 May 2013 10:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.080, 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 Qmbi6JNgMJsE; Sat, 4 May 2013 10:34:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EF221F9675; Sat, 4 May 2013 10:34:16 -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.44.p5 Message-ID: <20130504173416.11238.8554.idtracker@ietfa.amsl.com> Date: Sat, 04 May 2013 10:34:16 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-dh-checks-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: Sat, 04 May 2013 17:34:20 -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 : Additional Diffie-Hellman Tests for IKEv2 Author(s) : Yaron Sheffer Scott Fluhrer Filename : draft-ietf-ipsecme-dh-checks-04.txt Pages : 11 Date : 2013-05-04 Abstract: This document adds a small number of mandatory tests required for the secure operation of IKEv2 with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called DSA groups. This document updates the IKEv2 protocol, RFC 5996. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-dh-checks-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yaronf.ietf@gmail.com Sat May 4 10:37: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 527FC21F8F58 for ; Sat, 4 May 2013 10:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 VAfPMxOmXkcZ for ; Sat, 4 May 2013 10:37:52 -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 87DD021F8D94 for ; Sat, 4 May 2013 10:37:52 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n12so2411434wgh.1 for ; Sat, 04 May 2013 10:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=AIxGlU/Fhwg++AmY3gEKYledrax2NAkYaYExctIQJNo=; b=DltwMP0oiQi44ZxUbg+1h7/LJbBDbp0XyxJIJ3o05oCBp1TPpPtSVOZB/YnTaxN2aw tPW27cDmFI3LVsUeoL7d2rr7WRSLFOMWY1fSShTeOWNIJCoDAQ8ZGC9mDOL+9j3qy+v2 yopYZIYFn9F/9yeVSPbRudMHt89daRrILLyG6z4OKTTSNP3b3m6kfEqIRt1wDQEdXYVY BdBvdQLBU3bBPRrjHIwyCw30JYJ48O7gQ3Wx/Y6+zT+N06Qg9+0ATndPlkB473hsy/vk 2dBss7mJa9EvTs5Nvwc+50Q91sFPNzI1Z5JUD48h/1OE8XzxDJRMtd/kPikhXNdImB9I lBBA== X-Received: by 10.194.83.33 with SMTP id n1mr19153998wjy.7.1367689071497; Sat, 04 May 2013 10:37:51 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-182-97-31.red.bezeqint.net. [79.182.97.31]) by mx.google.com with ESMTPSA id dj7sm4027636wib.6.2013.05.04.10.37.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 May 2013 10:37:50 -0700 (PDT) Message-ID: <5185476C.6070501@gmail.com> Date: Sat, 04 May 2013 20:37:48 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: IPsecme WG References: <20130504173419.11238.16533.idtracker@ietfa.amsl.com> In-Reply-To: <20130504173419.11238.16533.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130504173419.11238.16533.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Fwd: New Version Notification for draft-ietf-ipsecme-dh-checks-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: Sat, 04 May 2013 17:37:53 -0000 Hi, we have just submitted a new version of the draft, resolving Sean's AD review comments, as well as Johannes' comment about the missing point at infinity. Thanks, Yaron -------- Original Message -------- Subject: New Version Notification for draft-ietf-ipsecme-dh-checks-04.txt Date: Sat, 04 May 2013 10:34:19 -0700 From: internet-drafts@ietf.org To: Scott Fluhrer , Yaron Sheffer A new version of I-D, draft-ietf-ipsecme-dh-checks-04.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Filename: draft-ietf-ipsecme-dh-checks Revision: 04 Title: Additional Diffie-Hellman Tests for IKEv2 Creation date: 2013-05-04 Group: ipsecme Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-dh-checks-04.txt Status: http://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks Htmlized: http://tools.ietf.org/html/draft-ietf-ipsecme-dh-checks-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-dh-checks-04 Abstract: This document adds a small number of mandatory tests required for the secure operation of IKEv2 with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called DSA groups. This document updates the IKEv2 protocol, RFC 5996. The IETF Secretariat From yumao9@gmail.com Sun May 5 08:49: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 C827121F9403 for ; Sun, 5 May 2013 08:49: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=[BAYES_00=-2.599, 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 G3igcPhdw4y2 for ; Sun, 5 May 2013 08:49:15 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C547821F93FE for ; Sun, 5 May 2013 08:49:15 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 10so3253881ied.5 for ; Sun, 05 May 2013 08:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ss38skj13fzD8YPiEK4j/nWfoJwrBtNR2Ohe+Zo5N8A=; b=et79X8XerHtG34fS+7/DudIuS6LY/Rsp4OooQ9h01/a3X5UUNuOUrT7YcKxRv6L2Y8 /caVvh6LZ21gROjNSTE3uSFW6sWEcuL+oLxS8JPb0EuuJkuQhpQ5E4jURXI69C7QJdtH IyYRZbkFop9ae+qqjVFLO7tgNvM6lYX9uw2OsuOxr9f8iPSUwKFySfgzSj1OOJx9aZVB R9L1QdaiHBASUXZu/G+xXViGBSjoTXM0wbVemAUABombfg1C3X3XdvSBr4m9eKeGeOy1 RVrOnusHdsu9SIrIttmKe7cC5AjrwA0UHaG1A5LPJ1eQfL3Tl1gHoKmAxMdwKyiwaeTt EWRg== MIME-Version: 1.0 X-Received: by 10.50.88.103 with SMTP id bf7mr1653389igb.9.1367768955367; Sun, 05 May 2013 08:49:15 -0700 (PDT) Received: by 10.43.98.201 with HTTP; Sun, 5 May 2013 08:49:15 -0700 (PDT) In-Reply-To: <33E02A33-0EA1-4D48-BCA4-F436C6023423@checkpoint.com> References: <0C678C21-ECDD-4249-9DBB-B120DEE8613F@vpnc.org> <33E02A33-0EA1-4D48-BCA4-F436C6023423@checkpoint.com> Date: Sun, 5 May 2013 23:49:15 +0800 Message-ID: From: Toby Mao To: Yoav Nir Content-Type: multipart/alternative; boundary=089e013cb9e0b838d304dbfa8672 Cc: IPsecme WG , "maoyu@h3c.com" , Paul Hoffman Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 May 2013 15:49:16 -0000 --089e013cb9e0b838d304dbfa8672 Content-Type: text/plain; charset=ISO-8859-1 Hi Yoav. The QoS implementations in ADVPN are : 1. In the star topology, the QoS policy is implemented individually for each spoke in the hub, all the traffic through the Hub can be regulated by QoS policy in the hub. 2. In the full mesh topology, when the two spokes establish the direct connection, each spoke should also have the QoS policy for each other. The QoS policy can be obtained from the Hub, or other control device , which has the individual QoS policy for each spoke. I think your understanding is the same as the QoS implementation in the full mesh topology. Toby On Fri, May 3, 2013 at 4:11 AM, Yoav Nir wrote: > Hi Toby. > > Let's see if I understand the issue. I'll describe this with an example. > Please let me know if I got it. > > Suppose we have satellite gateways A, B, C, D, and E. A through D each > have a bandwidth of 10 Mb/s, while E has 20 Mb/s. > > The center gateway, Z, has plenty of bandwidth and the appropriate QoS > policy. So if A, B, and C are simultaneously sending traffic to E through > Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP > ACKs) to make sure the QoS goals are met. > > Now add ADVPN to the mix. A and E discover each other, and are able to > bypass Z. Initially A had no IPsec policy about E. There's no reason to > think it had a QoS policy about E, and the same is true in the other > direction. Unless the QoS policy from Z somehow gets transmitted to the > satellites, they may reach congestion and have the QoS targets miss. > > So whereas before ADVPN the center gateway could be counted on to handle > the QoS (because everything goes through it), as soon as you add ADVPN, > that policy has to be enforced on the spokes, or not at all. > > I'm not sure whether we can or should solve this issue as part of > AD-VPN, but I want to make sure that we understand the issue. > > Yoav > > On May 2, 2013, at 6:02 PM, Toby Mao wrote: > > > On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman wrote: > >> These requirements might be useful to add in the next draft, but they >> need to be refined. >> >> On Apr 26, 2013, at 8:10 PM, Toby Mao wrote: >> >> > The ADVPN solution SHOULD be able to implement Quality of Service (QoS) >> to regulate the traffic in the ADVPN topology. >> >> Why is this statement needed? Do you see situations where an ADVPN >> solution would be *prevented* from implementing some sort of QoS because it >> was an ADVPN? >> > > [Toby]: There is no situation that ADVPN solution could be prevented > from implementing Qos. Actually, Qos is crucial on ADVPN, such as sharing > network bandwidth, meeting the application latency requirement. Especially > in the Hub, for each spoke, the Qos policy should be implemented > individually , because different spoke has different link speed and data > processing capability. Thus, in the ADVPN solution, the small spoke can not > be overrun by hub by sending too much traffic, also the spoke which has > large bandwidth cannot hog the hub's resources and starve other spokes. In > addition, a unique Qos policy for each spoke in the hub could be cumbersome > for administrator, some improvement could be implemented, such as the > spokes with the same bandwidth can belong to the same group, the Qos policy > can be implemented on a basis of group. > >> >> > ADVPN peer SHOULD NOT send excessive traffic to the other members of >> ADVPN. >> >> How would you define "excessive"? Where would that measurement be done? > > > [Toby] The traffic to the ADVPN peer exceeding the actual peer bandwidth > can be defined as "excessive". To solve this problem, the other ADVPN peer > should apply Qos policy for this ADVPN peer. > > > The traffic for each ADVPN peer CAN be measured individually for >> shaping and policing. >> >> Why is this statement needed? Do you see situations where an ADVPN >> solution would be *prevented* from measuring individually? > > > [Toby] The reason is explained in the first answer. > >> >> --Paul Hoffman > > > > > Email secured by Check Point > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > --089e013cb9e0b838d304dbfa8672 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Yoav.

=A0=A0=A0=A0=A0=A0=A0 =A0= The QoS implementations in ADVPN are :

1= .=A0=A0=A0=A0=A0=A0=A0=A0In the star topology, =A0the QoS policy is implemented indiv= idually for each spoke in the hub, all the traffic through the Hub can be r= egulated by QoS policy in the hub.

2= .=A0=A0=A0=A0=A0=A0=A0In the full mesh topology,=A0 when the two spokes establish the= direct connection, each spoke should also have the QoS policy for each oth= er. The QoS policy can be obtained from the Hub, or other control device , = =A0which has the individual QoS policy for each spoke.

I think your unde= rstanding is the same as the QoS implementation in the full mesh topology.<= /font>

Toby



On Fri, May 3, 2013 at 4:11 AM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi Toby.

Let's see if I understand the issue. I'll describe this with a= n example. Please let me know if I got it.

Suppose we have satellite gateways A, B, C, D, and E. A through D each= have a bandwidth of 10 Mb/s, while E has 20 Mb/s.

The center gateway, Z, has plenty of bandwidth and the appropriate QoS= policy. So if A, B, and C are simultaneously sending traffic to E through = Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP A= CKs) to make sure the QoS goals are met.

Now add ADVPN to the mix. A and E discover each other, and are able to= bypass Z. Initially A had no IPsec policy about E. There's no reason t= o think it had a QoS policy about E, and the same is true in the other dire= ction. Unless the QoS policy from Z somehow gets transmitted to the satellites, they may reach congestion and = have the QoS targets miss.=A0

So whereas before ADVPN the center gateway could be counted on to hand= le the QoS (because everything goes through it), as soon as you add ADVPN, = that policy has to be enforced on the spokes, or not at all.

I'm not sure whether we can or should solve this issue as part of = AD-VPN, but I want to make sure that we understand the issue.

Yoav
=A0

On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman <= span dir=3D"ltr"> <paul.hoffman= @vpnc.org> wrote:
These requirements might be useful to add in the next draft, but they need = to be refined.

On Apr 26, 2013, at 8:10 PM, Toby Mao <yumao9@gmail.com> wrote:

> The ADVPN solution SHOULD be able to implement Quality of Service (QoS= ) to regulate the traffic in the ADVPN topology.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from implementing some sort of QoS because it was an = ADVPN?

=A0[Toby]:=A0There is no situation that ADVPN solution could be prevented from implem= enting Qos. Actually, Qos is crucial on ADVPN, such as sharing network band= width, meeting the application latency requirement. Especially in the Hub, for each spoke, the Qos policy= should be implemented individually , because different spoke has different= link speed and data processing capability. Thus, in the ADVPN solution, th= e small spoke can not be overrun by hub by sending too much traffic, also the spoke which has large bandwid= th cannot hog the hub's resources and starve other spokes. In addition,= a unique Qos policy for each spoke in the hub could be cumbersome for admi= nistrator, some improvement could be implemented, such as the spokes with the same bandwidth can belong to the = same group, the Qos policy can be implemented on a basis of group.

> ADVPN peer SHOULD NOT send excessive traffic to the other members of A= DVPN.

How would you define "excessive"? Where would that measurement be= done?
=A0
[Toby] =A0= The traffic to the ADVPN peer exceeding the actual peer bandwidth can be de= fined as "excessive". To solve this problem, the other ADVPN peer= should apply Qos policy for this ADVPN peer.=A0

> The traffic for each ADVPN peer CAN be measured individually for = shaping and policing.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from measuring individually?
=A0
[Toby] =A0= The reason is explained in the first answer.=A0

--Paul Hoffman



Email secured by Check Point

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


--089e013cb9e0b838d304dbfa8672-- From iesg-secretary@ietf.org Mon May 6 07:02: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 B2D3021F9184; Mon, 6 May 2013 07:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.378 X-Spam-Level: X-Spam-Status: No, score=-102.378 tagged_above=-999 required=5 tests=[AWL=0.222, 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 sGgH8vLQG1Xx; Mon, 6 May 2013 07:02:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 557B721F8E9A; Mon, 6 May 2013 07:02:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p5 Sender: Message-ID: <20130506140250.23671.9828.idtracker@ietfa.amsl.com> Date: Mon, 06 May 2013 07:02:50 -0700 Cc: ipsec@ietf.org Subject: [IPsec] Last Call: (Additional Diffie-Hellman Tests for IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 14:02:50 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Additional Diffie-Hellman Tests for IKEv2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-05-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document adds a small number of mandatory tests required for the secure operation of IKEv2 with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called DSA groups. This document updates the IKEv2 protocol, RFC 5996. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-dh-checks/ballot/ No IPR declarations have been submitted directly on this I-D. From praveenys@juniper.net Mon May 6 09:33: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 8BD3D21F9133 for ; Mon, 6 May 2013 09:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 6enB3w8CVn-1 for ; Mon, 6 May 2013 09:33:10 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id ACE8E21F888C for ; Mon, 6 May 2013 09:33:10 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUYfbRpMh8gNXLPEJs4KVYyd8K5wGBy2z@postini.com; Mon, 06 May 2013 09:33:10 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 6 May 2013 09:31:22 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 6 May 2013 09:31:21 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.209) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 6 May 2013 09:34:38 -0700 Received: from mail78-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE023.bigfish.com (10.3.207.145) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 May 2013 16:31:19 +0000 Received: from mail78-am1 (localhost [127.0.0.1]) by mail78-am1-R.bigfish.com (Postfix) with ESMTP id A1BDF40455 for ; Mon, 6 May 2013 16:31:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.232.213; KIP:(null); UIP:(null); (null); H:BLUPRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zf7Iz98dI9371Ic85fhzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL18c673h8275bh8275dhz2dh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1155h) Received: from mail78-am1 (localhost.localdomain [127.0.0.1]) by mail78-am1 (MessageSwitch) id 1367857867595120_31465; Mon, 6 May 2013 16:31:07 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.253]) by mail78-am1.bigfish.com (Postfix) with ESMTP id 7E558120058; Mon, 6 May 2013 16:31:07 +0000 (UTC) Received: from BLUPRD0511HT002.namprd05.prod.outlook.com (157.56.232.213) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 6 May 2013 16:31:05 +0000 Received: from BLUPRD0511MB413.namprd05.prod.outlook.com ([169.254.6.83]) by BLUPRD0511HT002.namprd05.prod.outlook.com ([10.255.135.165]) with mapi id 14.16.0305.001; Mon, 6 May 2013 16:30:51 +0000 From: Praveen Sathyanarayan To: Toby Mao , Yoav Nir Thread-Topic: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt Thread-Index: AQHOSncSTL2I0J2F6E6l8VJM+XdQ2Q== Date: Mon, 6 May 2013 16:30:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.255.135.132] Content-Type: multipart/alternative; boundary="_000_CDAD284818B87Fpraveenysjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CHECKPOINT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%H3C.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%VPNC.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: IPsecme WG , "maoyu@h3c.com" , Paul Hoffman Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 16:33:16 -0000 --_000_CDAD284818B87Fpraveenysjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Toby, When you say QoS policy, could you elaborate what it really means? I mean w= hat kind of information does it need to have or exchanged? -- Praveen From: Toby Mao > Date: Sunday, May 5, 2013 8:49 AM To: Yoav Nir > Cc: IPsecme WG >, "maoyu@h3c.com" >, Paul Hoffman > Subject: Re: [IPsec] One comment to this draft//Fwd: I-D Action: draft-ietf= -ipsecme-ad-vpn-problem-06.txt Hi Yoav. The QoS implementations in ADVPN are : 1. In the star topology, the QoS policy is implemented individually= for each spoke in the hub, all the traffic through the Hub can be regulate= d by QoS policy in the hub. 2. In the full mesh topology, when the two spokes establish the dire= ct connection, each spoke should also have the QoS policy for each other. T= he QoS policy can be obtained from the Hub, or other control device , whic= h has the individual QoS policy for each spoke. I think your understanding is the same as the QoS implementation in the ful= l mesh topology. Toby On Fri, May 3, 2013 at 4:11 AM, Yoav Nir > wrote: Hi Toby. Let's see if I understand the issue. I'll describe this with an example. Pl= ease let me know if I got it. Suppose we have satellite gateways A, B, C, D, and E. A through D each have= a bandwidth of 10 Mb/s, while E has 20 Mb/s. The center gateway, Z, has plenty of bandwidth and the appropriate QoS poli= cy. So if A, B, and C are simultaneously sending traffic to E through Z, Z = will do the QoS magic (maybe by dropping packets or playing with TCP ACKs) = to make sure the QoS goals are met. Now add ADVPN to the mix. A and E discover each other, and are able to bypa= ss Z. Initially A had no IPsec policy about E. There's no reason to think i= t had a QoS policy about E, and the same is true in the other direction. Un= less the QoS policy from Z somehow gets transmitted to the satellites, they= may reach congestion and have the QoS targets miss. So whereas before ADVPN the center gateway could be counted on to handle th= e QoS (because everything goes through it), as soon as you add ADVPN, that = policy has to be enforced on the spokes, or not at all. I'm not sure whether we can or should solve this issue as part of AD-VPN, b= ut I want to make sure that we understand the issue. Yoav On May 2, 2013, at 6:02 PM, Toby Mao > wrote: On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman > wrote: These requirements might be useful to add in the next draft, but they need = to be refined. On Apr 26, 2013, at 8:10 PM, Toby Mao > wrote: > The ADVPN solution SHOULD be able to implement Quality of Service (QoS) t= o regulate the traffic in the ADVPN topology. Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from implementing some sort of QoS because it was an = ADVPN? [Toby]: There is no situation that ADVPN solution could be prevented from = implementing Qos. Actually, Qos is crucial on ADVPN, such as sharing networ= k bandwidth, meeting the application latency requirement. Especially in the= Hub, for each spoke, the Qos policy should be implemented individually , b= ecause different spoke has different link speed and data processing capabil= ity. Thus, in the ADVPN solution, the small spoke can not be overrun by hub= by sending too much traffic, also the spoke which has large bandwidth cann= ot hog the hub's resources and starve other spokes. In addition, a unique Q= os policy for each spoke in the hub could be cumbersome for administrator, = some improvement could be implemented, such as the spokes with the same ban= dwidth can belong to the same group, the Qos policy can be implemented on a= basis of group. > ADVPN peer SHOULD NOT send excessive traffic to the other members of ADVP= N. How would you define "excessive"? Where would that measurement be done? [Toby] The traffic to the ADVPN peer exceeding the actual peer bandwidth c= an be defined as "excessive". To solve this problem, the other ADVPN peer s= hould apply Qos policy for this ADVPN peer. > The traffic for each ADVPN peer CAN be measured individually for shaping = and policing. Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from measuring individually? [Toby] The reason is explained in the first answer. --Paul Hoffman Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_CDAD284818B87Fpraveenysjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <257511755B999941BB6F3651F1B22AE3@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Toby,

When you say QoS policy, could you elaborate what it really means? I m= ean what kind of information does it need to have or exchanged? 

-- Praveen

From: Toby Mao <yumao9@gmail.com>
Date: Sunday, May 5, 2013 8:49 AM To: Yoav Nir <ynir@checkpoint.com>
Cc: IPsecme WG <ipsec@ietf.org>, "maoyu@h3c.com" <maoyu@h3= c.com>, Paul Hoffman <pa= ul.hoffman@vpnc.org>
Subject: Re: [IPsec] One comment to= this draft//Fwd: I-D Action: draft-ietf-ipsecme-ad-vpn-problem-06.txt

Hi Yoav.

      = ;   The QoS implementations in ADVPN are :

1.=         In the star topology,  the QoS p= olicy is implemented individually for each spoke in the hub, all the traffic through the Hub ca= n be regulated by QoS policy in the hub.

2.=        In the full mesh topology,  when the t= wo spokes establish the direct connection, each spoke should also have the QoS policy for each= other. The QoS policy can be obtained from the Hub, or other control devic= e ,  which has the individual QoS policy for each spoke.=

I think your under= standing is the same as the QoS implementation in the full mesh topology.

Toby



On Fri, May 3, 2013 at 4:11 AM, Yoav Nir <ynir@checkpoin= t.com> wrote:
Hi Toby.

Let's see if I understand the issue. I'll describe this with an exampl= e. Please let me know if I got it.

Suppose we have satellite gateways A, B, C, D, and E. A through D each= have a bandwidth of 10 Mb/s, while E has 20 Mb/s.

The center gateway, Z, has plenty of bandwidth and the appropriate QoS= policy. So if A, B, and C are simultaneously sending traffic to E through = Z, Z will do the QoS magic (maybe by dropping packets or playing with TCP A= CKs) to make sure the QoS goals are met.

Now add ADVPN to the mix. A and E discover each other, and are able to= bypass Z. Initially A had no IPsec policy about E. There's no reason to th= ink it had a QoS policy about E, and the same is true in the other directio= n. Unless the QoS policy from Z somehow gets transmitted to the satellites, they may reach congestion and = have the QoS targets miss. 

So whereas before ADVPN the center gateway could be counted on to hand= le the QoS (because everything goes through it), as soon as you add ADVPN, = that policy has to be enforced on the spokes, or not at all.

I'm not sure whether we can or should solve this issue as part of AD-V= PN, but I want to make sure that we understand the issue.

Yoav
 
On May 2, 2013, at 6:02 PM, Toby Mao <yumao9@gmail.com> wrote:


On Sat, Apr 27, 2013 at 10:57 PM, Paul Hoffman <= span dir=3D"ltr"> <paul.hoffman= @vpnc.org> wrote:
These requirements might be useful to add in the next draft, but they need = to be refined.

On Apr 26, 2013, at 8:10 PM, Toby Mao <yumao9@gmail.com> wrote:

> The ADVPN solution SHOULD be able to implement Quality of Service (QoS= ) to regulate the traffic in the ADVPN topology.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from implementing some sort of QoS because it was an = ADVPN?

 [Toby]: There is no situation that ADVPN solution could be prevented= from implementing Qos. Actually, Qos is crucial on ADVPN, such as sharing = network bandwidth, meeting the application latency requirement. Especially in the Hub, for each spoke, the Qos policy should = be implemented individually , because different spoke has different link sp= eed and data processing capability. Thus, in the ADVPN solution, the small = spoke can not be overrun by hub by sending too much traffic, also the spoke which has large bandwidth cann= ot hog the hub's resources and starve other spokes. In addition, a unique Q= os policy for each spoke in the hub could be cumbersome for administrator, = some improvement could be implemented, such as the spokes with the same bandwidth can belong to the same group, t= he Qos policy can be implemented on a basis of group.

> ADVPN peer SHOULD NOT send excessive traffic to the other members of A= DVPN.

How would you define "excessive"? Where would that measurement be= done?
 
[Tob= y]  The traffic to the ADVPN peer exceeding the actual peer bandwidth = can be defined as "excessive". To solve this problem, the other A= DVPN peer should apply Qos policy for this ADVPN peer. 

> The traffic for each ADVPN peer CAN be measured individually for = shaping and policing.

Why is this statement needed? Do you see situations where an ADVPN solution= would be *prevented* from measuring individually?
 
[Tob= y]  The reason is explained in the first answer. 

--Paul Hoffman



Email secured by Check Point

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


 --_000_CDAD284818B87Fpraveenysjunipernet_-- From svanru@gmail.com Tue May 7 05: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 475F221F8E2C for ; Tue, 7 May 2013 05:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 uNZ2LOsvBogk for ; Tue, 7 May 2013 05:41:19 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1445421F8E5F for ; Tue, 7 May 2013 05:41:14 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id y6so661893lbh.3 for ; Tue, 07 May 2013 05:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=xK3YNXjZHqnxP1/li8wgGK+1Igi9UBC9WjHsopUANFY=; b=Ik46CQW2Ynrq9IXg55WlT3YR7+5f/eF4VRUo2NOH0ka++XwE8JE5aZup+hiDvx0Rca FIYxRdsk9m/kAxHfD3YpNyXE3EDWDbei6mlGXD+CbIhXp0wDO9mdHQArDE/gFgLdHT/s QW5cKK2/zjw1lPIJ1RUk8U0AMO8+EwveqAgsGCTHYu5aO9N1f2xtx8ktm1jxluQ+GB4h d7F7mFwcUP2d7FeDTywmCNRjyXIY0faVqtLMCBBp6DrCLIYKiejsmp8rEQYtQBxSfKRO RwNt18z8sGOpk/NJdEtqyvhvcl4bGsOc5I3uznQuqHBZDOCssd5b4rE3BwdGO0rjwPW0 i0CQ== X-Received: by 10.112.169.72 with SMTP id ac8mr913301lbc.115.1367930474044; Tue, 07 May 2013 05:41:14 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id t17sm10211537lbd.11.2013.05.07.05.41.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 05:41:13 -0700 (PDT) Message-ID: <1D5C3857EF7C48AF9A952CB5AEA3CB21@buildpc> From: "Valery Smyslov" To: "IPsecme WG" References: <517FCC2A.8060904@gmail.com> Date: Tue, 7 May 2013 16:40:58 +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] IPsecME virtual interim meeting (revised date) 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, 07 May 2013 12:41:26 -0000 Hi alll, before the meeting I'd like to express some thoughts about the topic. First, I think this is a very important problem. Untill we implemented IKE fragmentation, many of our "road warrior" customers complained that they couldn't use IPsec from public places, like hotels, restaraunts etc. Such places often use cheap SOHO NAT boxes, that don't pass IP fragments through. Second, I (obviously) support draft-smyslov-ipsecme-ikev2-fragmentation as solution for IKEv2, for the following reasons: 1. comparing with the non-standard IKEv1 mechanism it is more robust to DoS attacks (for the modest price), provides capability for PMTU discovery, well suited for IKEv2 and is IPR free. It is implemented and tested in fields. 2. IKE-over-TCP is an interesting solution, but, I think, it became too cumbersome as more details were considered. As usual, devil in details. Regards, Valery Smyslov. > The ipsecme working group is chartered to come up with a solution for > transporting long IKEv2 messages over networks that do not perform IP > fragmentation correctly, and as a result drop overly long messages, > usually IKE_AUTH messages. > > We would like to invite the group to a Virtual Interim Meeting (a.k.a. > conference call), to discuss this problem. > > Potential outcomes of the meeting include: > - The group decides that this is not an important problem. > - This is an important problem and we have 1-2 people committed to author > a draft along the lines of the non-standard IKEv1 mechanism. > - This is an important problem and the group is happy to adopt > draft-smyslov-ipsecme-ikev2-fragmentation (which solves the same problem > in a somewhat different fashion). > - The group still prefers IKE-over-TCP and there are committed authors to > continue work on that draft. From ynir@checkpoint.com Tue May 7 06:00:03 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 2982621F907E for ; Tue, 7 May 2013 06:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 Qai15uMHw7Mj for ; Tue, 7 May 2013 05:59:58 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 193B321F905F for ; Tue, 7 May 2013 05:59:57 -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 r47CxtRq029117; Tue, 7 May 2013 15:59:55 +0300 X-CheckPoint: {5188F940-1-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Tue, 7 May 2013 15:59:55 +0300 From: Yoav Nir To: Valery Smyslov Thread-Topic: [IPsec] IPsecME virtual interim meeting (revised date) Thread-Index: AQHORam5ZxuxdS9gCkedkzry4uPQm5j5tSZ7///Sw4A= Date: Tue, 7 May 2013 12:59:53 +0000 Message-ID: References: <517FCC2A.8060904@gmail.com> <1D5C3857EF7C48AF9A952CB5AEA3CB21@buildpc> In-Reply-To: <1D5C3857EF7C48AF9A952CB5AEA3CB21@buildpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.134] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 1186b1b8abe78648fa3e52aed378d3ed12f8cc5eea Content-Type: text/plain; charset="us-ascii" Content-ID: <055FD3638241EF409549A31991680DCE@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] IPsecME virtual interim meeting (revised date) 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, 07 May 2013 13:00:03 -0000 Hi Valery. I agree with your conclusion (that we should do an IKE fragment thing, mayb= e based on your draft). However, 2 comments: 1. You can never know if anything is IPR free. At best you can say that no= body has said anything yet. 2. IKE over TCP has worked for over 10 years in my company's products and = worked well. So the details can be ironed out. The reason we abandoned this= technology is that the broken SOHO devices began to not only drop fragment= s, but to also drop anything that wasn't TCP to a specific group of ports. = IKE-over-TCP could not solve this issue. Yoav On May 7, 2013, at 3:40 PM, Valery Smyslov wrote: > Hi alll, >=20 > before the meeting I'd like to express some thoughts about the topic. >=20 > First, I think this is a very important problem. Untill we implemented > IKE fragmentation, many of our "road warrior" customers complained that > they couldn't use IPsec from public places, like hotels, restaraunts etc. > Such places often use cheap SOHO NAT boxes, that don't > pass IP fragments through. >=20 > Second, I (obviously) support draft-smyslov-ipsecme-ikev2-fragmentation > as solution for IKEv2, for the following reasons: >=20 > 1. comparing with the non-standard IKEv1 mechanism it is more robust > to DoS attacks (for the modest price), provides capability for PMTU dis= covery, > well suited for IKEv2 and is IPR free. It is implemented and tested in = fields. >=20 > 2. IKE-over-TCP is an interesting solution, but, I think, it became too c= umbersome > as more details were considered. As usual, devil in details. >=20 > Regards, > Valery Smyslov. >=20 >=20 >> The ipsecme working group is chartered to come up with a solution for tr= ansporting long IKEv2 messages over networks that do not perform IP fragmen= tation correctly, and as a result drop overly long messages, usually IKE_AU= TH messages. >>=20 >> We would like to invite the group to a Virtual Interim Meeting (a.k.a. c= onference call), to discuss this problem. >>=20 >> Potential outcomes of the meeting include: >> - The group decides that this is not an important problem. >> - This is an important problem and we have 1-2 people committed to autho= r a draft along the lines of the non-standard IKEv1 mechanism. >> - This is an important problem and the group is happy to adopt draft-smy= slov-ipsecme-ikev2-fragmentation (which solves the same problem in a somewh= at different fashion). >> - The group still prefers IKE-over-TCP and there are committed authors t= o continue work on that draft. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Email secured by Check Point From svanru@gmail.com Tue May 7 06:18: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 5AF3B21F8EC1 for ; Tue, 7 May 2013 06:18:32 -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.799, 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 XJqdU7NxT3WK for ; Tue, 7 May 2013 06:18:31 -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 228BC21F8EBC for ; Tue, 7 May 2013 06:18:30 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id ep20so552136lab.38 for ; Tue, 07 May 2013 06:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=gNSWcypY/+hUFTG1Sbxx2zb7n3WH7crTeHzLDR0dV2s=; b=DPevB1KBl/6tk8LSpOg9zYf8Bj1s4YxT3ijtiqGgwSqq5HiUR6tm2u4JZqdhWYd8vO hz6vRE6PfjPJJvZFo2pfOctXnQAITli59LXRXp69yi0Nt8JFPPoDbRy/aCESg23YExPW StOIsl9E4BlUjUBaimfD+E5JBSyMl0FDEyOyIb6svyNL2xEA6LwFxYcGufPtDjadjx0p 5V190mGRzIwSUrAVnxvz2e6cWMmH6VVZ6oeNlfXqUoASwmrVkbsNJXteJRGExtjtXlj9 nE3PpFMH4aY7aPOuMO47TSR/xPNUTlNrJGuY3LCVgGzDodkkvi9eYanApL45wIT3YnTb 2UBA== X-Received: by 10.112.173.39 with SMTP id bh7mr1069711lbc.62.1367932710072; Tue, 07 May 2013 06:18:30 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id 4sm3490322lbi.16.2013.05.07.06.18.28 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 06:18:29 -0700 (PDT) Message-ID: <5DCEA3A89A1346958FC20B990E5D68C8@buildpc> From: "Valery Smyslov" To: "Yoav Nir" References: <517FCC2A.8060904@gmail.com> <1D5C3857EF7C48AF9A952CB5AEA3CB21@buildpc> Date: Tue, 7 May 2013 17:18:27 +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] IPsecME virtual interim meeting (revised date) 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, 07 May 2013 13:18:32 -0000 Hi Yoav, > I agree with your conclusion (that we should do an IKE fragment thing, > maybe based on your draft). > > However, 2 comments: > > 1. You can never know if anything is IPR free. At best you can say that > nobody has said anything yet. Yes, I agree. I only meant that neither I, nor my company didn't claim IPR. Of course, somebody might have claimed IPR for similar approach before. > 2. IKE over TCP has worked for over 10 years in my company's products and > worked well. So the details can be ironed out. Of course, although from my understanding IKE over TCP for IKEv2 will have more issues to iron out than for IKEv1... > The reason > we abandoned this technology is that the broken SOHO devices > began to not only drop fragments, but to also > drop anything that wasn't TCP to a specific group of ports. IKE-over-TCP > could not solve this issue. Unfortunately, IKE fragmentation couldn't solve this either... From ynir@checkpoint.com Tue May 7 06:37: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 7A2BE21F8FDB for ; Tue, 7 May 2013 06:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.351 X-Spam-Level: X-Spam-Status: No, score=-10.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 Qph82VrQEtTN for ; Tue, 7 May 2013 06:37:22 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4C07621F8FB2 for ; Tue, 7 May 2013 06:37: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 r47DbJcp008011; Tue, 7 May 2013 16:37:19 +0300 X-CheckPoint: {51890203-A-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Tue, 7 May 2013 16:37:19 +0300 From: Yoav Nir To: Valery Smyslov Thread-Topic: [IPsec] IPsecME virtual interim meeting (revised date) Thread-Index: AQHORam5ZxuxdS9gCkedkzry4uPQm5j5tSZ7///Sw4CAADeIQ///0u0A Date: Tue, 7 May 2013 13:37:18 +0000 Message-ID: References: <517FCC2A.8060904@gmail.com> <1D5C3857EF7C48AF9A952CB5AEA3CB21@buildpc> <5DCEA3A89A1346958FC20B990E5D68C8@buildpc> In-Reply-To: <5DCEA3A89A1346958FC20B990E5D68C8@buildpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.134] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11013f2ddec6cd790c1002d1d9f838aad0c89e6c87 Content-Type: text/plain; charset="Windows-1252" Content-ID: <99C87119CC201542AF94B5652F8E4591@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] IPsecME virtual interim meeting (revised date) 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, 07 May 2013 13:37:28 -0000 On May 7, 2013, at 4:18 PM, Valery Smyslov wrote: >=20 >=20 >> The reason > we abandoned this technology is that the broken SOHO device= s began to not only drop fragments, but to also >> drop anything that wasn't TCP to a specific group of ports. IKE-over-TCP= could not solve this issue. >=20 > Unfortunately, IKE fragmentation couldn't solve this either=85 And so, SSL-VPN clients were born=85 From wwwrun@rfc-editor.org Wed May 8 06:05: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 1671721F85EF for ; Wed, 8 May 2013 06:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.333 X-Spam-Level: X-Spam-Status: No, score=-101.333 tagged_above=-999 required=5 tests=[AWL=1.267, 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 k2JqaRwXLJhE for ; Wed, 8 May 2013 06:05:47 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A77EA21F85CE for ; Wed, 8 May 2013 06:05:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1AB75B1E004; Wed, 8 May 2013 06:05:40 -0700 (PDT) To: rsj@cisco.com, kagarigi@cisco.com, ynir@checkpoint.com, yaronf.ietf@gmail.com, zhangdacheng@huawei.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, paul.hoffman@vpnc.org, yaronf.ietf@gmail.com From: RFC Errata System Message-Id: <20130508130540.1AB75B1E004@rfc-editor.org> Date: Wed, 8 May 2013 06:05:40 -0700 (PDT) X-Mailman-Approved-At: Wed, 08 May 2013 08:01:13 -0700 Cc: ipsec@ietf.org, ynir@checkpoint.com, rfc-editor@rfc-editor.org Subject: [IPsec] [Editorial Errata Reported] RFC6311 (3615) 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, 08 May 2013 13:05:52 -0000 The following errata report has been submitted for RFC6311, "Protocol Support for High Availability of IKEv2/IPsec". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6311&eid=3615 -------------------------------------- Type: Editorial Reported by: Yoav Nir Section: 6.4 Original Text ------------- Note that this solution requires that either all Child SAs use Extended Sequence Numbers (ESNs) or else that no Child SA uses ESNs. Corrected Text -------------- Note that this solution requires that either all Child SAs use Extended Sequence Numbers (ESN) or else that no Child SA uses ESN. Notes ----- "ESN" is used here as a name of a feature. There is no need to pluralize it. This is different from "SAs" or "SPIs", where there are many of each. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6311 (draft-ietf-ipsecme-ipsecha-protocol-06) -------------------------------------- Title : Protocol Support for High Availability of IKEv2/IPsec Publication Date : July 2011 Author(s) : R. Singh, Ed., G. Kalyani, Y. Nir, Y. Sheffer, D. Zhang Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From paul.hoffman@vpnc.org Wed May 8 08:12: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 EF26821F9223 for ; Wed, 8 May 2013 08:12: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=[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 jZ-ukOWhUcNS for ; Wed, 8 May 2013 08:12:15 -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 598F021F9079 for ; Wed, 8 May 2013 08:12:15 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r48FAnUD007960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 May 2013 08:10:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <20130508130540.1AB75B1E004@rfc-editor.org> Date: Wed, 8 May 2013 08:10:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <425FD752-ED8E-4B3F-8E26-25A762F9563F@vpnc.org> References: <20130508130540.1AB75B1E004@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1503) Cc: IPsecme WG , Sean Turner , Stephen Farrell Subject: Re: [IPsec] [Editorial Errata Reported] RFC6311 (3615) 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, 08 May 2013 15:12:16 -0000 This is a small editorial change, and should be accepted. The RFC Editor = should add this change to its internal style guide for IPsec-related = documents. --Paul Hoffman On May 8, 2013, at 6:05 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC6311, > "Protocol Support for High Availability of IKEv2/IPsec". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6311&eid=3D3615 >=20 > -------------------------------------- > Type: Editorial > Reported by: Yoav Nir >=20 > Section: 6.4 >=20 > Original Text > ------------- > Note that this solution requires that either = all Child SAs > use Extended Sequence Numbers (ESNs) or else that no Child SA uses > ESNs. >=20 > Corrected Text > -------------- > Note that this solution requires that either = all Child SAs > use Extended Sequence Numbers (ESN) or else that no Child SA uses > ESN. >=20 > Notes > ----- > "ESN" is used here as a name of a feature. There is no need to = pluralize it. This is different from "SAs" or "SPIs", where there are = many of each. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6311 (draft-ietf-ipsecme-ipsecha-protocol-06) > -------------------------------------- > Title : Protocol Support for High Availability of = IKEv2/IPsec > Publication Date : July 2011 > Author(s) : R. Singh, Ed., G. Kalyani, Y. Nir, Y. Sheffer, = D. Zhang > Category : PROPOSED STANDARD > Source : IP Security Maintenance and Extensions > Area : Security > Stream : IETF > Verifying Party : IESG > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 From ietf-ipr@ietf.org Thu May 9 12:41: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 973CD21F8756; Thu, 9 May 2013 12:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.242, 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 uHqJ9bsWuxWW; Thu, 9 May 2013 12:41:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5DE21F86C1; Thu, 9 May 2013 12:41:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: yaronf.ietf@gmail.com, sfluhrer@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130509194111.30890.3049.idtracker@ietfa.amsl.com> Date: Thu, 09 May 2013 12:41:11 -0700 Cc: paul.hoffman@vpnc.org, ipsec@ietf.org, turners@ieca.com, ipr-announce@ietf.org, stephen.farrell@cs.tcd.ie Subject: [IPsec] IPR Disclosure: Certicom Corporation's Statement about IPR related to draft-ietf-ipsecme-dh-checks-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, 09 May 2013 19:41:12 -0000 Dear Yaron Sheffer, Scott Fluhrer: An IPR disclosure that pertains to your Internet-Draft entitled "Additional Diffie-Hellman Tests for IKEv2" (draft-ietf-ipsecme-dh-checks) was submitte= d to the IETF Secretariat on 2013-05-09 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2072/). The title of the IPR disclosure is "Certicom Corporation's Statement about IPR related to draft-ietf-ipsecme-d= h- checks-04.""); The IETF Secretariat From mcr@sandelman.ca Fri May 10 10:14: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 B905E21F84D8 for ; Fri, 10 May 2013 10:14:48 -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 kmBxXWlYkejV for ; Fri, 10 May 2013 10:14:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id D0BD421F84A9 for ; Fri, 10 May 2013 10:14:42 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id AF9582016D for ; Fri, 10 May 2013 13:26:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6E6CF63A7E; Fri, 10 May 2013 13:13:33 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5A1DF639DF for ; Fri, 10 May 2013 13:13:33 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <20130509194111.30890.3049.idtracker@ietfa.amsl.com> References: <20130509194111.30890.3049.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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] IPR Disclosure: Certicom Corporation's Statement about IPR related to draft-ietf-ipsecme-dh-checks-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, 10 May 2013 17:14:48 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I read: http://www.google.com/patents/US7215773 and I find:=20 In RSA or Rabin signatures there are generally three routines, namely key pair generation, signature generation and signature verification. Validating an RSA public key (n, e) involves three steps. Firstly validate e, secondly validate n and thirdly validate e and n are consistent with each other. In order to validate the public exponent e, use of made of the fact that the exponent 2<=3De<=3D2(k I can not speculate as to whether there is prior art, but it seems to match what we have been discussing. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUY0qvYqHRg3pndX9AQJ6iQP5Adn4pcOuCfFpn3/mHLIV3ky4wGbmz/a2 TZelECmC1WbZrVHclP9BJ/27psSiUWQSQZ12Pc/VLisLSvLFACPsVwaLXdpG+Qk8 7KTSv99sM5kqy3clY/XndaPjnfE5TTsBvhu6aJSSCQ6ZIyHKp4BgGFdAD0ggJxoy IMZDCI/a4R8= =VLD+ -----END PGP SIGNATURE----- --=-=-=-- From paul.hoffman@vpnc.org Fri May 10 10:20: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 364DC21F85C3 for ; Fri, 10 May 2013 10:20:58 -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 t--gYlFLuTJm for ; Fri, 10 May 2013 10:20:57 -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 B404621F8536 for ; Fri, 10 May 2013 10:20:57 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4AHKtHT099023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 10 May 2013 10:20:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <1679.1368206013@sandelman.ca> Date: Fri, 10 May 2013 10:20:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3A048F7F-4E75-43C4-9D7F-65A3298C5DAC@vpnc.org> References: <20130509194111.30890.3049.idtracker@ietfa.amsl.com> <1679.1368206013@sandelman.ca> To: IPsecme WG X-Mailer: Apple Mail (2.1503) Subject: Re: [IPsec] IPR Disclosure: Certicom Corporation's Statement about IPR related to draft-ietf-ipsecme-dh-checks-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, 10 May 2013 17:20:58 -0000 On May 10, 2013, at 10:13 AM, Michael Richardson = wrote: > I can not speculate as to whether there is prior art, but it seems to > match what we have been discussing. "We" have not been discussing it, and nor should we. Certicom has filed = numerous IPR statements with the IETF over more than a decade. Earlier = discussions of earlier IPR statements have not come to any general = understanding of what Certicom claims and what they intend to do with = those claims. In the absence of that understanding (which can be aided = by Certicom at any time), there is no point in using the WG mailing list = for guessing. WG participants who want to read more about IPR are advised to see = . --Paul Hoffman= From paul.hoffman@vpnc.org Fri May 10 13:39: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 DE41021F9164 for ; Fri, 10 May 2013 13:39: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=[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 8C4RoW1u-DBv for ; Fri, 10 May 2013 13:39:01 -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 73AEE21F89B2 for ; Fri, 10 May 2013 13:39:01 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4AKd0gD004442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 10 May 2013 13:39:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 10 May 2013 13:39:00 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [IPsec] Virtual Interim on IKEv2 and fragmentation: 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: Fri, 10 May 2013 20:39:02 -0000 Greetings again. =46rom the earlier announcement: The IPsecME Working Group will hold a virtual interim meeting on Thursday, May 16, 2013 via a phone bridge. The meeting will focus on whether solutions are needed for fragmentation of IKEv2 messages, and potential options in this space. For more background, see http://www.ietf.org/mail-archive/web/ipsec/current/msg08371.html. The time for the meeting is: 9:00am PDT 16:00 UTC 12:00 noon EDT 19:00 Israel The meeting will last 1 hour, maybe less. The agenda will be: - Introduction to the problem (Yaron and Paul) - Discussion of draft-smyslov-ipsecme-ikev2-fragmentation (Valery) 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 prvs=6845ebe474=mcampagna@blackberry.com Mon May 13 09:11: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 7DE5221F92BC for ; Mon, 13 May 2013 09:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 CUW+tH4IOEJb for ; Mon, 13 May 2013 09:11:16 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5F521F9195 for ; Mon, 13 May 2013 09:11:16 -0700 (PDT) X-AuditID: 0a41282f-b7fd66d000003d50-bf-51911096c66b Received: from XCT103CNC.rim.net (smtp-pop.rim.net [10.65.161.203]) by mhs060cnc.rim.net (SBG) with SMTP id 52.23.15696.69011915; Mon, 13 May 2013 11:11:02 -0500 (CDT) Received: from XMB118CNC.rim.net ([fe80::552f:5e53:97d:d179]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.02.0328.009; Mon, 13 May 2013 12:11:02 -0400 From: Matthew Campagna To: Paul Hoffman , IPsecme WG Thread-Topic: [IPsec] IPR Disclosure: Certicom Corporation's Statement about IPR related to draft-ietf-ipsecme-dh-checks-04 Thread-Index: AQHOTaHigq6r+akW5kKPMkf6RiFryJj+7T+AgARdxCA= Date: Mon, 13 May 2013 16:11:01 +0000 Message-ID: <5F51C39ADB3BAE4FB07D50180746A05837916D0D@XMB118CNC.rim.net> References: <20130509194111.30890.3049.idtracker@ietfa.amsl.com> <1679.1368206013@sandelman.ca> <3A048F7F-4E75-43C4-9D7F-65A3298C5DAC@vpnc.org> In-Reply-To: <3A048F7F-4E75-43C4-9D7F-65A3298C5DAC@vpnc.org> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsXC5bjwtO40gYmBBlefW1rs3/KCzeLW+i+s DkweS5b8ZPL4PPsqcwBTVAOjTVJiSVlwZnqevp1NYl5efkliSapCSmpxsq2ST2p6Yo5CQFFm WWJypYJLZnFyTmJmbmqRkkJmiq2SiZJCQU5icmpual6JrVJiQUFqXoqSHZcCBrABKsvMU0jN S85PycxLt1XyDPbXtbAwtdQ1VLLTTejkyfiybDVzwT2+ipZTvewNjP08XYycHBICJhJPNj1g hbDFJC7cW8/WxcjFISSwklHi6odJTCAJIYGNjBJ779mD2GwChhJf711hA7FFBFwl3m2+BtYs LFAjsaZ3LRNEvFbi+ZYVLBC2lUTzlu1g9SwCqhI3V/eBxXkFPCTe3JwLNX8yo8TUy/wgNqeA jUTPgzNgMxkFZCXWzlkJZjMLiEvcejKfCeJQAYkle84zQ9iiEi8f/4N6QFHi2Z2l7BD1ehI3 pk5hg7C1JZYtfM0MsVdQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUomJtRbGBmkJyXrFeU mauXl1qyiRGcDjT0dzC+fW9xiFGAg1GJhzfx74RAIdbEsuLK3EOMEhzMSiK8+3knBgrxpiRW VqUW5ccXleakFh9idAWGykRmKe7kfGCqyiuJNzYwwM1REuetcqsMFBJIByaf7NTUgtQimDlM HJwge7ikRIqBKSS1KLG0JCMelOjii4GpTqqBMc3Cd3dBm+K1b44vNk4MFVF4FJH2OyunPzj5 eceppctnnbKb+8HZlyfq+eVAoYNtMycv5L51VHW+mW/e4haFM8zXTYKd1z9o+1I1qzvxi8Xq CzYLFW+uKthYIh28NujlTtFS1aOT7cWXdYdW1eo0HfHtu3vewv69V2hCyJO63HeGwV+DJMI2 KrEUZyQaajEXFScCAFJLAddIAwAA X-Mailman-Approved-At: Mon, 13 May 2013 09:44:16 -0700 Subject: Re: [IPsec] IPR Disclosure: Certicom Corporation's Statement about IPR related to draft-ietf-ipsecme-dh-checks-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, 13 May 2013 16:13:21 -0000 Paul et al, I would like to draw the groups attention to "Section VIII. Other Notes:"= of the declaration https://datatracker.ietf.org/ipr/2072/. It highlights p= revious declarations in regards to the referenced patent and its use in affi= liated IPSec and IKE specifications. I personally hope that these earlier statements cover the bulk of concerns= and expected uses. Sincerely, Matt Campagna Matthew Campagna - Director, Certicom Research BlackBerry mcampagna@certicom.com direct =A0=A0=A0=A0=A0=A0=A0=A0=A0203.894.9777 office=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 877.746.5831x14181# http://www.blackberry.com -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Pa= ul Hoffman Sent: Friday, May 10, 2013 1:21 PM To: IPsecme WG Subject: Re: [IPsec] IPR Disclosure: Certicom Corporation's Statement about= IPR related to draft-ietf-ipsecme-dh-checks-04 On May 10, 2013, at 10:13 AM, Michael Richardson wro= te: > I can not speculate as to whether there is prior art, but it seems to > match what we have been discussing. "We" have not been discussing it, and nor should we. Certicom has filed nume= rous IPR statements with the IETF over more than a decade. Earlier discussio= ns of earlier IPR statements have not come to any general understanding of w= hat Certicom claims and what they intend to do with those claims. In the abs= ence of that understanding (which can be aided by Certicom at any time), the= re is no point in using the WG mailing list for guessing. WG participants who want to read more about IPR are advised to see . --Paul Hoffman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From ynir@checkpoint.com Mon May 13 12:32: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 EC6B521F8A74 for ; Mon, 13 May 2013 12:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.732 X-Spam-Level: X-Spam-Status: No, score=-9.732 tagged_above=-999 required=5 tests=[AWL=0.867, 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 oTjJCcAATBGg for ; Mon, 13 May 2013 12:32:20 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3046021F89EB for ; Mon, 13 May 2013 12:32:18 -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 r4DJWAl9001384; Mon, 13 May 2013 22:32:10 +0300 X-CheckPoint: {51913DDE-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Mon, 13 May 2013 22:32:09 +0300 From: Yoav Nir To: Matthew Campagna Thread-Topic: [IPsec] IPR Disclosure: Certicom Corporation's Statement about IPR related to draft-ietf-ipsecme-dh-checks-04 Thread-Index: AQHOT/mV5szxpieUcEePFXQH3x+s25kDTvqA Date: Mon, 13 May 2013 19:32:09 +0000 Message-ID: References: <20130509194111.30890.3049.idtracker@ietfa.amsl.com> <1679.1368206013@sandelman.ca> <3A048F7F-4E75-43C4-9D7F-65A3298C5DAC@vpnc.org> <5F51C39ADB3BAE4FB07D50180746A05837916D0D@XMB118CNC.rim.net> In-Reply-To: <5F51C39ADB3BAE4FB07D50180746A05837916D0D@XMB118CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.184] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11252453f47a1c9bc095d5ea33d542767b77a1037c Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] IPR Disclosure: Certicom Corporation's Statement about IPR related to draft-ietf-ipsecme-dh-checks-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, 13 May 2013 19:32:25 -0000 Hi Matthew. Actually, that section makes it all the more puzzling. It lists 3 disclosur= es that relate to several RFCs, but none of those RFCs relates to Diffie-He= llman. Instead they relate to lists of algorithms, so I'm not sure how this= helps cover the concerns. Yoav On May 13, 2013, at 7:11 PM, Matthew Campagna wr= ote: > Paul et al, >=20 > I would like to draw the groups attention to "Section VIII. Other Notes= :" of the declaration https://datatracker.ietf.org/ipr/2072/. It highlight= s previous declarations in regards to the referenced patent and its use in = affiliated IPSec and IKE specifications. >=20 > I personally hope that these earlier statements cover the bulk of concer= ns and expected uses. >=20 > Sincerely, > Matt Campagna >=20 >=20 > Matthew Campagna - Director, Certicom Research=20 > BlackBerry >=20 > mcampagna@certicom.com > direct 203.894.9777 > office 877.746.5831x14181# > http://www.blackberry.com >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of= Paul Hoffman > Sent: Friday, May 10, 2013 1:21 PM > To: IPsecme WG > Subject: Re: [IPsec] IPR Disclosure: Certicom Corporation's Statement abo= ut IPR related to draft-ietf-ipsecme-dh-checks-04 >=20 > On May 10, 2013, at 10:13 AM, Michael Richardson = wrote: >=20 >> I can not speculate as to whether there is prior art, but it seems to=20 >> match what we have been discussing. >=20 >=20 > > "We" have not been discussing it, and nor should we. Certicom has filed n= umerous IPR statements with the IETF over more than a decade. Earlier discu= ssions of earlier IPR statements have not come to any general understanding= of what Certicom claims and what they intend to do with those claims. In t= he absence of that understanding (which can be aided by Certicom at any tim= e), there is no point in using the WG mailing list for guessing. >=20 > WG participants who want to read more about IPR are advised to see . >=20 > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Email secured by Check Point From yaronf.ietf@gmail.com Wed May 15 07:22: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 CA0DB21F8F62 for ; Wed, 15 May 2013 07:22:32 -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 RINxbS3QpHBB for ; Wed, 15 May 2013 07:22:32 -0700 (PDT) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 199FD21F899E for ; Wed, 15 May 2013 07:22:31 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id my1so1055233bkb.33 for ; Wed, 15 May 2013 07:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qRUJ+HOzwXpVHn4luZ0PElYSa+3cUcFG8H+Eq/rZUEg=; b=F6U7tpOmnZ5Jvmdkc27IRrU1+V0+kJI74z/T6+9WmoVDR+15l3Pm1W/ioWPwQo1GxD jzehNpZ8o4HL/jHFmVvDvxVGdzvRlaFUhgJ77jB+EGISEaS2vmjIteOB3MtIfmurEiju 2wnSn4ujFsMZxxvRlKSvBbFNfD62zPWuoD1byPm3kr8ie7ITF8ZKcYm8i25/WOAgIHEM 1/5R3L8E+stN773Wvl0YoxxqmMxIh8FM5s+b64Dd0wCFuqS4iurCABnSkmrejAFSMJ5m 7jZlbLk6VUl2FaBEl96FucR9tmkScJghwcGzm5tGrTfhiPJUJwk5PoJEdHY/UE9Koiri r4Vg== X-Received: by 10.204.226.136 with SMTP id iw8mr10241655bkb.135.1368627751149; Wed, 15 May 2013 07:22:31 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-176-96-12.red.bezeqint.net. [79.176.96.12]) by mx.google.com with ESMTPSA id es13sm910915bkc.8.2013.05.15.07.22.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 May 2013 07:22:30 -0700 (PDT) Message-ID: <51939A24.5070205@gmail.com> Date: Wed, 15 May 2013 17:22:28 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: IPsecme WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Reminder: Virtual Interim on IKEv2 and fragmentation: tomorrow 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, 15 May 2013 14:22:32 -0000 Greetings again. From the earlier announcement: The IPsecME Working Group will hold a virtual interim meeting on Thursday, May 16, 2013 via a phone bridge. The meeting will focus on whether solutions are needed for fragmentation of IKEv2 messages, and potential options in this space. For more background, see http://www.ietf.org/mail-archive/web/ipsec/current/msg08371.html. The time for the meeting is: 9:00am PDT 16:00 UTC 12:00 noon EDT 19:00 Israel The meeting will last 1 hour, maybe less. The agenda will be: - Introduction to the problem (Yaron and Paul) - Discussion of draft-smyslov-ipsecme-ikev2-fragmentation (Valery) 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 yaronf.ietf@gmail.com Thu May 16 09:57: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 7D50411E8102 for ; Thu, 16 May 2013 09:57:32 -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 XaB-WkTS7CCF for ; Thu, 16 May 2013 09:57:32 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B43EB21F93D7 for ; Thu, 16 May 2013 09:57:30 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id e12so364763wgh.14 for ; Thu, 16 May 2013 09:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=xSb/f14gvSLPf85gxWt37CZyWSeCRPEv7qdHx62Y2Bg=; b=Sp44pDQycF9TT2/AcWcHedkVwbxzfhE2YEYSGMoZzKZkhZz/WaKVaHpqy+cLX6VAso b3KjxKRXus1BSbRmI9b0NxmVLpcBe2idmM55QSHT98n/OjEEnjryZs+X5iaCvKqC7SFh kFQUIQKCb7IyoJa6LS3YcQaHsxXg1Wfuk4cIMVj/wp6ylKY8r69Mxu+fUQ2T9GolQcD3 21H0rNXJpL7TOXqRaZ/m2Ot+cLtQuoIItJkZOIEodMa/g7aGWzATGR4qZAzxrirxBuiV Sxph3hSxfi6hWRs+gkEk7mISv/Eu3twPD7OYKDoVhUwPuc1QH9fbJ2ffH+V/h7vjhxMV aAfw== X-Received: by 10.180.39.137 with SMTP id p9mr26087961wik.27.1368723449841; Thu, 16 May 2013 09:57:29 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-182-153-201.red.bezeqint.net. [79.182.153.201]) by mx.google.com with ESMTPSA id eq15sm5035220wic.4.2013.05.16.09.57.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 09:57:29 -0700 (PDT) Message-ID: <51950FF7.1050707@gmail.com> Date: Thu, 16 May 2013 19:57:27 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: IPsecme WG References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] IPsecME virtual meeting minutes, and way forward with 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: Thu, 16 May 2013 16:57:32 -0000 Hi, As promised, we just had a virtual interim meeting to discuss IKEv2 fragmentation. Please see the minutes below (thanks Paul!). Following up on this meeting, we would like to confirm the decision on the mailing list: - The group still thinks this is an important problem that needs an interoperable solution. - We would like to abandon the work on IKE-over-TCP. - And to work on IKEv2 protocol-level fragmentation, using draft-smyslov-ipsecme-ikev2-fragmentation as a starting point. Please send your approval, disapproval or comments to the list within a week (until May 23). Thanks, Yaron -------- Original Message -------- Subject: Proposed minutes for today IPsecME WG Virtual Interim Meeting, 2013-05-16 Minutes taken by Paul Hoffman Yaron gave introduction Introduction superfluous We have little energy Maybe the draft should be individual draft with discussion on the list Valery: is OK with this being Individual Submission Yoav: wants it to be a WG document Cisco has its own running code that is non-interoperable Brian: Cisco would have to do the eventual result anyway Yoav: Cisco is more likely to implement if they were part of the discussion Yaron wonders if this is a problem that needs to be resolved Yoav: yes, and would rather work with an RFC Tero: the problem is still there, but it just won't be TCP The WG needs to have implementers reviews at the start Yaron: do we want to stay with the current TCP-based solution? Brian: might be running on sensors that don't have a TCP stack Yoav: even he won't implement it Yaron: is Valery's draft better than what several non-standard implementations of what IKEv1 did Yoav: just copying what IKEv1 did is probably wrong; doesn't know Valery: they implemented for IKEv1 based on Microsoft's implementation If we introduce negotiation in IKEv2, it won't be exactly the same The implementation will be different, but similar Brian: it looks very similar but using a Notify for signaling, which is an advantage Next steps: Ask the WG Abandon IKE TCP Adopt Valery's draft Blue sheet: Brian Weis Daneil Migault Paul Hoffman Tero Kivinen Valery Smyslov Yaron Sheffer Yoav Nir From paul@nohats.ca Thu May 16 10:08: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 15B6321F85D6 for ; Thu, 16 May 2013 10:08:21 -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 jYP8+fBXaSza for ; Thu, 16 May 2013 10:08:13 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9114221F8F28 for ; Thu, 16 May 2013 10:08:12 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3bBJx35mylz1jb; Thu, 16 May 2013 13:08: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 XWj0-Py7AODg; Thu, 16 May 2013 13:08:06 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Thu, 16 May 2013 13:08:05 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id E1B6981323; Thu, 16 May 2013 13:08:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D966180C7D; Thu, 16 May 2013 13:08:05 -0400 (EDT) Date: Thu, 16 May 2013 13:08:05 -0400 (EDT) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <51950FF7.1050707@gmail.com> Message-ID: References: <51950FF7.1050707@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPsecme WG Subject: Re: [IPsec] IPsecME virtual meeting minutes, and way forward with 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: Thu, 16 May 2013 17:08:21 -0000 On Thu, 16 May 2013, Yaron Sheffer wrote: > As promised, we just had a virtual interim meeting to discuss IKEv2 > fragmentation. Please see the minutes below (thanks Paul!). > > Following up on this meeting, we would like to confirm the decision on the > mailing list: > > - The group still thinks this is an important problem that needs an > interoperable solution. > - We would like to abandon the work on IKE-over-TCP. > - And to work on IKEv2 protocol-level fragmentation, using > draft-smyslov-ipsecme-ikev2-fragmentation as a starting point. Sorry I missed the meeting. I approve of the conclusions reached. Paul From andreas.steffen@strongswan.org Thu May 16 10:30: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 C685211E8111 for ; Thu, 16 May 2013 10:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.988 X-Spam-Level: X-Spam-Status: No, score=-5.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, 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 aEFiRqvzpK5c for ; Thu, 16 May 2013 10:30:10 -0700 (PDT) Received: from strongswan.org (sitav-80024.hsr.ch [152.96.80.24]) by ietfa.amsl.com (Postfix) with ESMTP id ECD8F11E810E for ; Thu, 16 May 2013 10:30:09 -0700 (PDT) Received: from 84-75-148-118.dclient.hispeed.ch ([84.75.148.118] helo=[10.10.0.33]) by strongswan.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Ud20B-0002Lb-EV; Thu, 16 May 2013 19:30:03 +0200 Message-ID: <5195179E.8090901@strongswan.org> Date: Thu, 16 May 2013 19:30:06 +0200 From: Andreas Steffen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: IPsecme WG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [IPsec] Approve 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, 16 May 2013 17:30:14 -0000 Hi list, I approve of using draft-smyslov-ipsecme-ikev2-fragmentation as a starting for IKEv2 fragmentation. Regards Andreas ====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== From mglt.ietf@gmail.com Thu May 16 10:51: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 A718311E8138 for ; Thu, 16 May 2013 10:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 V+diS3cp8YL9 for ; Thu, 16 May 2013 10:51:56 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BDC5A11E812B for ; Thu, 16 May 2013 10:51:55 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hr14so74398wib.5 for ; Thu, 16 May 2013 10:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AAx9rD8mM/b0ca5IkL3JAGX22v1A3ZlEBBegOsIQMmU=; b=KH8sOpJTtlS/VFNcrUaxLYl5HCODM/gogRXLIznrt7ZJo5znnwV7wYyGjIeUVTWQeo dCcoIg8icu6SgroHv/3Cp1lALsblKSj+49Xbm1efyuTOWvtEEy3ad9AbPcAksdW9ZUDw tp9Fq7Ks9fWyVqjCtw6MmVP5kyB8QBgrm/uVdE9vPNc+BgmbMzo6JO3FPzpy84XCtHp9 tKayirqB1+gVXndtlKP1NEywNjtfaKUhE7Fa5ChbozTdGtEzQXRijt2v6N+/AgD4LGh2 CmXI/N/say3ewTUqFbt5+I9V1/ksO+B059sQN4i1t12xRnK9mEc6bk4So2MXKcCpzqpm JeCg== MIME-Version: 1.0 X-Received: by 10.180.109.48 with SMTP id hp16mr26777904wib.24.1368726714794; Thu, 16 May 2013 10:51:54 -0700 (PDT) Received: by 10.194.173.233 with HTTP; Thu, 16 May 2013 10:51:54 -0700 (PDT) In-Reply-To: References: <51950FF7.1050707@gmail.com> Date: Thu, 16 May 2013 19:51:54 +0200 Message-ID: From: Daniel Migault To: Paul Wouters Content-Type: multipart/alternative; boundary=e89a8f3ba91da14a4404dcd98541 Cc: IPsecme WG Subject: Re: [IPsec] IPsecME virtual meeting minutes, and way forward with 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: Thu, 16 May 2013 17:51:56 -0000 --e89a8f3ba91da14a4404dcd98541 Content-Type: text/plain; charset=ISO-8859-1 I am supporting IKE fragmentation supported by the application and thus support draft-smyslov-ipsecme-ikev2-fragmentation. BR Daniel On Thu, May 16, 2013 at 7:08 PM, Paul Wouters wrote: > On Thu, 16 May 2013, Yaron Sheffer wrote: > > As promised, we just had a virtual interim meeting to discuss IKEv2 >> fragmentation. Please see the minutes below (thanks Paul!). >> >> Following up on this meeting, we would like to confirm the decision on >> the mailing list: >> >> - The group still thinks this is an important problem that needs an >> interoperable solution. >> - We would like to abandon the work on IKE-over-TCP. >> - And to work on IKEv2 protocol-level fragmentation, using >> draft-smyslov-ipsecme-ikev2-**fragmentation as a starting point. >> > > Sorry I missed the meeting. I approve of the conclusions reached. > > Paul > > ______________________________**_________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/**listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --e89a8f3ba91da14a4404dcd98541 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am supporting IKE fragmentation supported by the applica= tion and thus support=A0draft-smyslov-ipsecme-ikev2-fragmentation.

BR=A0
= Daniel



= On Thu, May 16, 2013 at 7:08 PM, Paul Wouters <paul@nohats.ca> = wrote:
On Thu, 16 May 2013, Yaron= Sheffer wrote:

As promised, we just had a virtual interim meeting to discuss IKEv2 fragmen= tation. Please see the minutes below (thanks Paul!).

Following up on this meeting, we would like to confirm the decision on the = mailing list:

- The group still thinks this is an important problem that needs an interop= erable solution.
- We would like to abandon the work on IKE-over-TCP.
- And to work on IKEv2 protocol-level fragmentation, using draft-smyslov-ip= secme-ikev2-fragmentation as a starting point.

Sorry I missed the meeting. I approve of the conclusions reached.

Paul

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



--
= Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
--e89a8f3ba91da14a4404dcd98541-- From kivinen@iki.fi Thu May 16 11:58: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 1B2FC1F0D30 for ; Thu, 16 May 2013 11:58:11 -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 366dPmnHbEq0 for ; Thu, 16 May 2013 11:58:10 -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 E91CA1F0D33 for ; Thu, 16 May 2013 11:57:57 -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 r4GIvhbY016012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 May 2013 21:57:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id r4GIvh1N011283; Thu, 16 May 2013 21:57: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: <20885.11303.337807.961730@fireball.kivinen.iki.fi> Date: Thu, 16 May 2013 21:57:43 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <51950FF7.1050707@gmail.com> References: <51950FF7.1050707@gmail.com> X-Mailer: VM 7.19 under Emacs 24.3.1 X-Edit-Time: 0 min X-Total-Time: 1 min Cc: IPsecme WG Subject: [IPsec] IPsecME virtual meeting minutes, and way forward with 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: Thu, 16 May 2013 18:58:11 -0000 Yaron Sheffer writes: > - The group still thinks this is an important problem that needs an > interoperable solution. > - We would like to abandon the work on IKE-over-TCP. > - And to work on IKEv2 protocol-level fragmentation, using > draft-smyslov-ipsecme-ikev2-fragmentation as a starting point. > > Please send your approval, disapproval or comments to the list within a > week (until May 23). I approve the decision to take that draft as starting point. I have earlier said I do not care wheter it is TCP or fragmentation, but I think the problem is something that needs to be solved, and I would prefer to have just one standardized way to solve it. -- kivinen@iki.fi From svanru@gmail.com Thu May 16 12:44: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 AE86B21F8539 for ; Thu, 16 May 2013 12:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=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 x1bz4ootbuLo for ; Thu, 16 May 2013 12:43:59 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDD621F8F4F for ; Thu, 16 May 2013 12:43:58 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id u10so1530078lbi.33 for ; Thu, 16 May 2013 12:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:importance:x-mailer:x-mimeole; bh=3Q7djshDv52nXa2SU0tnzJYQVJ3ZaNLbTD0fx46p9oc=; b=Yc3SpFGricoiH79GZDdZCuUiXW4tToc1FshpeSQVffB82vzBfYH1YzIoRCk9ikKjv+ ykTVz/LJt1nXSVzUU0b3/NTIh/QnyyvEoAkm+VbPTjOVk6Yx5DGqXxBuvCKnWhKGfB7n ZnLTmnJMN5mhEifoxvLobaE3MqSeZ5jPSOhdqRNjXqDyK4H6nr9gXoRIYKnboO+V+IOr GSZZ/nMRQzsTJYp4nliJRvj2+uy5eV4vNOZkuvIRfKhyJdyt5Eg/Y8Gcs3a+rX9rCjcz BS+v2abqA+RMFgVHmmxk6mPX9bGSkPJoQyqP6jo32xns1WVckdaI23XbU34653xA+AkM Eerw== X-Received: by 10.112.120.170 with SMTP id ld10mr20626209lbb.31.1368733437125; Thu, 16 May 2013 12:43:57 -0700 (PDT) Received: from chichi (ppp91-77-176-35.pppoe.mtu-net.ru. [91.77.176.35]) by mx.google.com with ESMTPSA id c5sm3699545lbe.1.2013.05.16.12.43.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 16 May 2013 12:43:56 -0700 (PDT) Message-ID: <6A2F45C0AA874BF6814B8E20D0D524DE@chichi> From: "Valery Smyslov" To: "Yaron Sheffer" , "IPsecme WG" References: <51950FF7.1050707@gmail.com> In-Reply-To: <51950FF7.1050707@gmail.com> Date: Thu, 16 May 2013 23:43: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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MIMEOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Subject: Re: [IPsec] IPsecME virtual meeting minutes, and way forward with 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: Thu, 16 May 2013 19:44:05 -0000 Hi, I approved the conclusion. Regards, Valery. > - The group still thinks this is an important problem that needs an > interoperable solution. > - We would like to abandon the work on IKE-over-TCP. > - And to work on IKEv2 protocol-level fragmentation, using > draft-smyslov-ipsecme-ikev2-fragmentation as a starting point. > > Please send your approval, disapproval or comments to the list within a > week (until May 23). From ynir@checkpoint.com Thu May 16 12:46: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 47DB711E811D for ; Thu, 16 May 2013 12:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.274 X-Spam-Level: X-Spam-Status: No, score=-10.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 lDk+tlg3tDk2 for ; Thu, 16 May 2013 12:46:04 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 17C9C11E8104 for ; Thu, 16 May 2013 12:46:03 -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 r4GJk10h009688; Thu, 16 May 2013 22:46:01 +0300 X-CheckPoint: {51953575-A-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Thu, 16 May 2013 22:46:01 +0300 From: Yoav Nir To: Valery Smyslov Thread-Topic: [IPsec] IPsecME virtual meeting minutes, and way forward with fragmentation Thread-Index: AQHOUlZ7rCucu8Gu7Ua/fs0xyuHbH5kIBGsAgAAAmAA= Date: Thu, 16 May 2013 19:46:00 +0000 Message-ID: References: <51950FF7.1050707@gmail.com> <6A2F45C0AA874BF6814B8E20D0D524DE@chichi> In-Reply-To: <6A2F45C0AA874BF6814B8E20D0D524DE@chichi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.9] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 115df002b3d3dc6f43ac7b39a8ad2dcb0016a045c8 Content-Type: text/plain; charset="us-ascii" Content-ID: <7DABA0DDECEFFC44B96A87FBCEB7B648@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] IPsecME virtual meeting minutes, and way forward with 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: Thu, 16 May 2013 19:46:10 -0000 X-List-Received-Date: Thu, 16 May 2013 19:46:10 -0000 +1 On May 16, 2013, at 10:43 PM, Valery Smyslov wrote: > Hi, >=20 > I approved the conclusion. >=20 > Regards, > Valery. >=20 >> - The group still thinks this is an important problem that needs an inte= roperable solution. >> - We would like to abandon the work on IKE-over-TCP. >> - And to work on IKEv2 protocol-level fragmentation, using draft-smyslov= -ipsecme-ikev2-fragmentation as a starting point. >> Please send your approval, disapproval or comments to the list within a = week (until May 23). >=20 From bew@cisco.com Thu May 16 16:55: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 7C3D011E80A3 for ; Thu, 16 May 2013 16:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij4Sgg0mgdVh for ; Thu, 16 May 2013 16:55:14 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 909B311E80E1 for ; Thu, 16 May 2013 16:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1338; q=dns/txt; s=iport; t=1368748511; x=1369958111; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=SfPKvxdF/ORk97kl7927ekFqUjd8JlAaBWBqSFhofQU=; b=gkvIjBOX6dfZd5kyNe7ICoIH6Ck9sf0voO4DdScn9uPcOzStfdFl1xy1 2NqXGgV98mzAOtzvakc4xIX28GPkTTlZLEbusHLPMiW/ht5QNABQzXjv5 +JUphb6zSpONhYqaMWhRX8vfVLaGc2r2Bog6NcKm1o011KZfbeU6cjmzW w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAHJxlVGrRDoG/2dsb2JhbABbgwjCBnsWdIIfAQEBAwE6NAsFCwtGITYGExuHXwMJBQGzXQ2IXoxIgiQzB4J0YQOJH4wzgWaMHYUjgzA X-IronPort-AV: E=Sophos;i="4.87,687,1363132800"; d="scan'208";a="81337762" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 16 May 2013 23:54:52 +0000 Received: from dhcp-128-107-147-78.cisco.com (dhcp-128-107-147-78.cisco.com [128.107.147.78]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4GNsp3u014964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 May 2013 23:54:51 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Brian Weis In-Reply-To: <51950FF7.1050707@gmail.com> Date: Thu, 16 May 2013 16:54:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51950FF7.1050707@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1503) Cc: IPsecme WG Subject: Re: [IPsec] IPsecME virtual meeting minutes, and way forward with 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: Thu, 16 May 2013 23:55:19 -0000 On May 16, 2013, at 9:57 AM, Yaron Sheffer = wrote: > Hi, >=20 > As promised, we just had a virtual interim meeting to discuss IKEv2 = fragmentation. Please see the minutes below (thanks Paul!). >=20 > Following up on this meeting, we would like to confirm the decision on = the mailing list: >=20 > - The group still thinks this is an important problem that needs an = interoperable solution. > - We would like to abandon the work on IKE-over-TCP. > - And to work on IKEv2 protocol-level fragmentation, using = draft-smyslov-ipsecme-ikev2-fragmentation as a starting point. >=20 > Please send your approval, disapproval or comments to the list within = a week (until May 23). I approve. [snip] > Yaron: do we want to stay with the current TCP-based solution? > Brian: might be running on sensors that don't have a TCP stack Someone made this comment, but it wasn't me.=20 I did mention that the current TCP-based solution has the advantage of = only re-sending the missing TCP segment, whereas current and proposed = UDP-based fragmentation solutions re-send all packet fragments. That = could be valuable for a VPN gateway with many peers with a lossy = network. But that doesn't seem enough of a justification to stay with = the current TCP-based solution. Brian= From ynir@checkpoint.com Fri May 17 01:08: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 BF8A821F8551 for ; Fri, 17 May 2013 01:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.339 X-Spam-Level: X-Spam-Status: No, score=-10.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 Yf+wK9UaX1Pn for ; Fri, 17 May 2013 01:08:39 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9203C21F843E for ; Fri, 17 May 2013 01:08:38 -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 r4H88YY6030627; Fri, 17 May 2013 11:08:34 +0300 X-CheckPoint: {5195E377-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Fri, 17 May 2013 11:08:33 +0300 From: Yoav Nir To: Brian Weis Thread-Topic: [IPsec] IPsecME virtual meeting minutes, and way forward with fragmentation Thread-Index: AQHOUlZ7rCucu8Gu7Ua/fs0xyuHbH5kISoqAgACJ9YA= Date: Fri, 17 May 2013 08:08:33 +0000 Message-ID: References: <51950FF7.1050707@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.103] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11dedda4303b2aeda4a7789c41b5053428ec1fb0c3 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] IPsecME virtual meeting minutes, and way forward with 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, 17 May 2013 08:08:44 -0000 On May 17, 2013, at 2:54 AM, Brian Weis wrote: >=20 > [snip] >=20 >> Yaron: do we want to stay with the current TCP-based solution? >> Brian: might be running on sensors that don't have a TCP stack >=20 > Someone made this comment, but it wasn't me.=20 That was Daniel. Yoav From mglt.ietf@gmail.com Fri May 17 01:46: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 EC5ED21F93C4 for ; Fri, 17 May 2013 01:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=2.658, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 za8eQ4dijflu for ; Fri, 17 May 2013 01:46:17 -0700 (PDT) Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2641A21F9347 for ; Fri, 17 May 2013 01:46:17 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 07DE85D88F4 for ; Fri, 17 May 2013 10:46:16 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.orange.com (Postfix) with ESMTP id F3A0A5D88F2 for ; Fri, 17 May 2013 10:46:15 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 May 2013 10:46:15 +0200 Received: from [10.193.169.114] ([10.193.169.114]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 May 2013 10:46:15 +0200 Message-ID: <5195EE37.5080709@gmail.com> Date: Fri, 17 May 2013 10:45:43 +0200 From: daniel migault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: ipsec@ietf.org References: <51950FF7.1050707@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2013 08:46:15.0691 (UTC) FILETIME=[FDEE15B0:01CE52DA] Subject: Re: [IPsec] IPsecME virtual meeting minutes, and way forward with fragmentation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mglt.ietf@gmail.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 08:46:22 -0000 yes, that was me. Daniel On 05/17/2013 10:08 AM, Yoav Nir wrote: > On May 17, 2013, at 2:54 AM, Brian Weis wrote: >> [snip] >> >>> Yaron: do we want to stay with the current TCP-based solution? >>> Brian: might be running on sensors that don't have a TCP stack >> Someone made this comment, but it wasn't me. > That was Daniel. > > Yoav > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From rsj@cisco.com Sat May 18 20:05: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 7CE7121F8C98 for ; Sat, 18 May 2013 20:05:37 -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 NcUA+yYJGQty for ; Sat, 18 May 2013 20:05:32 -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 7CBD821F8C38 for ; Sat, 18 May 2013 20:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1781; q=dns/txt; s=iport; t=1368932732; x=1370142332; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Hmi0ct59A9jfcQ5lv+yOh2BUCA5T4q/lCes9SJzzFA0=; b=meK3nga3t38v79NO3sCLND+o8WZQgeZAomTgyTmY/x+zYhrlTXkp7TL9 KX0Npkb+ysWqlnf3GQIuaLa+HtQOZYCLD97LfuRXzJyrTAXqq4n6u0CBo JgQw3UYkBx0TwFF6zZI9vQy31/CM504cSGAsM18zseljPsH2+naGyitpC U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAFhAmFGtJXG//2dsb2JhbABbgwgwwTp/FnSCHwEBAQMBAQEBNzQLBQcEAgEIEQQBAQsUCQchBgsUCQgCBAENBQgTh2ADCQYMs0ENiGoEjEqCJjEHBoJtYQOVUo4DhSODD4Im X-IronPort-AV: E=Sophos;i="4.87,702,1363132800"; d="scan'208";a="212209486" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 19 May 2013 03:05:31 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4J35VrC023896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 May 2013 03:05:31 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.189]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Sat, 18 May 2013 22:05:31 -0500 From: "Rajeshwar Singh Jenwar (rsj)" To: "Brian Weis (bew)" , Yaron Sheffer Thread-Topic: [IPsec] IPsecME virtual meeting minutes, and way forward with fragmentation Thread-Index: AQHOUlZ47d1B+ONwHEa/LihAWRnsr5kI0KeAgAMGEmA= Date: Sun, 19 May 2013 03:05:31 +0000 Message-ID: References: <51950FF7.1050707@gmail.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.67.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] IPsecME virtual meeting minutes, and way forward with 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: Sun, 19 May 2013 03:05:37 -0000 +1 Kind Regards, Raj -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of B= rian Weis (bew) Sent: Friday, May 17, 2013 5:25 AM To: Yaron Sheffer Cc: IPsecme WG Subject: Re: [IPsec] IPsecME virtual meeting minutes, and way forward with = fragmentation On May 16, 2013, at 9:57 AM, Yaron Sheffer wrote: > Hi, >=20 > As promised, we just had a virtual interim meeting to discuss IKEv2 fragm= entation. Please see the minutes below (thanks Paul!). >=20 > Following up on this meeting, we would like to confirm the decision on th= e mailing list: >=20 > - The group still thinks this is an important problem that needs an inter= operable solution. > - We would like to abandon the work on IKE-over-TCP. > - And to work on IKEv2 protocol-level fragmentation, using draft-smyslov-= ipsecme-ikev2-fragmentation as a starting point. >=20 > Please send your approval, disapproval or comments to the list within a w= eek (until May 23). I approve. [snip] > Yaron: do we want to stay with the current TCP-based solution? > Brian: might be running on sensors that don't have a TCP stack Someone made this comment, but it wasn't me.=20 I did mention that the current TCP-based solution has the advantage of only= re-sending the missing TCP segment, whereas current and proposed UDP-based= fragmentation solutions re-send all packet fragments. That could be valuab= le for a VPN gateway with many peers with a lossy network. But that doesn't= seem enough of a justification to stay with the current TCP-based solution= . Brian _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Mon May 20 18:27: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 1CFC021F9512 for ; Mon, 20 May 2013 18:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 sTRcvKE37QXW for ; Mon, 20 May 2013 18:27:50 -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 95AC921F93FC for ; Mon, 20 May 2013 18:27:50 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r4L1Rj6i055925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 May 2013 18:27:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <517FDAC7.8080701@ieca.com> Date: Mon, 20 May 2013 18:27:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <517FDAC7.8080701@ieca.com> To: "draft-ietf-ipsecme-ad-vpn-problem@tools.ietf.org" X-Mailer: Apple Mail (2.1503) Cc: IPsecme WG , Sean Turner Subject: Re: [IPsec] AD re-review of draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 01:27:51 -0000 Document authors: when might we have the update so Sean can move this = forwards? We are gated on this before we solicit AD-VPN protocols. --Paul Hoffman On Apr 30, 2013, at 7:52 AM, Sean Turner wrote: > Please incorporate the QoS issue brought up by Toby. I'd like to make = sure we have everything in the draft that the WG wants before issuing = the WGLC. I also think the TSV/RTG directorates/ADs will be interested = in that. >=20 > Can you explain the rationale for the following the changes to = requirement #5; I'm just not following it: >=20 > OLD: >=20 > 5. One ADVPN peer MUST NOT be able to impersonate another ADVPN = peer. >=20 > NEW: >=20 > 5. Any of the ADVPN Peers MUST NOT have a way to get the long term > authentication credentials for any other ADVPN Peers. The compromise = of an Endpoint MUST NOT affect the security of communications between = other ADVPN Peers. The compromise of a Gateway SHOULD NOT affect the = security of the communications between ADVPN Peers not associated with = that Gateway. >=20 > Is the first sentence still saying basically: "peers can't impersonate = peers"? >=20 > Nits: >=20 > - sec 1.1: Need to add what an ADVPN is and expand the acronym >=20 > - sec 4/1.1: The terms allied and federated environment kind of come = out of nowhere. Please add them to s1.1. I just to make sure it's = clear what the difference is between the two. From vishwas.ietf@gmail.com Tue May 21 19:09: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 2800C21F8ACD for ; Tue, 21 May 2013 19:09:59 -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, 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 fsmIDbqYCAW7 for ; Tue, 21 May 2013 19:09:58 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6EB21F896B for ; Tue, 21 May 2013 19:09:58 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c13so3812635ieb.24 for ; Tue, 21 May 2013 19:09:57 -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=jjzt9TITRpPBi1EW4wjO3sEgTmzFHiImryyVSEsvncw=; b=LmLGUy6VBuBzpYlRrswOxty6EW3PeIPvyBmT/DVwC8AooRMN2kJhSKgZkyWEzU+M7Y lWzxlqEmglI8X1x8bWrXdNjd4IH3zKeBOVUk49CloIg75lHzE1TfV6TymGYpjvtOxaYa dAG7tB5tnPBNfHshSU4az5zpp+X3gDAj3Fsfh+9lmMXc6CwmuPUYx3HtYjUXwtSrmyGB xPyf17Iju9gVIW8UecuR868HAoEy/Rmr89Nz082NilPw5SY1qU5Elw4lEorDI7t5sK3S SS7PG7kVuP8f4ymnePMdobpzDdFrr0xA20jJ7D08hTuosWOMeELSqh5oyOiBmIO66DtA shmw== MIME-Version: 1.0 X-Received: by 10.50.114.33 with SMTP id jd1mr9745546igb.30.1369188597750; Tue, 21 May 2013 19:09:57 -0700 (PDT) Received: by 10.50.46.170 with HTTP; Tue, 21 May 2013 19:09:57 -0700 (PDT) In-Reply-To: References: <517FDAC7.8080701@ieca.com> Date: Wed, 22 May 2013 07:39:57 +0530 Message-ID: From: Vishwas Manral To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b41418effe73304dd450fc9 Cc: IPsecme WG , "draft-ietf-ipsecme-ad-vpn-problem@tools.ietf.org" , Sean Turner Subject: Re: [IPsec] AD re-review of draft-ietf-ipsecme-ad-vpn-problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 02:09:59 -0000 --047d7b41418effe73304dd450fc9 Content-Type: text/plain; charset=ISO-8859-1 Hi Paul, I will try to get this done around the first week of June. I am currently travelling till the end of the week. Thanks, Vishwas On Tue, May 21, 2013 at 6:57 AM, Paul Hoffman wrote: > Document authors: when might we have the update so Sean can move this > forwards? We are gated on this before we solicit AD-VPN protocols. > > --Paul Hoffman > > On Apr 30, 2013, at 7:52 AM, Sean Turner wrote: > > > Please incorporate the QoS issue brought up by Toby. I'd like to make > sure we have everything in the draft that the WG wants before issuing the > WGLC. I also think the TSV/RTG directorates/ADs will be interested in that. > > > > Can you explain the rationale for the following the changes to > requirement #5; I'm just not following it: > > > > OLD: > > > > 5. One ADVPN peer MUST NOT be able to impersonate another ADVPN > peer. > > > > NEW: > > > > 5. Any of the ADVPN Peers MUST NOT have a way to get the long term > > authentication credentials for any other ADVPN Peers. The compromise of > an Endpoint MUST NOT affect the security of communications between other > ADVPN Peers. The compromise of a Gateway SHOULD NOT affect the security of > the communications between ADVPN Peers not associated with that Gateway. > > > > Is the first sentence still saying basically: "peers can't impersonate > peers"? > > > > Nits: > > > > - sec 1.1: Need to add what an ADVPN is and expand the acronym > > > > - sec 4/1.1: The terms allied and federated environment kind of come out > of nowhere. Please add them to s1.1. I just to make sure it's clear what > the difference is between the two. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --047d7b41418effe73304dd450fc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Paul,
=A0
I will try to get th= is done around the first week of June. I am currently travelling till the e= nd of the week.
=A0
Thanks,
Vishwas


On Tue, May 21, 2013 at 6:57 AM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:
Document authors: when might we have the update so Sean can move this forwa= rds? We are gated on this before we solicit AD-VPN protocols.

--Paul Hoffman

On Apr 30, 2013, at 7:52 AM, Sean Turner <turners@ieca.com> wrote:

> Please incorporate the QoS issue brought up by Toby. =A0I'd like t= o make sure we have everything in the draft that the WG wants before issuin= g the WGLC. =A0I also think the TSV/RTG directorates/ADs will be interested= in that.
>
> Can you explain the rationale for the following the changes to require= ment #5; I'm just not following it:
>
> OLD:
>
> 5. One ADVPN peer MUST NOT be able to impersonate another ADVPN =A0 = =A0 =A0 peer.
>
> NEW:
>
> 5. Any of the ADVPN Peers MUST NOT have a way to get the long term
> authentication credentials for any other ADVPN Peers. The compromise o= f an Endpoint MUST NOT affect the security of communications between other = ADVPN Peers. The compromise of a Gateway SHOULD NOT affect the security of = the communications between ADVPN Peers not associated with that Gateway. >
> Is the first sentence still saying basically: "peers can't im= personate peers"?
>
> Nits:
>
> - sec 1.1: Need to add what an ADVPN is and expand the acronym
>
> - sec 4/1.1: The terms allied and federated environment kind of come o= ut of nowhere. =A0Please add them to s1.1. =A0I just to make sure it's = clear what the difference is between the two.

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

--047d7b41418effe73304dd450fc9--