Subject: Re: [mif] AD review of MPVD Architecture

From: Dmitry Anipko <[email-masked]>
Date: Sat, 10 Jan 2015 17:21:42 -0800

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Jan 2015 22:21:01 -0500

On Jan 10, 2015, at 8:21 PM, Dmitry Anipko <[email-masked]> wrote:
> >>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.

OK.  Does anybody know what the intent was behind this text:

  One way to

As I said above, this wouldn't actually be possible with DHCP OROs, but what's being proposed here could in principle be done by providing separate OROs per PvD.

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

I would just not mention shared-secret authentication.   The way authentication happens is really out of scope for this document anyway.

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

No, this change isn't quite capturing the point I was making.   How about this:

  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.
     This may also occur accidentally if two sites choose the same
     identifier (e.g., "linsky").

     In order to detect and prevent this, the client must be able to
     authenticate the identifier provided by the network.   This means
     that the client must have configuration information that maps the
     PvD identifier to an authenticable identity, and must be able to
     authenticate that identity.

     In addition, the network must provide
     information the client can use to authenticate the identity.   This
     could take the form of a PKI-based or DNSSEC-based trust anchor, or
     a key remembered from a previous leap-of-faith authentication of
     the identifier.

     Because the PvD-specific information may come to the network
     infrastructure with which the client is actually communicating
     from some upstream provider, it is necessary in this case that
     the PvD container and its contents be relayed to the client
     unchanged, leaving the upstream provider's signature intact.

---

From: Dmitry Anipko <[email-masked]>
Date: Tue, 13 Jan 2015 23:17:54 -0800

Hi Ted,

>>OK.  Does anybody know what the intent was behind this text:

My best recollection is that the contributors believed that there may be a
need to deploy multiple PVDs, applicable to different nodes/node groups,
and hence to avoid having to do broadcast propagation of all of those, a
node could have an ability to specify which ones the node is capable to
understand.

>>I would just not mention shared-secret authentication.

OK.

>>No, this change isn't quite capturing the point I was making.

Thanks for suggesting the text. Looks good to me.

After the question around ORO is closed (or decided to be left open) I will
submit another rev with these changes.

Thank you,
Dmitry

On Sat, Jan 10, 2015 at 7:21 PM, Ted Lemon <[email-masked]> wrote:

> > >>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.
> As I said above, this wouldn't actually be possible with DHCP OROs, but
> what's being proposed here could in principle be done by providing separate
> OROs per PvD.
>
> I would just not mention shared-secret authentication.   The way
> authentication happens is really out of scope for this document anyway.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Jan 2015 07:58:04 -0800

On Jan 13, 2015, at 11:17 PM, Dmitry Anipko <[email-masked]> wrote:
> My best recollection is that the contributors believed that there may be a need to deploy multiple PVDs, applicable to different nodes/node groups, and hence to avoid having to do broadcast propagation of all of those, a node could have an ability to specify which ones the node is capable to understand.

That sounds highly problematic.   How does the node know which pvds to list for a particular network?   What about the privacy implications?   I think this should just be taken out of the architecture and left as future work when someone is enthusiastic and has a use case for it.

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 14 Jan 2015 21:41:52 -0800

>> I think this should just be taken out of the architecture and left as
future work when someone is enthusiastic and has a use case for it.

Thanks Ted. If there are no other inputs by end of Friday, I will remove
the respective text from the draft.

On Wed, Jan 14, 2015 at 7:58 AM, Ted Lemon <[email-masked]> wrote:

> > My best recollection is that the contributors believed that there may be
> a need to deploy multiple PVDs, applicable to different nodes/node groups,
> That sounds highly problematic.   How does the node know which pvds to
> list for a particular network?   What about the privacy implications?   I
> think this should just be taken out of the architecture and left as future
> work when someone is enthusiastic and has a use case for it.
>
>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Jan 2015 13:13:27 -0500

On Jan 15, 2015, at 12:41 AM, Dmitry Anipko <[email-masked]> wrote:
> Thanks Ted. If there are no other inputs by end of Friday, I will remove the respective text from the draft.

Time's a-wasting.

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 22 Jan 2015 11:11:33 -0800

Sorry for the delay, will submit the revision today/tomorrow.