Subject: [secdir] SECDIR and OPSDIR review of draft-ietf-dhc-vpn-option-11

From: "David Harrington" <[email-masked]>
Date: Thu, 15 Oct 2009 11:32:55 -0400

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
[email-masked]
[email-masked]
[email-masked]

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 26 Oct 2009 16:24:19 -0500

David,

I'm a bit unsure to whom I should respond with 
answers to the questions you are asking.  Other folks
have included your questions in their responses.

Since you initially raised these questions, I'll
respond to you initially.

Thanks for the review of the draft.  

My comments below are indented, each preceded
by "Kim: ..."

I have mildly reformatted the comments you sent in,
as at least on my mail reader they seemed to wrap
in some strange way that made them extremely hard to
read.

Regards -- Kim

------------------------------------------------

At 10:32 AM 10/15/2009, David Harrington wrote:
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.

        Kim: I find this confusing.  The one new issue I raised
        in this draft (as opposed to referencing other drafts)
        was:

>   The VSS option could be used by a client in order to obtain an IP
>   address from any VPN.  This option would allow a client to perform a
>   more complete address-pool exhaustion attack since the client would
>   no longer be restricted to attacking address-pools on just its local
>   subnet.

        and I go on to suggest a way that relay agents can
        circumvent this attack -- which is certainly a mitigation
        mechanism in my book.

        So, I don't understand the source of this comment.

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.
        
        Kim: It is assumed that the relay agent is more "trusted"
        than the DHCP client in realistic deployments.  Thus, our
        choice to "trust" what the relay agent tells us is
        actually a security feature.

        Kim: I know all of the authors, and we know where the
        information came from, and it is all ok, so we don't have
        to disclaim anything.  Or did I get this wrong somehow?

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

        Kim: 
        In the real world, there are very few protocols that
        don't require you to deploy entities at both ends that
        support the protocol.  Of course, the specific situation
        in this draft is not quite that just described -- the
        problem is that an existing server which does not support
        the VSS sub-option will respond in such a way that the
        relay agent may have trouble determining if the server
        responded correctly or incorrectly.  Later in this email
        I suggest a way we can actually solve this problem
        by a slight extension of the draft.

        Kim: In the larger sense, you usually have to deploy
        matching support in client<->server ensembles to have
        things work correctly, so it isn't as if this is totally
        outlandish.  And "work correctly" is an interesting term.
        While things may appear to "work correctly" at the relay
        agent when someone deploys a relay agent that supports
        the VSS sub-option against a DHCP server who does support
        it, that is only a local misapprehension.  The ultimate
        client will not receive an IP address that will work.
        And so the failure will be noticed.   And this isn't
        an occasional failure -- the whole VPN won't work. 

      not being addressed:

        Kim: Well, yes.  Specifically.  That is because these
        scenarios do not describe configurations that today make
        any sense.  Trying to describe protocol actions for
        situations that make no operational sense today is akin
        to designing a protocol on speculation.  Something that
        at least our WG keeps a sharp eye out for and quashes
        whenever it is noticed.

        I could take out all these words, if that would make this
        less concerning, but then people will ask "what about this"
        or "what about that", and I'll have to put some of it back
        in.  

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

        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.

        Kim: Sorry, I'll say that they are reserved for future
        use.

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

        Kim: There is certainly a set of standard configurations
        which make sense, and I suppose that I've just assumed
        that they were obvious and/or well known by the folks
        that would read this document.  I expect that I can be
        more explicit about them so there is no doubt what
        they are, and I will do that.

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.

        Kim: I'll fix this.

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?

        Kim: Yes, I'll call them reserved.

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?

        Kim: I believe this is always true.  I don't
        believe there is any potential for conflict, or the
        underlying MPLS VPN capability wouldn't work at all.

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.

        Kim: Sub-sections would be a good idea here.  Diagrams
        are less clear to me, in that they all kind of look
        the same.  I'll see what I can do about diagrams, though.
        Perhaps sequence diagrams 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)?

        Kim: Legacy DHCP entities should ignore options (and
        sub-options) they don't understand.  Like this one.

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.

        Kim:  At one point, we had the relay agent deal
        with this, but someone objected so we took it out.
        Now the server deals with this case -- which is
        what Section 7.3 is all about.

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?

        Kim: Throughout the DHCP protocol world there is no
        general way (and scant specific ways) to determine
        who supports what options from the bits on the wire.
        In two of the three cases, this document makes that
        easy, in one of the three cases, this document
        makes that more difficult.  But later I propose to
        close even that hole.

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?

        Kim: Yes, the server will believe it is assigned, but the
        client will request again since it didn't get an address.
        In general DHCP drops packets, and relay agents don't
        synthesize things like DHCPRELEASE packets.

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?

        Kim: Interesting questions, and the answers are really
        outside of the scope of the document.  I don't know of
        any deployments where people request addresses on VPN's
        but don't "require" them.  All of the cases with which I
        am familiar they are required.  But we didn't want to
        preclude this possibility.  If you feel strongly, we
        could take this out.

10.  In section 5, it says "There are only two pieces of
information which can be determined ..." but the specified
behaviors could also result from mis-configuration, right?  And
the relay cannot tell whether it is a deliberate behavior or a
mis-configuration.

        Kim:  If you don't get it back, then the server didn't
        support it.  If it was supposed to support it, and
        someone misconfigured it, and it now doesn't support it,
        that is still not supporting it.  If you get a VPN
        sub-option back that is different than the one you sent
        in, then the server gave you an address on a different
        VPN.  If it wasn't supposed to, and was misconfigured to
        do so, well, it still did it.  So I don't see what you
        are driving at here, I'm sorry.

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?

        Kim: The idea was to look at internal tables,
        ARP for the address, or otherwise perform some
        kind of consistency check.  All very implementation
        dependent.

        Kim: Hmmm.  One approach might be to send in two VPN
        sub-options, one "real", and the other (specified in the
        document) as "to-be-removed".  Then, when someone did the
        right thing, they'd remove the one that was to-be-removed
        and return the one that was used.  Then if the relay
        agent got a to-be-removed sub-option back, it would know
        that this server didn't support the capability and could
        drop the packet.  I'll kick this around with the other
        authors, but this might be a way around the problem.

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, but 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 and resolutions
are covered adequately.

        Kim:  I don't know of a case that isn't covered.
        Maybe it is confusion about there "MUST NOT be
        any additional information...".  That is        
        in the option/sub-option with the 255, not
        the whole message.  I can clear that up.

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?

        Kim:: Some external configuration -- certainly
        something external to this document (in the 
        case where the DHCP server is trying to 
        drive the VPN selection).

        Kim: In the case where the server is responding
        to an incoming VPN option/sub-option, then it
        is obvious whoever sent it understands it.

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.

        Kim: Section 6 should be broadened to include relay
        agents acting on behalf of clients.

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?

        Kim: The server returned one, but typically the
        actual "end" DHCP clients aren't dealing with this,
        but the relay agents are.

        Can a return message contain multiple VSS options?  If I
        readthe 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.

        Kim: Correct, only one VSS option should come back
        from a server -- if you send in two, and get two back,
        it either doesn't support this (if they are sub-options),
        or it is broken.

David Harrington
[email-masked]
[email-masked]
[email-masked]