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

[Jouni Korhonen <[e-mail]>]

Dmitry,

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


On Nov 4, 2013, at 2:19 AM, Dmitry Anipko <[e-mail]> wrote:

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

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

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 option be described (or already existing, if any, option be referred to)?

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.

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

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 of the provisioning domain and is passed on unmodified by the DHCPv6 server.".

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

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 interest in all PVDs (as the third bullet seems to imply).

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

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

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. 

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

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

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: [e-mail] <[e-mail]> on behalf of Suresh Krishnan <[e-mail]>
> Sent: Wednesday, October 23, 2013 9:00 AM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif-arch-dt
> _______________________________________________
> mif-arch-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif-arch-dt