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

Brian Weis <bew@cisco.com> Mon, 17 December 2012 18:43 UTC

Return-Path: <bew@cisco.com>
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 3327721F8B77 for <ipsec@ietfa.amsl.com>; Mon, 17 Dec 2012 10:43:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.827
X-Spam-Level:
X-Spam-Status: No, score=-109.827 tagged_above=-999 required=5 tests=[AWL=-0.428, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NV97Hh0Dve2C for <ipsec@ietfa.amsl.com>; Mon, 17 Dec 2012 10:43:52 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2474421F8B65 for <ipsec@ietf.org>; Mon, 17 Dec 2012 10:43:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1984; q=dns/txt; s=iport; t=1355769832; x=1356979432; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=CVB60PYanXyHGdFvnUi/4EdM5LPEq3LLXyOZwnBADZo=; b=A9YMyPfPHxHTll0RIPujPLeOYJ1YWcvUZLdXL4iDehR2LCiBlejzMJ0w V5aohmZU6d4XB6XORwvjYZxxS1+YuWH1+ijgDfAbgiFY1qZNN+m9P3vXp t2o+wwEHOpBOBvWSgtuk25Q1sovLsEpW4kV+D69UtgzHxgqKLOW8VBVi0 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsYHACxnz1CrRDoJ/2dsb2JhbABFg0i6axZzgh4BAQEDAQEBAWsLBQsLDgouJzAGExuHcgUBDLl4BIxdG4NHYQOIYYk8g22QSIMUgUw
X-IronPort-AV: E=Sophos;i="4.84,304,1355097600"; d="scan'208";a="66724586"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 17 Dec 2012 18:43:51 +0000
Received: from dhcp-128-107-147-77.cisco.com (dhcp-128-107-147-77.cisco.com [128.107.147.77]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBHIhpeW022713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 18:43:51 GMT
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Brian Weis <bew@cisco.com>
In-Reply-To: <50CE010E.4000709@labn.net>
Date: Mon, 17 Dec 2012 10:43:55 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <F1923125-B429-4EC6-8135-D80B070A3D0F@cisco.com>
References: <0B592A71-6BE1-4988-8BA7-2F3CD61AD03A@cisco.com> <CAOyVPHRk49O0eX3KzCGB6usDW=aQhpe3=cPsQfSQM=sZQOE4Rg@mail.gmail.com> <154376FC-F5D4-472F-B321-5B2ED0C5CA2C@cisco.com> <50CB6CA4.3020806@labn.net> <9D8C5AA9-B072-445C-813E-FA187ED75BCE@cisco.com> <50CE010E.4000709@labn.net>
To: Lou Berger <lberger@labn.net>
X-Mailer: Apple Mail (2.1499)
Cc: "vishwas.manral@hp.com" <vishwas.manral@hp.com>, ipsec@ietf.org, Stephen Hanna <shanna@juniper.net>
Subject: Re: [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: Mon, 17 Dec 2012 18:43:53 -0000

On Dec 16, 2012, at 9:12 AM, Lou Berger <lberger@labn.net> wrote:

> Brian,
> 	Just want to confirm that Vishwas solution closes this issue.  Agreed?

Agreed!

Thanks,
Brian

> 
> Thanks,
> Lou
> 
> On 12/14/2012 4:56 PM, Brian Weis wrote:
>> Hi Lou,
>> 
>> On Dec 14, 2012, at 10:15 AM, Lou Berger <lberger@labn.net> wrote:
>> 
>>> Brian,
>>> 	Opps, should have replied to this message (and not the prior).
>>> 
>>> My previous mail basically said the new requirement is placed on the
>>> ADVPN solution, not a particular implementation.  I think it's important
>>> to ensure that the overall solution provides for Requirement 14, and I'm
>>> not sure how this can be done without a requirement.
>> 
>> If I understand correctly, these requirements are intending to be relevant to "ADVPN solutions" that don't include network infrastructure. It doesn't make sense to me to make a "ADVPN solution" implemented on PCs and comprised exclusively of PCs subject to this as a general requirement.
>> 
>> All other MUST requirements in Section 4 seem to apply equally to all use cases.
>> 
>>> 
>>> See below for additional specific responses.
>> 
>> [snip]
>> 
>>>> Lou, would something like the following text in Section 2.2 be a
>>>> satisfactory replacement for Requirement 14?
>>>> 
>>>>   There is also the case when L3VPNs operate over IPsec Tunnels, 
>>>>   for example Provider Edge (PE) based VPN's. An AD VPN must
>>>>   support L3VPN as an application protected by the IPsec
>>>>   Tunnels.
>>> 
>>> it he must was a MUST, sure.
>> 
>> I'd happily support a MUST here. There aren't any other MUSTs outside of Section 4, but I don't know why.
>> 
>> Thanks,
>> Brian
>> 
>>> 
>>> Lou
>> 
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>> 
>> 
>> 
>>