[dhcwg] draft-ypal-sfc-dhcp-option-for-nsh-for-sfp

[Ted Lemon <[e-mail]>]

>
>    The NSH SFP option can be used by the client and server during the
>    initial four message exchanges (DHCPDISCOVER, DHCPOFFER, DHCPREQUEST,
>    and DHCPACK) or during two message exchange (DHCPINFORM and DHCPACK)
>    to configure the SFP details to SFF DHCP clients (i.e SFF will
>    receive SFP details along with other DHCP configuration parameters).


When would a client ever use the SFP option?   I think what you mean here
is something more like this:

The NSH SFP option can be used by DHCP servers to communicate SFP
information to  DHCP clients, either in a stateful DHCP address
configuration or renewal transaction, or in a stateless information request
(DHCPINFORM).

I would really suggest that you take out as much descriptive language about
how DHCP works as possible, because it's not clear to me that the model you
are using for DHCP behavior is correct, and I think readers will find it
confusing, and may feel that they need to make inappropriate changes to
their client or server implementations to support this option.   In
particular, it's entirely possible that an SFP option might be added to the
server's configuration and that clients might receive it during a stateful
IP address renewal.   This is perfectly reasonable and should not be
excluded, but the above language does exclude it.

A client configured from beginning to act as SFF MUST include the
> OPTION_NSH_SFP option in both DHCPDISCOVER and DHCPREQUEST to inform
> the server about the options client is interested in. Whereas, if the
> client is configured latter to act as SFF after initial exchanges, it
> MUST include OPTION_NSH_SFP option in the DHCPINFORM message to inform
> the server.


This isn't how DHCP works.   Clients need only mention the option code for
the option in the parameter request list.   There is no need to send the
option as well, and the server would need to be specially modified to
handle that behavior.   You mention this in the previous paragraph.   Also,
the client can either do a DHCPINFORM or simply renew its lease to request
the new information.   Which is done should be left up to the
implementation, so I would reword this paragraph as follows:

DHCP clients that support the SFF option must handle the case where SFF
functionality is configured after the client has been started.   This can
be handled by the client either by renewing its lease when SFF
functionality is configured, or by sending a DHCPINFORM message.   The
details of how this is implemented are implementation-dependent.

The above suggestion also applies to section 5.3.1.

   A DHCPv4 server if configured to handle service chaining, SHOULD
>    provision the SFF clients with SFP, as per its administrative policy.
>    A server can receive requests for OPTION_NSH_SFP option from clients
>    in different message (DHCPDISCOVER and DHCPREQUEST) exchanges.


This is how DHCP works, and there is no need to repeat it here.  It's also
incomplete, and I don't think you should try to make it complete.   Please
just rely on the base protocol specification to say how this works.

   DHCPv4 server SHOULD inform the client with the option OPTION_NSH_SFP
>    and SFP information in both DHCPOFFER and DHCPACK messages as a response
>    to the DHCP client's DHCPDISCOVER and DHCPREQUEST respectively. If the
>    DHCPv4 server receives the option OPTION_NSH_SFP during DHCPINFORM
>    exchange, it SHOULD process and respond back as per administrative
>    policy (server MAY choose to act as per the host requirement document).
>    NSH SFP option sent to client is detailed in section 4.1.1


Again, you are incorrectly specifying what is already specified in the base
protocol spec.   Please just delete this text.

    DHCPv4 server SHOULD inform the client with the option OPTION_NSH_SFP
>    and SFP information in both DHCPOFFER and DHCPACK messages as a response
>    to the DHCP client's DHCPDISCOVER and DHCPREQUEST respectively. If the
>    DHCPv4 server receives the option OPTION_NSH_SFP during DHCPINFORM
>    exchange, it SHOULD process and respond back as per administrative
>    policy (server MAY choose to act as per the host requirement document).
>    NSH SFP option sent to client is detailed in section 4.1.1


Same issue.   Please delete.

   Whenever server detects any change is required in the SFP path, it
>    will inform the clients using Reconfigure Message.


DHCP servers don't detect that changes are required in the SFP path.   They
are reconfigured with new information.   What they do then is up to the
agent that is doing the reconfiguring, not up to the DHCP server.   I would
suggest that you put it this way instead:

When a DHCP server has been configured with different SFP parameters, the
administrator or agent that updated the configuration should trigger
Reconfigure messages for any clients that now have stale configurations.
How such clients are identified is implementation-dependent.   Such
reconfiguration may not be possible in practice.

You should also require (or at least recommend) that clients that use the
SFP option support reconfigure, since reconfigure support in clients is not
guaranteed.   That said, if you are depending on this DHCP option as a way
to get clients to switch away from no-longer-valid paths, you are probably
asking too much of DHCP.

   A server receiving the option OPTION_NSH_SFP in Solicit, Request, Renew,
>    Rebind, Confirm or Information-request will process this request and
>    SHOULD respond back to exchange with NSH SFP option as detailed in

   section 4.2.1


I think this is incorrect, and should be reworded as follows:

Clients do not send OPTION_NSH_SFP to servers; therefore, servers that
receive this option should take no special action as a result of having
received it.

>
> 5.5. Geolocation Based SFP
>    In certain cloud deployment scenarios, operator will like to know the
>    details of SFF location to provide information to local authority
> towards
>    integrity of resources and data moving across the SFF. In such
> scenarios,
>    SFF sends option OPTION_NSH_SFP along with geolocation option to DHCP
>    server.
>    In order to achieve this, the DHCP SFF clients SHOULD include the
>    GeoConf option as per RFC6225 and OPTION_GEOCONF_CIVIC option as per
>    RFC4776 for DHCPv4 and DHCPv6 respectively, along with the
> OPTION_NSH_SFP
>    option in DHCPDISCOVER, DHCPREQUEST, DHCPINFORM requests of DHCPv4 and
>    in Solicit, Request, Renew, Rebind, Confirm or Information-request in
>    DHCPv6 exchanges.


The privacy implications of this section are breathtaking.   This text
should not survive IESG review.   I recommend you take it out now and avoid
the fight.

>
>     To minimize the unintended exposure of SFP, the OPTION_NSH_SFP
>    option SHOULD be returned by DHCP servers only when the DHCP client
>    has included this option in its request (Section 3.5 of [RFC2131],
>    Section 9.8 of [RFC2132]).


Again, confusion about ORO/PRL versus sending the actual option.   Please
change "has included this option" to "has requested this option".   Also,
obviously you should not reference section 3.5 of RFC 2131--section 9.8 of
RFC 2132 is the only applicable reference.

   Where critical decisions might be based on the value of this option,
>    DHCP authentication as defined in "Authentication for DHCP Messages"
>    [RFC3118] and "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"
>    [RFC3315] SHOULD be used to protect the integrity of the DHCP

options.


Neither of these choices is actually available to implementations.   RFC
3118 didn't catch on, and the mechanism defined in 3315 didn't either, and
is effectively deprecated.   If your document needs to rely on integrity
protection for DHCP4, you are out of luck.   For DHCPv6, there is work in
progress that you could reference, but there is no existing standard to
reference.

   Link-layer confidentiality and integrity protection may also be
>    employed to reduce the risk of location disclosure and tampering.


I would reword this as follows:

Networks where this option is used SHOULD use link-layer security and
integrity protection.    Additionally, such networks should filter out
rogue DHCP messages (RFC 7610).

Your IANA considerations section is inadequate.   Take a look at:
https://tools.ietf.org/html/rfc5226

Sorry for all the criticism, but the goal is to help you succeed.   :}