[IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02

Brian Weis <bew@cisco.com> Tue, 11 December 2012 20:39 UTC

Return-Path: <bew@cisco.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3639511E809B for <ipsec@ietfa.amsl.com>; Tue, 11 Dec 2012 12:39:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.399
X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ARp2dBR1dUkR for <ipsec@ietfa.amsl.com>; Tue, 11 Dec 2012 12:39:02 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6CEA311E8097 for <ipsec@ietf.org>; Tue, 11 Dec 2012 12:39:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2459; q=dns/txt; s=iport; t=1355258342; x=1356467942; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=bklYj4e+W+AQ+r1kSU1gfkudnITWnYfapNmPVltv0BA=; b=DsDjfC9owdIwAcGkkG51XUc08QjdzoBSVOcNxGVkjAaY0nMAsYde015D BmFtaGBPi8ZxTwnqrBak6D28G72K3QHXJAPX3uFzLumT2Vz3RQQp/9y+G AWDVoT2um+THMEBMiKRoVIIncni3KvAapXEeDv0vyT/q4F4jMH40pv8cy U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ao8HAC6Yx1CrRDoG/2dsb2JhbABFg0i7BhZzgl8/KYEVAS2HdasukFKQLGEDiGCNJ5BIgxQ
X-IronPort-AV: E=McAfee;i="5400,1158,6923"; a="63197224"
Received: from mtv-core-1.cisco.com ([]) by mtv-iport-1.cisco.com with ESMTP; 11 Dec 2012 20:39:01 +0000
Received: from sjc-vpn5-90.cisco.com (sjc-vpn5-90.cisco.com []) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBBKcrbZ018702 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Dec 2012 20:39:01 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 11 Dec 2012 12:30:56 -0800
Message-Id: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com>
To: Stephen Hanna <shanna@juniper.net>, "vishwas.manral@hp.com" <vishwas.manral@hp.com>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Cc: ipsec@ietf.org
Subject: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02
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: Tue, 11 Dec 2012 20:39:03 -0000

Hi Steve & Vishwas,

Here are a couple of comments on the proposed -02 sent a few days ago.

Requirement 1 says "gateways and endpoints MUST minimize configuration changes when a new gateway or endpoint is added, removed or changed." While I certainly agree with the sentiment behind the requirement, this statement is about as strong as "gateways and endpoints MUST perform well", or "gateways and endpoints MUST be easy to use". In other words, it isn't a testable assertion that can be evaluated. Also the body of the document says "it is desired that there be minimal configuration on each gateway", which does not support a MUST requirement. This ought to be a SHOULD rather than a MUST.

Requirement 8 has gone through several versions, but I think it could still be made clearer. It first requires Gateways and endpoints "to work when they are behind NAT boxes", and then makes a bunch of necessary exceptions. The following replacement text attempts to make the same points as the original but might be clearer:

   8.  Gateways and endpoints MUST have the capability to participate 
   in an AD VPN even when they are located behind NAT boxes. However, 
   in some cases they may be deployed in such a way that they will not be 
   fully reachable behind a NAT box.  It is especially difficult 
   to handle cases where the Hub is behind a NAT box.  Where the
   two endpoints are both behind separate NATs, communication between
   these spokes SHOULD be supported using workarounds
   such as port forwarding by the NAT or detecting when two spokes
   are behind uncooperative NATs and using a hub in that case. 

Requirement 14 says "The ADVPN solution MUST support Provider Edge (PE) based VPN's". This requirement seems unfair to the end point use cases in 2.1 and 2.3, or even gateway-to-gateway ADVPN solutions that have nothing to do with L3VPNs! I think you're trying to say it must be possible to build an ADVPN solution that meets the requirements of L3VPN, which I have no problem with but I don't think think this it's a fair requirement to put in Section 4. Is there anything beyond the new text you added in 2.2 regarding L3VPN that needs to be said?

There's a couple remaining nits:

Section 2.2: s/A fully meshed solution is would/A fully meshed solution would/
Section 4: s/This sectiondefines/This section defines/