Re: [IPsec] IPsecME virtual interim meeting (revised date)

Yoav Nir <ynir@checkpoint.com> Tue, 07 May 2013 13:00 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: ipsec@ietfa.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 <ipsec@ietfa.amsl.com>; 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 <ipsec@ietfa.amsl.com>; 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 <ipsec@ietf.org>; 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 <ynir@checkpoint.com>
To: Valery Smyslov <svanru@gmail.com>
Thread-Topic: [IPsec] IPsecME virtual interim meeting (revised date)
Thread-Index: AQHORam5ZxuxdS9gCkedkzry4uPQm5j5tSZ7///Sw4A=
Date: Tue, 07 May 2013 12:59:53 +0000
Message-ID: <F4E83D4E-8166-412B-9694-F40034DB55A5@checkpoint.com>
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 <ipsec@ietf.org>
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 <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=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, 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.

 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 fragments, 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 <svanru@gmail.com> wrote:

> 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.
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Email secured by Check Point