Re: [mif] AD review of MPVD Architecture ***feedback needed from MIF working group participants ***

[Dmitry Anipko <[e-mail]>]

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 <[e-mail]> wrote:

> On Jan 10, 2015, at 8:21 PM, Dmitry Anipko <[e-mail]>
> 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
>   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.
>
> 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:
> > What would be the change you propose?
>
> 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.
> >
> > I’ve added a sentence, let me know if it doesn’t address your comment.
>
> 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.
>
>