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

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Tue, 02 May 2017 13:31 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 7D5A8131580 for <ipsec@ietfa.amsl.com>; Tue, 2 May 2017 06:31:52 -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=unavailable 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 y-3KIMqNmqsp for <ipsec@ietfa.amsl.com>; Tue, 2 May 2017 06:31:51 -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 02200131569 for <ipsec@ietf.org>; Tue, 2 May 2017 06:27:26 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=YxxlLT6ng8OckeXiQ3vGPduLyoCvaWja7j0E1+4JC6bUcuKGKp2REXLa9OG5gKA+3oifi1UnSsXr4TOUTqfhWgXoYvg5PkvgkXeWY7Wpyow9WnwC5ELa/PbuIjYLPd5SLJHvTlP2219p8cOA90Opx4KQpkoEBTcyJZENYctgofA=; 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 15387 invoked from network); 2 May 2017 15:27:25 +0200
Received: from p5dec2bdc.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.43.220) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 2 May 2017 15:27:25 +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: <22792.31378.769444.232365@fireball.acr.fi>
Date: Tue, 02 May 2017 15:27:23 +0200
Cc: ipsecme-chairs@ietf.org, Eric Rescorla <ekr@rtfm.com>, IPsecME WG <ipsec@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly <tpauly@apple.com>, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <78A72CF3-E011-4E8D-9F66-63C7918A8236@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>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20170502132725.15376.51347@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/B9lr1mKkZF7Fk7d8YkOqeoWXXTw>
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: Tue, 02 May 2017 13:31:52 -0000

Hi Tero,

my thinking was that the main problem is that 3947 was not obsoleted and I’m assuming we need a document to fix that. 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…?

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!

Mirja



> Am 02.05.2017 um 14:24 schrieb Tero Kivinen <kivinen@iki.fi>:
> 
> Mirja Kuehlewind (IETF) writes:
>> so first updating is a request to IANA, so you have to remove the
>> first sentence.
> 
> Agreed, forgot to remove that. 
> 
>> Then the update of the UPD port should probably be done in a
>> separate document that potentially also obsoletes 3947 if that was
>> missed with 7296.
> 
> No point of doing that. Publishing 1 page document doing IANA updates
> is just stupid and does not help anybody. If it cannot be done here,
> we can leave it as it is now, and I talk to IANA and change this thing
> separately. As this is clearly a error in the IANA registry, they have
> fixed this kind of mistakes before without any need for documents
> especially when registry is not RFC required or similar. They do like
> to get document requests just for keeping track of changes, and thats
> why I think it would be better to combine the changes in this
> document, as we are going to change the TCP/4500 anyways, and fixing
> the UDP/4500 references at the same time would be easy.
> 
> And yes, RFC7296 did forget to obsolete RFC3947, but this is not the
> document do that, and thats why I did not suggest this to do anything
> like that. I suggested just fixing the reference from the RFC3947 to
> RFC3948, as RFC3948 actually describes the protocol used over the port
> 4500. RFC3947 does not specify the protocol for port UDP/4500, it just
> refers to the RFC3948 for protocol details. Adding RFC7296 would be
> good, as it provides latest information about the IKE interactions for
> the RFC3948 (i.e., 7296 still uses 3948 defined protocol, but replaces
> the non port 4500 related details which were in the 3947). This is
> just to make sure the people reading the RFC3948 also gets pointer to
> the IKE parts of the protocol (as RFC4306/5996/7296 forgot to obsolete
> 3947). 
> -- 
> kivinen@iki.fi
>