Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Mon, 08 May 2017 12:49 UTC

Return-Path: <ietf@kuehlewind.net>
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 36698129461 for <ipsec@ietfa.amsl.com>; Mon, 8 May 2017 05:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 ewaGA7wpcoHY for <ipsec@ietfa.amsl.com>; Mon, 8 May 2017 05:49:40 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09AF12945E for <ipsec@ietf.org>; Mon, 8 May 2017 05:49:39 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=cO8q+aC0LZDr/SWbOu8rRTQxQV0WdlxrBcxhBwEShDClgBPKN8m4KjORMlzUpR3W+ME5FuVmypIJy0Z+qcXDXknxno3yvyloeywJ7TkmEVO/hM4r2tqcIcErfGX8LnssKfigGqNHy0JlBXbza3WkIwExO2GxJYjExwZltAx0lcs=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 31846 invoked from network); 8 May 2017 14:49:38 +0200
Received: from p5dec259c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.37.156) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 8 May 2017 14:49:38 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <CABcZeBPz0BN5643j9QHQx-5LfxXLbTGj2XmUrOfkU7PsHpcZcg@mail.gmail.com>
Date: Mon, 08 May 2017 14:49:36 +0200
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, IESG <iesg@ietf.org>, ipsecme-chairs@ietf.org, Tommy Pauly <tpauly@apple.com>, draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen <kivinen@iki.fi>, IPsecME WG <ipsec@ietf.org>, Mark Nottingham <mnot@mnot.net>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F1859DB7-AB24-49DA-A5B1-AAE74201368A@kuehlewind.net>
References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <CABcZeBMj9UpzD+CpvOMKOkUsYNSL-UQCwuYt__5XCXtH=zyesA@mail.gmail.com> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <CAKKJt-fb1vx=SzpJ_9gvtJ+SEH08nyBRGqb7F36PGw0EyJ6zmA@mail.gmail.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> <22792.31378.769444.232365@fireball.acr.fi> <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net> <22793.40707.624092.66793@fireball.acr.fi> <c0fad3b5-54b1-a347-0ea1-bec24dab0e36@kuehlewind.net> <CAKKJt-ceDuYKWGBFb6RKc8K_AcB55doOXMf11Ke807f6kc+UFA@mail.gmail.com> <CABcZeBPz0BN5643j9QHQx-5LfxXLbTGj2XmUrOfkU7PsHpcZcg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20170508124938.31834.92503@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/5uDw2aWGtMkCcd6IngcLaNLiyqY>
Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)
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: Mon, 08 May 2017 12:49:41 -0000

Does the proposed text changes from Tommy still refer to 443 anywhere (lost track a bit but I guess the appendix still does right)?

Again I think we should talk about using 443 if that’s what’s done in reality. However my understanding is that real-life implementation use TCP/TLS which I think could be discussed in the body rather than the appendix.

And I would like to see a recommendation that HTTPS and TCPIKE should not be multiplexed the same time on the same port. My understanding from Tero’s feedback was that this is usually not done today and probably not necessary in future.

Mirja


> Am 05.05.2017 um 23:13 schrieb Eric Rescorla <ekr@rtfm.com>:
> 
> It seems like most of the issues are resolved here, except for that of muxing
> IKE and non-IKE protocols on the same port (especially 443). My understanding
> is that (although we may not like it) it's nevertheless a common practice, and
> yet we can't levy the requirement that no other protocol start with IKETCP<whatever>,
> so it seems like what we need is a warning note and potentially a request to reserve
> this string for some set of common protocols (HTTP,...?).
> 
> Mirja, would that work for you?
> 
> -Ekr
> 
> 
> On Wed, May 3, 2017 at 6:11 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> 
> On May 3, 2017 05:54, "Mirja Kühlewind" <ietf@kuehlewind.net> wrote:
> I didn't propose to obsolete RFC3947 in this document. I guess you can also file an error for this if you don't want to take any further actions. However, for updating the IANA registry, I would say the right action is to do this simply by IESG approval for UDP then.
> 
> Fwiw, that would work for me.
> 
> Spencer
> 
> 
> 
> Mirja
> 
> 
> 
> On 03.05.2017 11:12, Tero Kivinen wrote:
> Mirja Kuehlewind (IETF) writes:
> my thinking was that the main problem is that 3947 was not obsoleted
> and I’m assuming we need a document to fix that.
> 
> This is partly issue, but it is not issue we need to solve here, as
> this document is not something that should obsolete 3947.
> 
> Also 3947 only defines extension for the IKEv1 (RFC2409) and that is
> already obsoleted, so effectively RFC3947 is already obsoleted, as
> there is no way to implement 3947 without implementing obsoleted
> protocol...
> 
> This issue is not not important enough to require RFC now.
> 
> In this case that document could/should also fix the IANA entry for
> the UDP port. However, I’m actually not sure what the right
> processing would be to fix this forgotten obsolete… maybe other ADs
> know better…?
> 
> For now I would just leave it as it is, but fix the references in the
> IANA registry so that document will not be referenced, especially as
> the original IANA reference was not to the correct RFC in the first
> place.
> 
> Otherwise if you don’t want to do this, I don’t think it’s a good
> idea to merge kind of unrelated fixes into this spec. We can also
> fix that by using the IESG approval process (see RFC5226). I think
> that’s the better option!
> 
> That is true, but as this document already modifies the TCP/4500
> reference, fixing the UDP/4500 reference at the same time is not
> completely unrelated fix.
> 
> Obsoleting RFC3947 would be unrelated fix.
> 
> 
>