Re: [mif] AD review of MPVD Architecture

Dmitry Anipko <dmitry.anipko@gmail.com> Sun, 11 January 2015 01:21 UTC

Return-Path: <dmitry.anipko@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A482A1A1A76 for <mif@ietfa.amsl.com>; Sat, 10 Jan 2015 17:21:50 -0800 (PST)
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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTxhHIsRmw0K for <mif@ietfa.amsl.com>; Sat, 10 Jan 2015 17:21:44 -0800 (PST)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086751A1A75 for <mif@ietf.org>; Sat, 10 Jan 2015 17:21:44 -0800 (PST)
Received: by mail-wg0-f42.google.com with SMTP id k14so13918610wgh.1 for <mif@ietf.org>; Sat, 10 Jan 2015 17:21:42 -0800 (PST)
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=GsFglCvVTf8eg/urNhtro85LHIEvpphl4hKIWrEbRHs=; b=gy14Kr1A3+7yZLOpHndBQztDGu37WgtNgkGPja1i95QkcujlP/ojcCehTdK4zanVVK AS0XPZM9RHsOxsUQ6NBkGxE8y4Mje2wrm/Owvd08/P/VAuWckayUACIVVUVmg/fuA3Dr 2M4L7Gk3PF0/4qgS1O9vMlfwgmFqxTgBuDkpY9R915qbj2M6pLxVbS3bcxYiTWnrQQCD JtBvwkVDaFCQ82xUPa6fkhnTbiKD+9JGuVDN/Ow8O/dc8MdtBttNQdCWYWpWIjrs/Zv8 VOVNB8UmMWsYiVtvyhwJTnOVcevlhgkzuO3Rg6XZ0fBTj4f/kYXOXPR0XymYFsRVpNrI rxLQ==
MIME-Version: 1.0
X-Received: by 10.194.175.2 with SMTP id bw2mr12939166wjc.117.1420939302739; Sat, 10 Jan 2015 17:21:42 -0800 (PST)
Received: by 10.180.101.70 with HTTP; Sat, 10 Jan 2015 17:21:42 -0800 (PST)
In-Reply-To: <9071C858-BBCA-483C-94CD-E7C2584980F0@nominum.com>
References: <9071C858-BBCA-483C-94CD-E7C2584980F0@nominum.com>
Date: Sat, 10 Jan 2015 17:21:42 -0800
Message-ID: <CACurXJhq5PyogN=J-kHBjqiNO1VTFsm_F9e-YdK+Q9Zqy_pKjw@mail.gmail.com>
From: Dmitry Anipko <dmitry.anipko@gmail.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Content-Type: multipart/alternative; boundary="089e013d0f846325db050c5636c7"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mif/sAtIwIrCYwIIz-TMf1xi_76Toag>
Cc: "mif@ietf.org List" <mif@ietf.org>
Subject: Re: [mif] AD review of MPVD Architecture
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif/>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Jan 2015 01:21:50 -0000

Hi Ted,

thank you for review and comments. Please find responses below:

>>This is a bit hard to parse, and I suggest the following change:

>>Use of a particular network that is not consistent with the

       intended use of the network, or the intent of the

       communicating parties, leading to connectivity failure

       and / or other undesired consequences.


Done.


>>What's the rationale for the third sentence in the paragraph below?

>>However,

   where different design choices are possible, the choice that requires

   a smaller number of packets shall be preferred for efficiency.

>>If it's more of an aside, let's get rid of it.


Done. If anyone on the list feel strongly about it, they can object.


>>For the foreseeable future, there will be networks which do not

   advertise explicit PvD information, because deployment of new

   features in networking protocols is a relatively slow process


Done.


>PvD-aware nodes shall treat betwork information from different

   interfaces, which is not identified as belonging explicitly to some

   PvD, as belonging to separate PvDs, one per interface.

>>The reason I propose this is that the last paragraph


Done.


>> NEW:

   Implicit PvDs can also occur in a mixed mode, i.e., where of multiple

   networks that are available on an attached link, only some advertise

   PvD information.  In this case, the PvD-

   aware node shall create explicit PvDs from information explicitly

   labeled as beloinging to PvDs.   It shall associate

   configuration information not labeled with an explicit PvD with

   an implicit PvD created for that interface.

>>(Is there a case where two implicit PvDs would be created on the same
interface?)


Done, with very minor modification. I’m trying to avoid re-spinning the
discussion whether there may or may not be multiple implicit PvDs on one
interface.


>>In the simplest case, explicit PvDs will be scoped for

   configuration related only to a specific interface.  However,

   there is no requirement in this architecture for such a

   limitation.


Done.


>>I don't know what "generally" means here, suggest you delete it:


Done.


>>This architecture supports such scenarios.

   Hence, no hierarchical relationship exists

   between interfaces and PvDs: it is possible for multiple PvDs to be

   simultaneously accessible over one interface, as well as a single PvD

   to be simultaneously accessible over multiple interfaces.


Done.


>> If the term "token" was preferred over "signature", it's fine to leave
it that way and duke it out during IESG review. :)


I’ve changed to “token or signature”.


>>The ORO just lists options.   There's no way to name a PvD.   I vaguely
recall that the idea here was to provide a per-PvD ORO, not list PvDs in
the ORO.


I’m leaving this item open for in this update, and suggest that the
contributors who have suggested this text would comment.


>>This would mean that any node that can authenticate the assertion of the
PvD identity can also spoof it:


What would be the change you propose?


>>What prevents this attack is not the provision of authentication
information, but an explicit configuration on the client to reject this PvD
if it is _not_ authenticated.   The way you've stated it, it's fairly
obvious that that's the case, but you don't actually say so.


I’ve added a sentence, let me know if it doesn’t address your comment.


Thanks,

Dmitry

On Wed, Dec 17, 2014 at 7:48 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

> I'm sorry this has taken so long.   It got lost in the tracker, only to
> surface just as an unrelated cluster of documents was soaking up a lot of
> my time.   I am very excited to get this document to the IESG, so please
> don't take this delay as being indicative of a lack of interest.   On to
> the comments:
>
> This is a bit hard to parse, and I suggest the following change:
> OLD:
>    3.  Usage of a particular network that is not consistent with the
>        intent of the scenario or involved parties leading to
>        connectivity failure and / or other undesired consequences.
> NEW:
>    3.  Use of a particular network that is not consistent with the
>        intended use of the network, or the intent of the
>        communicating parties, leading to connectivity failure
>        and / or other undesired consequences.
>
> What's the rationale for the third sentence in the paragraph below?
>
>    In some network topologies, network infrastructure elements may need
>    to advertise multiple PvDs.  Generally, the details of how this is
>    performed will be defined in companion design documents.  However,
>    where different design choices are possible, the choice that requires
>    a smaller number of packets shall be preferred for efficiency.
>
> I ask because I think this is DISCUSS fodder: someone is going to want
> details.   If it's important, let's keep it and defend it.   If it's more
> of an aside, let's get rid of it.
>
> Difficult to parse:
> OLD:
>    For some time it is likely that there will be networks which do not
>    advertise explicit PvD information as the deployment of new features
>    in networking protocols is a relatively slow process.
> NEW:
>    For the foreseeable future, there will be networks which do not
>    advertise explicit PvD information, because deployment of new
>    features in networking protocols is a relatively slow process.
>
> I think the last sentence in this paragraph serves two purposes, and would
> be better separated:
> OLD:
>    Through the use of implicit PvDs, PvD-aware nodes may still provide
>    benefits to their users (when compared to non-PvD aware nodes) by
>    following the best practices described in Section 5, using the
>    network information from different interfaces separately to
>    consistently serve network connection request.
> NEW:
>    Through the use of implicit PvDs, PvD-aware nodes may still provide
>    benefits to their users (when compared to non-PvD aware nodes) by
>    following the best practices described in Section 5.
>
>    PvD-aware nodes shall treat betwork information from different
>    interfaces, which is not identified as belonging explicitly to some
>    PvD, as belonging to separate PvDs, one per interface.
>
> The reason I propose this is that the last paragraph in the section
> imposes an explicit requirement on PvD-aware nodes that they separate out
> PvD-labeled and non-PvD-labeled information into explicit and implicit
> PvDs, but the section as a whole never explicitly states a requirement that
> information from different interfaces that is not labeled is treated as
> belonging to separate PvDs.   Whether this change as taken as I have made
> it, or done some other way, I think you need to state a requirement for
> both cases.
>
> The last paragraph in the section also doesn't parse very well:
> OLD:
>    In mixed mode, i.e., where of multiple networks are available on an
>    attached link only some of which advertise PvD information, the PvD-
>    aware node shall create explicit PvDs from explicitly learned PvD
>    information and associate other learned configuration (without an
>    explicit PvD) with implicit PvD(s) created for that interface.
> NEW:
>    Implicit PvDs can also occur in a mixed mode, i.e., where of multiple
>    networks that are available on an attached link, only some advertise
>    PvD information.  In this case, the PvD-
>    aware node shall create explicit PvDs from information explicitly
>    labeled as beloinging to PvDs.   It shall associate
>    configuration information not labeled with an explicit PvD with
>    an implicit PvD created for that interface.
>
> (Is there a case where two implicit PvDs would be created on the same
> interface?)
>
> This seems a bit too definite to me:
> OLD:
>    Explicit PvDs, in practice will often also be scoped only for
>    configuration related to a particular interface.  However, there are
>    no such requirements or limitations defined in this architecture.
> NEW:
>    In the simplest case, explicit PvDs will be scoped for
>    configuration related only to a specific interface.  However,
>    there is no requirement in this architecture for such a
>    limitation.
>
> I don't know what "generally" means here, suggest you delete it:
>    generally, authentication of a PvD ID
>    may be also required in scenarios involving only one connected
>    interface and / or PvD
>
> You could take out some equivocating here:
> OLD:
>    This architecture intends to support such scenarios, among others.
>    Hence, it shall be noted that no hierarchical relationship exists
>    between interfaces and PvDs: it is possible for multiple PvDs to be
>    simultaneously accessible over one interface, as well as a single PvD
>    to be simultaneously accessible over multiple interfaces.
> NEW:
>    This architecture supports such scenarios.
>    Hence, no hierarchical relationship exists
>    between interfaces and PvDs: it is possible for multiple PvDs to be
>    simultaneously accessible over one interface, as well as a single PvD
>    to be simultaneously accessible over multiple interfaces.
>
> I think you need a signature, not an authorization token, here:
>    To resolve this, there must be
>    a mechanism for the PvD owner to attach some form of authorization
>    token to the configuration information that is delivered.
>
> I don't remember the details of the discussion we had anymore, but the
> issue with a token is that it doesn't actually solve the problem of proving
> that the PvD information supplied is actually associated with the named
> PvD.   Having said this, I know the working group thought about this, and
> I'm not proposing to change the consensus.   If the term "token" was
> preferred over "signature", it's fine to leave it that way and duke it out
> during IESG review. :)
>
> This doesn't make sense:
>    One way to
>    restrict the propagation of information which is of no use to a
>    specific host is for the host to indicate the PvD information they
>    require within their configuration request.  One way this could be
>    accomplished is by using a DHCPv6 ORO containing the PvDs that are of
>    interest.  The configuration source can then respond with only the
>    requested information.
>
> The ORO just lists options.   There's no way to name a PvD.   I vaguely
> recall that the idea here was to provide a per-PvD ORO, not list PvDs in
> the ORO.
>
> Do you really want to advocate the use of shared-secret authentication of
> PvD identities?   This would mean that any node that can authenticate the
> assertion of the PvD identity can also spoof it:
>
>    One way to validate the trust relationship between a node and the
>    source of a PvD is through the combination of cryptographic
>    authentication and an identifier configured on the node.  In some
>    cases, the two could be the same; for example, if authentication is
>    by a shared secret, the secret would have to be associated with the
>    PvD identifier.  Without a PvD Identifier / shared key tuple,
>    authentication would be impossible, and hence authentication and
>    authorization are combined.
>
> Slight clarification called for here:
>    Rogue configuration source: A compromised configuration source, such
>       as a router or a DHCPv6 server, may advertise information about
>       PvDs that it is not authorized to advertise.  e.g.  A coffee shop
>       WLAN may advertise configuration information purporting to be from
>       an enterprise and may try to attract enterprise related traffic.
>       The only real way to prevent this is is for the PvD related
>       configuration container to contain embedded authentication and
>       authorization information from the owner of the PvD. This provides
>       the client with a way of detecting the attack by verifying the
>       authentication and authorization information provided inside the
>       PvD container option, after verifying its trust of the PvD owner
>       (e.g.  a certificate with a well-known / common trust anchor).
>
> What prevents this attack is not the provision of authentication
> information, but an explicit configuration on the client to reject this PvD
> if it is _not_ authenticated.   The way you've stated it, it's fairly
> obvious that that's the case, but you don't actually say so.
>
>
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif
>