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

Vishwas Manral <> Thu, 13 December 2012 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81FC621F8B01 for <>; Thu, 13 Dec 2012 09:54:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.818
X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rJ6iZZf+7-iN for <>; Thu, 13 Dec 2012 09:54:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4769021F8533 for <>; Thu, 13 Dec 2012 09:54:16 -0800 (PST)
Received: by with SMTP id i20so3310460qad.10 for <>; Thu, 13 Dec 2012 09:54:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hG4llqoi2etokspeMZyKznEdjoxzkZqvXbiCe0SNUrQ=; b=xW284hUlky92utirEIQ4vcGnN7c6wL91S3KuDs9U0DVlEtQYXYkT6N7ZP6Pn2saalI IpC2DtM+j4L2afUtja/ETZh63wFqFDCQrqBQGw53IbRf+Wi+sfx2zE+pwEHHbaKPDvjZ eVLwbDaLHfbFixy3dup05lBFnOkQc9Nr80voV8MfAwxYNR5skV4/aVMiB9VHYSDQRhkR GImVDk+O59M+RnATpxQ9VUW3ekA75CQKQxdknzFj7HolE44EyRRU7YhLfklx9j9MPU83 QNRuxc2MjlA2KUj/TKRFWb1OoxVqNrKCzgsFTLLyYbyCbLn6CYabFqX3wt89fFmzE9bz i6ag==
MIME-Version: 1.0
Received: by with SMTP id br13mr803666qab.37.1355421249388; Thu, 13 Dec 2012 09:54:09 -0800 (PST)
Received: by with HTTP; Thu, 13 Dec 2012 09:54:09 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Thu, 13 Dec 2012 09:54:09 -0800
Message-ID: <>
From: Vishwas Manral <>
To: Brian Weis <>
Content-Type: multipart/alternative; boundary="485b397dcd5b17413804d0bf9a39"
Cc: "" <>,, Stephen Hanna <>
Subject: Re: [IPsec] Comments on proposed draft-ietf-ipsecme-ad-vpn-problem-02
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Dec 2012 17:54:17 -0000

Hi Brian,

Thanks a lot for your comments and sorry I did not reply immediately. I
have still been waiting for the version 2 to upload. I have sent it to the address.

My comments are inline and will be updated in version 03. We could do it in
version 02 too if it does not get posted soon enough. The only issue I have
is with the L3VPN comment and would want Lou Berger's opinion on it, as he
thought the text would add value there (though if you see previous comments
I am more of the opinion similar to yours).

On Tue, Dec 11, 2012 at 12:30 PM, Brian Weis <> wrote:

> 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.
Changed the MUST to a SHOULD.

> 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.
VM> Updated.

> 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?
VM> No I did not add any extra text for L3VPN besides this one. The idea
was that if IPsec over GRE as PE to PE communication tunnels the ADVPN
technology should not preclude such a solution.Like I have said earlier I
do not have strong opinion regarding this requirement. Lou thought this
should be there and I asked the list if there were objections to this, and
I did not hear anyone object, so I added it.

Lets try to hear from Lou on this.

> 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/
VM> Updated.


> Thanks,
> Brian
> _______________________________________________
> IPsec mailing list