Subject: Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains

From: Dmitry Anipko <[email-masked]>
Date: Mon, 4 Nov 2013 00:19:15 +0000

Hi Suresh, Jouni, Shwetha,

thank you very much for sharing this work, I think this is a great start. Please find comments below. 

-Dmitry

Applicable to both DHCP and ND:

1. The drafts say there must be strictly one OPTION_PVD_ID in each container.  It makes sense for the particular type of ID, but I wonder whether this removes an ability to have the PVD named by different types of ID (UUID and UTF string, perhaps human readable) at the same time?If the latter is desirable, should multiple ID options, with different ID type each, be allowed in one container, or should there be a different solution for such scenario?

2.  The drafts say or imply that one of the things the container signature does, is that it can prevent unauthorized config source, such as a router or a DHCP server, from advertising a PVD it is not authorized to advertise. But it is not clear (at least to me), how that the use of the signature actually achieves or can achieve that? 

3. Both drafts mention timestamp as a protection against replay attacks. If that's the recommended solution against what's considered to be a fairly common relevant attack, shall the timestamp option be described (or already existing, if any, option be referred to)?

Applicable to DHCP only:

4. There seem to be possibly conflicting / ambiguous language about OPTION_PVD_AUTH in different places in the draft: "Every OPTION_PVD option SHOULD contain at most one OPTION_PVD_AUTH option" vs "The PVD container option SHOULD contain exactly one OPTION_PVD_AUTH". Remove one of the sentences? (my guess the latter)

5. In the description of the  option, it is unclear, to which field in the option the following text refers to: "authentication/authorization information: This information is provided by the owner of the provisioning domain and is passed on unmodified by the DHCPv6 server.".

6.  In client/server behavior, it seems to me, there is a mismatch between the client and the server behavior: the client is said to include OPTION_PVD in OPTION_ORO if it wants to get info from *all* PVDs (my guess, as opposed to individual PVD?); while server is sad to not send any PVD info if OPTION_PVD in OPTION_ORO is not present.

7. Related to 6, in the server section, it is unclear whether the intended use of OPTION_PVD in OPTION_ORO is to indicate client support for PVDs (as the first bullet seems to imply), or client interest in all PVDs (as the third bullet seems to imply).

Applicable to ND only:

8, There is currently no separate sections for client/router behavior (as in DHCP). Should it be added? (may be particularly helpful to discuss the potential differences between formation of solicited and unsolicited RAs, and clients interested in all PVDs/interested in particular PVD)

9. The language "after subtracting 'Options Count' times suboptions from it", if read literally, is probably not correct (multiplying only makes sense if all the lengths are equal).

For differences between DHCP and ND:

10. The formation of PVD signature is done differently in the drafts (in DHCP - the last option in the container, in ND - part of the container option) . Is there a reason for this (such as, potentially, consistency with other precedents in DHCP/ND)? (if there isn't, then arguably having unified way to verify messages can make implementations simpler)

11. The formatting of how variable number of sub options in the container is accommodated in ND vs DHCP, is different - in one cases, there is a field, explicitly indicating number of options, in addition to the length of the container and each option, in the other case it is based purely on lengths. Is there a reason for that?

12. OPTION_PVD_ID in ND has ID-Length, in DHCP it doesn't. Similarly,  differences in the \0-padding language.

________________________________________
From: [email-masked] <[email-masked]> on behalf of Suresh Krishnan <[email-masked]>
Sent: Wednesday, October 23, 2013 9:00 AM
To: [email-masked]
Subject: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains

Hi all,
  One of the action items from the meeting two weeks ago was to write up
a strawman solution proposal for DHCP and RA options to carry
information about multiple provisioning domains. Jouni, Shwetha and I
worked on it and came up with these initial drafts. We would love to
hear your comments.

The DHCP version is at

http://tools.ietf.org/html/draft-kkb-mpvd-dhcp-support-00

The RA version is at

http://tools.ietf.org/html/draft-kk-mpvd-ndp-support-00

Thanks
Suresh, Jouni and Shwetha
_______________________________________________
mif-arch-dt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mif-arch-dt

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 4 Nov 2013 20:06:08 +0200

Dmitry,

Thanks for the review. I have added few comments inline.

> 1. The drafts say there must be strictly one OPTION_PVD_ID in each container.  It makes sense for the particular type of ID, but I wonder whether this removes an ability to have the PVD named by di…

Honestly, having human readable stuff in this context does not bring any value. It already requires quite a n effort to diagnostic on DHCP/ND messages so converting e.g. UUID to displayable form.

We had the mindset that if you need an overlapping ID, add a new container. However, this is debatable.

> 2.  The drafts say or imply that one of the things the container signature does, is that it can prevent unauthorized config source, such as a router or a DHCP server, from advertising a PVD it is n…

A router or a DHCP server can advertise unauthorized information but the receiver will discover it, since the sender of  unauthorized information does not have the required private key to sign the data appropriately. Replays need then be handled differently, since the signature alone does not prevent replays.

> 3. Both drafts mention timestamp as a protection against replay attacks. If that's the recommended solution against what's considered to be a fairly common relevant attack, shall the timestamp opti…

Our intention was to rely on the "carrier protocol" to deal with replays. In case of DHCP, the DHCP protocol need to handle replays (like auth+RDM). In case of ND, existing ND security solutions need to deal with replays (like SeND). Why we took this approach was not repeat all the existing security solutions in the container option. However, this is debatable.

> 4. There seem to be possibly conflicting / ambiguous language about OPTION_PVD_AUTH in different places in the draft: "Every OPTION_PVD option SHOULD contain at most one OPTION_PVD_AUTH option" vs…

Ack.

> 5. In the description of the  option, it is unclear, to which field in the option the following text refers to: "authentication/authorization information: This information is provided by the owner…

Ack.

> 6.  In client/server behavior, it seems to me, there is a mismatch between the client and the server behavior: the client is said to include OPTION_PVD in OPTION_ORO if it wants to get info from *a…

Ok. We'll clarify this.

> 7. Related to 6, in the server section, it is unclear whether the intended use of OPTION_PVD in OPTION_ORO is to indicate client support for PVDs (as the first bullet seems to imply), or client int…

Client being interested all PVDs, not just a specific one. We'll clarify this.

> 8, There is currently no separate sections for client/router behavior (as in DHCP). Should it be added? (may be particularly helpful to discuss the potential differences between formation of solici…

Ok. Will add text for both router & end host.

> 9. The language "after subtracting 'Options Count' times suboptions from it", if read literally, is probably not correct (multiplying only makes sense if all the lengths are equal).

Ack. 

> 10. The formation of PVD signature is done differently in the drafts (in DHCP - the last option in the container, in ND - part of the container option) . Is there a reason for this (such as, potent…

No particular reason for signature encoding differences. These can easily be aligned.

> 11. The formatting of how variable number of sub options in the container is accommodated in ND vs DHCP, is different - in one cases, there is a field, explicitly indicating number of options, in a…

Different alignment requirements with ND and DHCP. This obviously requires some more thinking how to make encodings more alike.

Regarding the options count in ND that comes from the way the current signature field is added into the container option. If the signature becomes a sub-option itself, there would be no need for the count field.

> 12. OPTION_PVD_ID in ND has ID-Length, in DHCP it doesn't. Similarly,  differences in the \0-padding language.

That is mainly because in ND options length is multiple of 8 octets where are in DHCP options have no alignment requirements. The same principle was brought into sub-options. However, regarding sub-option in the container for ND, we could possible drop the alignment requirements if that becomes a sticking point.

Regarding padding, I rather keep the it explicit how the padding is done when such is needed.

- JOuni

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 6 Nov 2013 01:28:08 +0200

Dmitry,

On Nov 4, 2013, at 8:06 PM, Jouni Korhonen <[email-masked]> wrote:

[snip]

> That is mainly because in ND options length is multiple of 8 octets where are in DHCP options have no alignment requirements. The same principle was brought into sub-options. However, regarding sub…
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It seems my short term memory is failing or something.. for ND container we need to maintain 8 octet alignment, since we allow embedding existing ND options as sub-options. Existing ND options have strict alignment requirements and no way to indicate smaller length counts than 8 octets. I would love to use existing code to parse option (whether they are inside the PVD container or not).

- Jouni

---

From: Dmitry Anipko <[email-masked]>
Date: Sun, 17 Nov 2013 01:31:36 +0000

Hi Jouni,

sorry for the delay.

>>Honestly, having human readable stuff in this context does not bring any value. 

My understanding that several design team members at different times expressed a desired for an option to support some type of human-readable representation of the PVD ID, for instance, to be able to show those in UI (e.g., most recently http://www.ietf.org/mail-archive/web/mif/current/msg02130.html). I understand for human-readable IDs it may be more difficult to ensure/formalize approach for uniqueness, perhaps an option that would meet both requirements easily could be a mandatory UUID +  optional human-readable label.

All that said, in my opinion, Dave Thaler brought up interesting suggestion during the WG meeting, (as I understood it) to just described ID as a blob in this draft with needed length/alignment/padding for that blob, and have the details of the actual blob contents - possible ID types etc. elaborated elsewhere (and that reference could be shared by DHCP & ND documents). What do you think?

>>A router or a DHCP server can advertise unauthorized information but the receiver will discover it, since the sender of  unauthorized information does not have the required private key to sign the…

I see how that would work e.g. in enterprise network where all routers / access point are under admin control, but it's not immediately clear to me how such model would work e.g. at home where a home router, "managed" by the end user, connected to one or more ISP up-links. My guess ISPs won't delegate their private keys to the equipment, for which they can't ensure its integrity. What are your thoughts on how that scenario is solved?

 >> In case of ND, existing ND security solutions need to deal with replays (like SeND). Why we took this approach was not repeat all the existing security solutions in the container option. However, this is debatable.

Really don't mean to possibly start a passionate discussion, but has SeND seen sufficient level of deployment in order to take a dependency on it? If e.g. a schema which doesn't depend on SeND was considered, do you think it would inevitably require the same level of rich security capabilities as SeND provides?

-Dmitry
 
________________________________________
From: Jouni Korhonen <[email-masked]>
Sent: Monday, November 04, 2013 10:06 AM
To: Dmitry Anipko
Cc: Suresh Krishnan; [email-masked]
Subject: Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains

Dmitry,

Ack.

Ack.

Ok. We'll clarify this.

Ack.

- JOuni

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 22 Nov 2013 19:11:48 +0200

Dmitry,

> My understanding that several design team members at different times expressed a desired for an option to support some type of human-readable representation of the PVD ID, for instance, to be able…

Domain names and alike possible PVD-IDs are ok since they already are "human readable". However, I would put zero energy trying to add something readable data into PVDs if the used PVD-ID itself is e.g. a binary blob. I just see no value of that if it increases the data size of the PVD container or ID.

> All that said, in my opinion, Dave Thaler brought up interesting suggestion during the WG meeting, (as I understood it) to just described ID as a blob in this draft with needed length/alignment/pad…

Dave's proposal is well received as I would say. It makes the management and encoding of IDs much easier.

> I see how that would work e.g. in enterprise network where all routers / access point are under admin control, but it's not immediately clear to me how such model would work e.g. at home where a ho…

First, signing is optional. I would assume that in a home router
case Joe Average does not care about PVD information being signed
or not.. in a typical case.

There are two models: routed or bridged. In a bridged case the ISP
can still sign the PVD information even if the home router is managed
by the end user.

The routed case is then more complex. If the user cares about signed
PVD information, his home router would need to sign the stuff (per
PVD) with a private key whose certificate is issued by the ISP
(..certification paths.. uhh). The end host then would need to have
certificates for the issuer (trust anchor) and the home router.

This follows the existing model in the RFCs we cite for reuse.

> Really don't mean to possibly start a passionate discussion, but has SeND seen sufficient level of deployment in order to take a dependency on it? If e.g. a schema which doesn't depend on SeND was…

I know SeND failed to get deployed. And for that reason we do not have
a normative dependency. SeND is mentioned as a possibility to provide
first hop security is such is desired. I do agree that having a replay
protection included in the PVD container is tempting. This is something
to elaborate further.

- Jouni

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Nov 2013 15:33:57 -0500

> Domain names and alike possible PVD-IDs are ok since they already are "human readable". However, I would put zero energy trying to add something readable data into PVDs if the used PVD-ID itself is…

If the PVD ID is a blob, you need a mechanism for assigning a name to it and validating it.

Think about the possible flow here.   We want to be able to present this information to the user in a chooser, right?   So that means that if what's contained in the ID is a binary blob, we need a way to translate it.   Also, if the blob is something we've already seen and can cryptographically authenticate based on a previous leap of faith, then we need the signature to authenticate.  And if we don't have the name at this point, we need a process for finding the name associated with the blob after we've decided to try it.

It might be better to have a name that we can do all that too that's human-readable.   Then we can do cryptographic validation if we have already seen the name, and avoid connecting to a fraudulent version of the PVD (which we could also do with the blob).   But if we haven't seen the name before, and haven't yet accepted it, we want something to present to the user, don't we?

This bears thinking about.   I'm not saying you're wrong, but don't be too quick to leap to conclusions about this!

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 22 Nov 2013 15:38:50 -0500

Le 2013-11-22 à 15:33, Ted Lemon <[email-masked]> a écrit :

> It might be better to have a name that we can do all that too that's human-readable.  

be careful. If it is a protocol parameter that is not shown to the user, then human readable is one design choice to help troubleshoot and ...  But if is a human-readable for end-users, as you seem to assume above, then we enter into the languages, scripts, i18n, normalization and ....  I'm not sure we want to go there for a PVD-ID...  I would assume a protocol element and then some end-user mapping in his own language/script/locale that is outside of the scope of this work/spec.

Marc.

>  Then we can do cryptographic validation if we have already seen the name, and avoid connecting to a fraudulent version of the PVD (which we could also do with the blob).   But if we haven't seen the name before, and haven't yet accepted it, we want something to present to the user, don't we?
>

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 22 Nov 2013 20:57:23 +0000

>>But if is a human-readable for end-users, as you seem to assume above, then we enter into the languages, scripts, i18n, normalization and 

As I understand, there are a few examples like SSID, APN names etc which are typically (or perhaps can't be?) localized. Is there a guidance document at the IETF which prohibits introduction of new types of human-readable identifiers w/o internationalization support?
________________________________________
From: Marc Blanchet <[email-masked]>
Sent: Friday, November 22, 2013 12:38 PM
To: Ted Lemon
Cc: Jouni Korhonen; [email-masked]; Suresh Krishnan; Dmitry Anipko
Subject: Re: [mif-arch-dt] Strawman solution proposals for DHCPv6 and RA support for multiple provisioning domains

Marc.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Nov 2013 16:17:34 -0500

> But if is a human-readable for end-users, as you seem to assume above, then we enter into the languages, scripts, i18n, normalization and

This is not that hard, and we shouldn't avoid it.   Of course names need to be human-readable. So encode them in UTF-8.   (I'm oversimplifying, because you still need a unique identifier, and that's likely _not_ the name.)

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 23 Nov 2013 22:19:26 +0200

> If the PVD ID is a blob, you need a mechanism for assigning a name to it and validating it.

For me UUID is a binary blod. Obviously you need to know to type of the
binary you are carrying.

- Jouni

---

From: Ted Lemon <[email-masked]>
Date: Sat, 23 Nov 2013 21:56:19 -0500

> For me UUID is a binary blod. Obviously you need to know to type of the

You are just stating an opinion—what are we supposed to do with that?   Can you say what the reason is behind your opinion, and how you intend for your blob to work?

---

From: Jouni Korhonen <[email-masked]>
Date: Sun, 24 Nov 2013 15:51:33 +0200

Ted,

> You are just stating an opinion—what are we supposed to do with that?   Can you say what the reason is behind your opinion, and how you intend for your blob to work?

The starting point was unifying the encoding of PVD-IDs across protocols they get carried over and having the PVD-IDs defined in one place. Therefore, from the protocol point of view that carries the PVD-ID, it is always considered as a binary blob; for example in case of DHCPv6 or NDP the PVD-ID option would just be Type(PDV-ID)+Length(PVD-ID with necessary paddings)+Value(binary blob).

Then a spec (to be) that defines the PVD-IDs with unified encoding describes how the "binary blob" is interpreted. That would then be Type(ID)+ID_specific_fields.

The receiver and sender can know what the "binary blob" is for the PVD-ID and how to process it. Also the parsing is unified to a degree that a receiver can skip the ID if it does not understand its type.

Anyway, back to "human readable" part. Say that my PVD-ID is basically a binary construction. I see no reason to add another set of data to make my binary encoded PVD-ID human readable on wire. That is just unnecessary and duplicate information. Any parser or diagnostic tool that understands the used PVD-ID type can display something user friendly out of it - when needed. 

- Jouni

---

From: Tim Chown <[email-masked]>
Date: Sun, 24 Nov 2013 14:11:24 +0000

> This is not that hard, and we shouldn't avoid it.   Of course names need to be human-readable. So encode them in UTF-8.   (I'm oversimplifying, because you still need a unique identifier, and that'…

I think there’s many potential scenarios for PVD-IDs, and to what or whom they may or may not be exposed to or required by, be the 'consumer' users or applications.

We seem to commonly refer to a user selecting an SSID and a PVD-ID following implictly from that; so the PVD-ID is implictly acquired, and the user may never need to see it. The user device may however have multiple interfaces, e.g. WiFi and 3G. I believe that iOS7 runs MPTCP across both wired and wireless interfaces for Siri, which is an interesting example.

Another example is selecting and using a VPN; there is again an implicit PVD-ID associated with the connection when the user initiates the VPN (or the VPN auto connects). We said at IETF88 that certain applications should be configurable to run only if a certain VPN PVD is available.

In the case of a mutli-homed IPv6 site with multiple prefixes, from different providers, users on workstations with two IPv6 prefixes don’t currently make selections, rather they rely on address selection or some other policy to be applied.  In this PVD case, an application may again wish to only run if a certain PVD is available, e.g. one prefix is associated with a PVD for some IP TV service, the other prefix is used for general Internet.

The above behaviours don’t require users to select PVDs, except where they are already exposed today as SSIDs or VPNs, but applications seem more likely to be able to assert a certain PVD is in place?

Perhaps we need something in the draft to discuss the possible ‘consumers’ of PVDs?

Tim