IETF Logo Mail Archive

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

Yoav Nir <ynir.ietf@gmail.com> Sun, 19 March 2017 10:14 UTC

Return-Path: <ynir.ietf@gmail.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 393051243FE; Sun, 19 Mar 2017 03:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mHHLm6G1fJh; Sun, 19 Mar 2017 03:14:07 -0700 (PDT)
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5581201FA; Sun, 19 Mar 2017 03:14:06 -0700 (PDT)
Received: by mail-wm0-x243.google.com with SMTP id n11so9765748wma.0; Sun, 19 Mar 2017 03:14:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=RcoQljSoithy3raDZdbe7hH2a5HATd8ezo6R2t5SmZc=; b=Y1L+vCzuiEzJmCpldql2qqw90NuJTq0nJFh6bKUg+NVxADpJw09r7AYIMJtNCEXYuw aBPJYJSdUJt70bHIIz01pvscLjFz1dYpYIQxTtEkerg8ZdW/6yvGuWpzrK68BJhj8A+S e15V4pgX6wmJMMUARFubtcJVsClhDVMvV9UQIqh5jAGt9B5TEC/lErvTHuLfquVO/Zpc JLxRg/q385qyuO5YToDwdLhlYEvhqT3L9h/+ppNR9BHb47AQvMb37SmdCagdeldKvib0 VEOplNXg/FaajUGXRkn8qetZU18ADjWMmMJbXbr+3+Do9/h5lFsl6YjAmJ+218/oRvK6 pDdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=RcoQljSoithy3raDZdbe7hH2a5HATd8ezo6R2t5SmZc=; b=QMfwIxLqnWcfQGgp2t77nW7DZTscBd4o9AM91pvUz4e37uabeA4kjcLJwCA/uXhQR8 FGDjEBLOYMr6oJOvp9oxYjMu1ZXCXOgKOgn7LL+Zbp8bCvE2CpUAkl3ePyv/2grGs2AL zTNP5LDQxhzsQpa3ri1THCU5dZbPFSk6gi50Da0tXRkh2HNNGMR63Ug3JrqPC80G5lxP 50Y9/zaQ93wb0RYYlKwhApW8cfb7UbqAHvjxCJRq0RsiBH//bwCqRcb88RXADKrcgVK0 y24qEDQksHyEAqdgjvQ9RnraD28KfG1NZl/9nAZ2Oa0xgAthZ36b+a/DvrKsM2eBtUwy tQ8w==
X-Gm-Message-State: AFeK/H2vtkXQnnrHDrpywfw/KEZA48VTtjRWy9y0f+S/Fgxy0PqB9QfloZ+q8PlSBoUUjQ==
X-Received: by 10.28.92.65 with SMTP id q62mr949458wmb.139.1489918445456; Sun, 19 Mar 2017 03:14:05 -0700 (PDT)
Received: from [172.24.249.245] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id g43sm11240253wrg.35.2017.03.19.03.14.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Mar 2017 03:14:04 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_E83594FA-F9D8-40CB-970A-FA5C1B0149B6"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Yoav Nir <ynir.ietf@gmail.com>
X-Priority: 3
In-Reply-To: <621CA73A71744D9AAA226100AE915285@chichi>
Date: Sun, 19 Mar 2017 12:14:01 +0200
Cc: Eric Rescorla <ekr@rtfm.com>, draft-ietf-ipsecme-tcp-encaps@ietf.org, ipsec@ietf.org
Message-Id: <2D2EA57F-EAF0-4C8C-87D7-FB1938C3CD22@gmail.com>
References: <CABcZeBPMR9m8zPdhG4Bc3DHWj9UmVq22Z7G4ApYjBGJeC7MU=A@mail.gmail.com> <621CA73A71744D9AAA226100AE915285@chichi>
To: Valery Smyslov <svanru@gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/vQ1hYUUz6ftDZP_JObJumvB9E3M>
Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 19 Mar 2017 10:14:09 -0000

Hi Valery.

> On 19 Mar 2017, at 11:24, Valery Smyslov <svanru@gmail.com> wrote:
> 
> Hi Eric,
> 
>> - It seems like IKE associations can span TCP connections (S 6)
>>  so why not instead of doing UDP first then TCP, do happy eyeballs.
> 
> I don't think it's a good idea. The TCP encapsulation has a lot of drawbacks in terms of performance (see Section 12), so it is considered
> as a last resort if UDP doesn't work. In general UDP (or no encapsulation) is a preferred transport. If we start trying TCP and UDP in parallel, then
> in some cases TCP will win even if UDP works, resulting in non-efficient connection, even when UDP could be used.

So as I said before, we do it, although IIRC (I’m not on the client team) the client gives TCP a one-second head start. The reason is that in many places where a UDP packet can go, a fragmented UDP packet gets dropped, so the first packets will work fine but the packets with the certificates (either IKE_AUTH or Main Mode #5) will get dropped.

In by the end of IKE we have determined that UDP also works, we move to that for IPsec. And if TCP is blocked, we will try the IKE negotiation on UDP.

Note that we do all that only for remote access VPN. Site-to-site VPN is ESP or UDP only.  There’s just a lot of crappy routers out there.

Yoav

v2.23.0 | Report a Bug | By Email