Re: [IPsec] Comments to draft-ietf-ipsecme-ike-tcp-00.txt

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 04 November 2012 21:02 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921F321F87D6 for <ipsec@ietfa.amsl.com>; Sun, 4 Nov 2012 13:02:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.954
X-Spam-Level:
X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcL5J9cSGphs for <ipsec@ietfa.amsl.com>; Sun, 4 Nov 2012 13:02:30 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 115F521F87D4 for <ipsec@ietf.org>; Sun, 4 Nov 2012 13:02:30 -0800 (PST)
Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id 4EE8681A9 for <ipsec@ietf.org>; Sun, 4 Nov 2012 15:54:27 -0500 (EST)
Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 69B26CA0BC for <ipsec@ietf.org>; Sun, 4 Nov 2012 16:02:29 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: ipsec@ietf.org
In-reply-to: <20630.53020.522052.651631@fireball.kivinen.iki.fi>
References: <20629.51761.388715.484632@fireball.kivinen.iki.fi> <25304.1352050845@sandelman.ca> <20630.53020.522052.651631@fireball.kivinen.iki.fi>
Comments: In-reply-to Tero Kivinen <kivinen@iki.fi> message dated "Sun, 04 Nov 2012 22:25:00 +0200."
X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Sun, 04 Nov 2012 16:02:29 -0500
Message-ID: <32506.1352062949@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-ike-tcp-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <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: Sun, 04 Nov 2012 21:02:33 -0000

Tero Kivinen <kivinen@iki.fi> wrote:
    TK> In addition to the IKE_AUTH there is another big class of UPD
    TK> packets which can be large, and which might get fragmented, i.e
    TK> udp encapsulated nat traversal IPsec UDP packets. If the

    >> I don't think you are suggesting any specific technical change to
    >> support this.  I think that you are saying that we need to be
    >> more clear that we aren't proposing anything here.  And that if
    >> TCP gets used for the AUTH payload, that might be a clue to the
    >> IPsec layer that it should do:

    TK> No, I was just pointing out that IKE_AUTH is not the only packet
    TK> which can be big packets, and UDP encapsulated packets might
    TK> also have problems bypassing the NATs dropping all fragments.

So, the converse statement (for me) is that you think that we should
specify a way to carry ESP over TCP.

    TK> For tunnel mode IPsec traffic, the gateway can fragment inner
    TK> packets before wrapping them to ESP, so the outer ESP packets
    TK> visible to nat box are not fragmented.

    >> which the gateway machine might not otherwise do. But, this can't
    >> be done for IPv6.  (There isn't really any significant downside
    >> to doing this.  If anything, this moves the memory expense of
    >> fragment reassembly from gateways to end nodes.)

    TK> On the other hand I am not sure NAT boxes do drop IPv6
    TK> fragments...  IPv6 and NAT are not used that often together.

IPv6 packets inside ESP over IPv4-ESP-UDP.
This gives your laptop ubiquitous IPv6, even when behind stupid networks.

    >> Yes.  I think that the congestion window argument is probably not
    >> relevant. I don't think the congestion window will open much even
    >> if the first round trip goes through.

    TK> In most systems just opening the TCP session will reserve 32 kB
    TK> buffers for sending and receiving immediately when you open tcp
    TK> connection. Earlier that was one of the parameters you needed to
    TK> tune down for web servers if you wanted to support lots of
    TK> clients.  

yeah, but the concern listed in the document is that the initial
congestion window wouldn't be big enough to quickly send out the large
IKE_AUTH payload.   Having at least one RTT for the initial IKE_INIT
exchange would allow TCP to double the window, and get an estimate for
RTT.

-- 
Michael Richardson
-on the road-