Re: [renum] Working Group Last Call: draft-ietf-6renum-gap-analysis-03.txt

Shane Amante <shane@castlepoint.net> Wed, 19 September 2012 19:11 UTC

Return-Path: <shane@castlepoint.net>
X-Original-To: renum@ietfa.amsl.com
Delivered-To: renum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B60A21E80A5 for <renum@ietfa.amsl.com>; Wed, 19 Sep 2012 12:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 ymusyUoUL6eB for <renum@ietfa.amsl.com>; Wed, 19 Sep 2012 12:11:17 -0700 (PDT)
Received: from mail.tcb.net (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2BE11E8091 for <renum@ietf.org>; Wed, 19 Sep 2012 12:11:17 -0700 (PDT)
Received: from mbpw.castlepoint.net (216-160-173-224.hlrn.qwest.net [216.160.173.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.tcb.net (Postfix) with ESMTPSA id AD1835DA; Wed, 19 Sep 2012 13:11:15 -0600 (MDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <C89AB8B8-78B6-4482-9E34-5DE04B6C537D@gmail.com>
Date: Wed, 19 Sep 2012 13:11:17 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <D0BA0A91-4334-49FF-B6DB-AB63FA90A508@castlepoint.net>
References: <C89AB8B8-78B6-4482-9E34-5DE04B6C537D@gmail.com>
To: RJ Atkinson <rja.lists@gmail.com>
X-Mailer: Apple Mail (2.1486)
Cc: renum@ietf.org
Subject: Re: [renum] Working Group Last Call: draft-ietf-6renum-gap-analysis-03.txt
X-BeenThere: renum@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Renumbering discussion mailing list." <renum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/renum>, <mailto:renum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/renum>
List-Post: <mailto:renum@ietf.org>
List-Help: <mailto:renum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/renum>, <mailto:renum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Sep 2012 19:11:18 -0000

Ran, Brian,

On Sep 19, 2012, at 12:39 PM, RJ Atkinson <rja.lists@gmail.com> wrote:
>>> Earlier, Marc Lampo wrote:
>>> One element is that in practice, not all devices "out there"
>>> (some very widely used) are not capable of defining the
>>> valid addresses on an IPSEC endpoint via DNS.
> 
> (With a confused look on my face)
> 
> I'm aware of numerous IPsec devices that do support
> the use of FQDNs, in addition to IP addresses, as
> IPsec SA endpoint identifiers.  Multiple products 
> (e.g. from Cisco, from Juniper [both JunOS and also
> ex-Netscreen products running ScreenOS], and 
> other products from many suppliers) support this
> -- and have done for many many years now.

I agree.  In fact, I remember configuring FQDN's, as IPsec SA endpoint ID's, in Netscreen devices (ScreenOS) as far back as the 2000-2001 timeframe.  I seem to recall Checkpoint FW-1 supporting a similar capability in that timeframe, as well.  Anyway, just more data points from my past experience to substantiate what Ran said above.

I'll echo what Ran said below:
> An example of a "very widely used" IPsec implementation
> that can't do this would be informative, to me at least, 
> if not on-list, then perhaps in a quick unicast email.


-shane


> In fact, I'm not aware of any IKEv1 or IKEv2 
> implementations that lack this, since it was 
> in the very very early specifications for ISAKMP/IKE.
> 
> However, in many cases, users don't seem to realise that 
> the capability exists, which is partly why the capability
> was noted in RFC-5887 and is repeated here.  
> 
> 
> Later, Brian Carpenter wrote:
>> True, that's an implementation and deployment gap,
>> not a protocol gap.  All we can do in the IETF is document
>> this kind of gap, since we don't control implementations.
> 
> Agreed.  To the extent that some IPsec implementation(s)
> d(oes)n't comply with long-standing (well over a decade old)
> IETF specs, that issue is outside the scope of an IETF WG.
> 
> However, the best information I have, and I've done some
> online checks today (without figuring out which item
> Marc is referring to), is that this capability is widely
> implemented and available -- albeit not so widely deployed.
> 
>> Nothing works if people don't use the global DNS correctly, ...
> 
> 
> Agreed.
> 
> 
> Yours,
> 
> Ran
> 
> _______________________________________________
> renum mailing list
> renum@ietf.org
> https://www.ietf.org/mailman/listinfo/renum
>