Hi,
I have reviewed this document as part of the Security Directorate's
ongoing effort to review all IETF documents being processed by the
IESG. ... AND ... I have performed an unofficial Operations
Directorate review.
(i.e., I wasn't assigned as the OPSDIR reviewer)
Background:
This memo defines a Virtual Subnet Selection (VSS) option for
DHCPv4
and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These
are intended for use by DHCP clients, relay agents, and proxy
clients
in situations where VSS information needs to be passed to the DHCP
server for proper address or prefix allocation to take place.
=========================
SECDIR Review
=========================
The security review comments were written primarily for the benefit of
the security area directors. Document editors and WG chairs should
treat these comments just like any other last call comments.
I found the security considerations section reasonably thorough.
Some of the considerations are of the form "there is this known
problem; you should do whatever you can to mitigate it."
I wonder if some specific mitigation mechanisms might have been
described and standardized.
In section 4, a relay agent can insert a VSS option into a client
request, and then remove it from the server response. I am a little
concerned that the server does not actually get to differentiate which
entity is making the VSS request, and the relay is thus masquerading
as the client.
=========================
OPSDIR Review Questions:
=========================
The operations review comments were written primarily for the benefit
of the OPS area directors. Document editors and WG chairs should
treat these comments just like any other last call comments.
I do not normally work at the DHCP level, so some of my comments may
simply be misunderstandings of DHCP.
Is the document readable?
yes.
Does it contain nits?
yes.
The document seems to lack a disclaimer for pre-RFC5378 work
Is the document class appropriate?
yes.
Is the problem well stated?
yes.
Is the problem really a problem?
yes.
Does the document consider existing solutions?
yes.
Does the solution break existing technology?
possibly.
1) Section 4 says "Deploying relay
agents which support and emit VSS sub-options in concert with
DHCPv4
servers which do not support the VSS option or sub-option as
defined
in this document SHOULD NOT be done, as such an ensemble will not
operate correctly together because all of the IP addresses will be
allocated from the global or default VPN regardless of the VPN on
which the client's reside."
2) I have concerns that there are potential conflicts that are
not
being addressed:
" There are many other scenarios which can be created with
multiple
relay agents each inserting VSS information into different Relay-
forward messages, relay agent VSS information conflicting with
client
VSS information, or DHCP server VSS information conflicting with
relay agent and client VSS information. Since these scenarios do
not
describe situations that are useful today, specifying precisely how
to resolve all of these conflicts is unlikely to be valuable in the
event that these scenarios actually become practical in the future.
The current use of the VSS option and sub-option require that each
entity knows the part that it plays in dealing with VPN data. Each
entity -- client, relay agent or agents, and server -- SHOULD know
through some policy or configuration beyond the scope of this
document whether it is responsible for specifying VPN information
using the VSS option or sub-option or responsible for responding to
VSS information specified by another entity, or simply ignoring any
VSS information which it might see.
Some simple conflict resolution approaches are discussed below, in
the hopes that they will cover simple cases that may arise from
scenarios beyond those envisioned today. However, for more complex
scenarios, or simple scenarios where appropriate conflict
resolution
strategies differ from those discussed in this document, a document
detailing the usage scenarios and appropriate conflict resolution
strategies SHOULD be created and submitted for discussion and
approval."
3) section 7 says " In either case above, care should be
taken to ensure that a client or
relay agent receiving a reply containing a VSS option will
correctly
understand the VSS option. Otherwise, the client or relay agent
will
end up using the address as though it were a global address."
This could have a negative impact on the existing network
deployment.
Does the solution preclude future activity?
yes. It declares the VPN types 2-254 to be invalid "as of this
memo", but doesn't
discuss how they could become valid in the future. The IANA
section seems to waffle
on whether it can or cannot be expanded in the future.
Is the solution sufficiently configurable?
There is quite a bit of text that says the entity "has been
configured in some way"
In some cases, the configuration MUST be done correctly for
the system to work, but the
configuration requirements are not detailed.
For example, Section 4 says "It is important to ensure
that
each entity ... is configured correctly."
and "There is no conflict between different entities trying to
specify
different VSS information -- each entity knows its role through
policy or configuration external to this document." and
"In the event that there
were more than one relay agent involved in this transaction, some
external configuration or policy would be needed to inform the
DHCPv6
server into which Relay-reply message the VSS option should go."
These sound like normative requirements, but there is no
attempt to standardize the configuration.
Can performance be measured? How?
performance measurement is not discussed.
Does the solution scale well?
I think this should scale as well as DHCP.
I suppose that the server might be expected to have lots of
storage if it needs to track the address
ranges for a large number of VPNs, but I don't think that
would be a limiting factor for a DHCP server.
general comments:
1. The Terminology section defines upstream and downstream using terms
that have not been defined.
It is unclear to me whether access concentrator and subscriber are
similar to server and client.
2. In section 3.4, might it be better to declare 2-254 as reserved
rather than invalid?
The text says "invalid as of this memo".
Should there be a mechanism to support enterprise-specific VSS?
3. In section 4, it says DHCP can assign the same IP address to nodes
in a VPN and in the global IP space, because the address is qualified
by the VPN. Is this always true? Is there any potential for conflict,
such as in forwarding loops, if the two addresses spaces are handled
by the same device?
4. I think section 4 would benefit from sub-sections to separate the
scenarios, and all the "in this scenario" phrases could be eliminated.
Diagrams of the scenarios would be helpful.
5. Will legacy DHCP entities ignore the VSS option by default? or will
the presence of the option somehow impact entity behaviors (e.g., by
dropping packets)?
6. In section 5, it says the relay SHOULD insert VSS information into
requests from a client. What happens if the client has inserted a VSS
option? That isn't discussed.
7. Section 5 says
"Anytime a relay agent places a VSS option or sub-option in a DHCP
request, it MUST send it only to a DHCP server which supports the
VSS
option or sub-option." How does it know? is there an option
discovery mechanism?
8. In section 5, if a relays requests a specific VPN, but the server
returns an address not within that VPN, then the relay should drop the
packet. Should the relay let the server know that it dropped the
packet and why? Won't the server assume the address has actually been
assigned to the client, thus reducing the pool of available addresses?
9. In section 5, "If an IP address that is
on the requested VPN is not required, then the relay agent is free
to
accept the IP address that is not on the VPN that was requested."
Then why request it?
Under what conditions would it not be required?
how does the relay know whether it is or is not required?
10. In section 5, it says "There are only two pieces of information
which can be determined ..."
but the speciied behaviors could also result from
mis-configuration, right?
And the relay cannot tell whether it is a deliberate behavior
or a mis-configuration.
11. section 5: " Thus, if a DHCPv4 relay agent has a requirement to
determine if the
address allocated by a DHCPv4 server is on a particular VPN, it
must
use some other approach than the appearance of the VSS sub-option
in
the reply packet to make this determination."
What other approach works?
12. section 5: " Note that in some environments a relay agent may
choose to always
place a VSS option or sub-option into packets and messages that it
forwards in order to forestall any attempt by a downstream relay
agent or client to specify VSS information. In this case, a type
field of 255 is used to denote the global, default VPN. When the
type field of 255 is used, there MUST NOT be any additional VSS
Information in the VSS option."
This section does not say that the relay must check to make
sure there is
no existing VSS option.
Section 5 talks about relays inserting VSS options, buit does
not specify that
the relay must check that no VSS=255 is present in the message
already.
But section 7.3 talks about resolving conflicting VSS options.
I am not sure the potential conflicts abd resolutions are
covered adequately.
13. section 5.1 what does "if the relay agent is unable to honor the
server requirement" mean?
This could be made less ambiguous.
14. section 5.1 " The DHCP server MUST NOT place VSS information in
an outgoing packet
if the relay agent or DHCP client is unprepared to properly
interpret
the VSS information." This seems ambiguous. How will the server
know if the other entities
can properly interpret the VSS information?
s/send in/insert/
15. section 4 says "The DHCP client, in this scenario, does not know
the VPN on which it resides."
section 6 says " A DHCPv4 or DHCPv6 client will employ the VSS
option to communicate
VSS information to their respective servers. This information MUST
be included in every message concerning any IP address on a
different
VPN than the global or default VPN."
these statements seem to conflict regarding the client's
knowledge.
16. section 6: " Clients should be aware that some DHCP servers will
return a VSS
option with different values than that which was sent in. In
addition, a client may receive a response from a DHCP server with a
VSS option when none was sent in by the Client."
So should subsequent messages from the client use the original
VSS information or
the server-returned or relay-returned VSS info?
Can a return message contain multiple VSS options? If I read
the document correctly,
multiple relays can add their own VSS options, and a server
typically copies all the
options. If a client is expected to include the VSS option
information in subsequent
messages, does it include multiple VSS options? The second
paragraph of 6 says that
is not allowed.
David Harrington
dbharrington(_at_)comcast(_dot_)net
ietfdbh(_at_)comcast(_dot_)net
dharrington(_at_)huawei(_dot_)com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf