Re: [IPsec] AD re-review of draft-ietf-ipsecme-ad-vpn-problem

Vishwas Manral <vishwas.ietf@gmail.com> Mon, 03 June 2013 17:33 UTC

Return-Path: <vishwas.ietf@gmail.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 8F41121F91A3 for <ipsec@ietfa.amsl.com>; Mon, 3 Jun 2013 10:33:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B31UINa8k8Yu for <ipsec@ietfa.amsl.com>; Mon, 3 Jun 2013 10:33:20 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 89A6021F8F41 for <ipsec@ietf.org>; Mon, 3 Jun 2013 10:29:24 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id b11so11141304iee.39 for <ipsec@ietf.org>; Mon, 03 Jun 2013 10:29:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y8WPQHvzrEsJXmokO+aBRb4c1O6yUKqutLfc+WBWP3Y=; b=C5VG2UTiFRiCJJmHMSkQTnyhntWxb4AM4wJsT/PmyaBiF2oe6pDb3mzBJXijvfIku+ l8Jx6KJbxZyMf3l9GtPZ2DEgO3H02YAATfirDgUm0xFhF2lBKWfTmPIps9Yogvy5mWRo ui917KEfSe+CH3EZcwE6iF/j3nHspar0MXeJ5F6c5f1BhprcXiat6SFpa1JHyASOVUHn Fpbdy488WnCtrIyu7NgOnrappLC74fM18P3h8vsclvh1tLGSA9bHcu2+ISF4Lk/Gcg5P 9l5ZcJbtSmEuaZA56dvjyX/FzTBgnQoYgvNU40VZG1j1fdahrj55fWSY/uzvnVGf7ORU bkfw==
MIME-Version: 1.0
X-Received: by 10.50.128.44 with SMTP id nl12mr8805995igb.0.1370280564159; Mon, 03 Jun 2013 10:29:24 -0700 (PDT)
Received: by 10.50.56.107 with HTTP; Mon, 3 Jun 2013 10:29:24 -0700 (PDT)
In-Reply-To: <51ACD133.3040903@ieca.com>
References: <CAOyVPHSjYfvbQFP1nJGzAEySe3saXuSEftbvshzLHix68FCHHA@mail.gmail.com> <51ACD133.3040903@ieca.com>
Date: Mon, 03 Jun 2013 10:29:24 -0700
Message-ID: <CAOyVPHSW9qPFM_VVtVnZUMO4J_NrUxLwfjZ-eRakqOOEtyN08g@mail.gmail.com>
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Sean Turner <turners@ieca.com>
Content-Type: multipart/mixed; boundary="089e013a011c44f97604de434e3d"
Cc: IPsecme WG <ipsec@ietf.org>, "draft-ietf-ipsecme-ad-vpn-problem@tools.ietf.org" <draft-ietf-ipsecme-ad-vpn-problem@tools.ietf.org>
Subject: Re: [IPsec] AD re-review of draft-ietf-ipsecme-ad-vpn-problem
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, 03 Jun 2013 17:33:31 -0000

Hi Sean,

Here is the latest draft with your comments incorporated.

WG/ Toby,

I have added one last requirement number 15 into the document for QoS.
Based on inputs from the WG, we can add/ remove/ or update the requirement.

Thanks,
Vishwas


On Mon, Jun 3, 2013 at 10:24 AM, Sean Turner <turners@ieca.com> wrote:

> On 6/3/13 1:02 PM, Vishwas Manral wrote:
>
>> Hi Sean,
>> My comments are inline:
>>
>> Please incorporate the QoS issue brought up by Toby.I'd like to make
>>
>>
>> sure we have everything in the draft that the WG wants before issuing
>>
>> the WGLC.I also think the TSV/RTG directorates/ADs will be interested
>>
>>
>> in that.
>>
>> VM> I can incorporate it if the Working Group thinks the QoS parts
>> should be part of the aDVPN solution.
>>
>
> Yeah it wasn't clear to me whether it should be part of the aDVPN
> solution.  Maybe the chairs can chime in on this one.
>
>
>  Can you explain the rationale for the following the changes to
>>
>> requirement #5; I'm just not following it:
>>
>> OLD:
>>
>> 5. One ADVPN peer MUST NOT be able to impersonate another ADVPNpeer.
>>
>> NEW:
>>
>> 5. Any of the ADVPN Peers MUST NOT have a way to get the long term
>>
>> authentication credentials for any other ADVPN Peers. The compromise of
>>
>> an Endpoint MUST NOT affect the security of communications between other
>>
>> ADVPN Peers. The compromise of a Gateway SHOULD NOT affect the security
>>
>> of the communications between ADVPN Peers not associated with that
>> Gateway.
>>
>> Is the first sentence still saying basically: "peers can't impersonate
>>
>> peers"?
>>
>> VM> Yes thats the idea in my view. Steve Hanna may have more omments on
>> this. Steve?
>>
>
> Okay I guess that makes sense it just seems a little wordy but not worth
> holding the draft up for.
>
>
>  Nits:
>>
>> - sec 1.1: Need to add what an ADVPN is and expand the acronym
>>
>> VM> Should something like the below suffice:
>>
>> VM> ADVPN - Auto Discovery Virtual Private Network (ADVPN) is VPN
>> solution that enables a large number of systems to communicate directly,
>> with minimal configuration and operator intervention using IPsec to
>> protect communication between them.
>>
>
> yes
>
>  - sec 4/1.1: The terms allied and federated environment kind of come out
>>
>> of nowhere.Please add them to s1.1.I just to make sure it's clear
>>
>>
>> what the difference is between the two.
>>
>> VM> Here is what I will add to 1.1.
>>
>> VM> Allied and Federated Environments - Environments where we have
>> multiple different organizations that have close association and need to
>> connect to each other.
>>
>
> that'll work.
>