Subject: [dhcwg] dhc wg last call on vpn-option and agent-vpn-id drafts

From: Stig Venaas <[email-masked]>
Date: Tue, 10 Jul 2007 15:08:58 +0200

This message announces a wg last call on two drafts. They are

Virtual Subnet Selection Option <draft-ietf-dhc-vpn-option-06.txt>

and

Virtual Subnet Selection Sub-Option for the Relay Agent Information 
Option for DHCPv4 <draft-ietf-dhc-agent-vpn-id-04.txt>

The last call will conclude at 1700EST on Sun, 2007-07-22.

Please respond to this WG last call.  If you support acceptance of the
documents without change, respond with a simple acknowledgment, so that
support for the documents can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the documents will not be advanced
to the IESG.

draft-ietf-dhc-vpn-option defines a new DHCP option for passing Virtual
Subnet Selection (VSS) information between the DHCP client and the DHCP
server.  It is intended for use primarily by DHCP proxy clients in
situations where VSS information needs to be passed to the DHCP server
for proper address allocation to take place.  This document documents
option usage in line with the option reclassification in RFC 3942.
This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-06.txt

draft-ietf-dhc-agent-vpn-id defines a new relay-agent-information option
sub-option used by a relay agent to tell the DHCP server important
information about the VPN (called the Virtual Subnet Selection
information, or VSS) for every DHCP request it passes on to the DHCP
server, and is also used to properly forward any DHCP reply that the
DHCP server sends back to the relay agent.
This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-vpn-id-04.txt

Stig

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 15 Jul 2007 10:35:51 -0400

Some comments on draft-ietf-dhc-vpn-option-06.txt (and also on
draft-ietf-dhc-agent-vpn-id-04.txt below):

1. I'm not sure why the document uses TBD for the option code when it
clearly should be using 221 as that it what the document is requesting -
that 221 be allocated for this option. This applies to all TBD usages in
the document.

2. In section 1. Introduction, 2nd paragraph:

   If the allocation is being done through a DHCP relay, then a relay
   suboption could be included.  In some cases, however an IP address is
   being sought by a DHCP proxy on behalf of a client (would may be
   assigned the address via a different protocol).  In this case, there
   is a need to include VSS information relating to the client as a DHCP
   option.

I don't understand what "would may be" means.

3. In section 1. Introduction, 3rd paragraph:

  addresses are acquired via DHCP and then given to the remove customer
                                                        ^^^^^^ ->
remote?

I also think PPP and IPCP should have references to the documents (or at
least be defined)?

4. In section 1. Introduction, 4th paragraph:

   This memo defines a new DHCP [2] option, the VSS Information option

Well, "This memo defines existing usage for the VSS Information option"?

As this is not a standard track document, I think it should be clear
that it is defining existing usage?

5. In section 3. VSS Information Definition

   The second type of identifier which can be placed in the VSS
   Information Option is an RFC2685 VPN-ID [4], which is typically 14
   hex digits in length (though it can be any length as far as the VSS
   Information Option is concerned).

   ...

   If the type field is set to one (1), it indicates that all following
   bytes should be interpreted in agreement with RFC2685 as a VPN
   Identifier, typically 14 hex digits.

This "14 hex digits in length" is a bit odd. I presume the 14 is decimal
and the hex digits are the ASCII representation of the digits (or are
they nibble encoded)? I think this should be clarified.

If we look at RFC 2685, it defines 7 octets of data (3 of VPN OUI
followed by 4 of VPN index). So, perhaps it would be best to specify
this as "7 octets of the RFC2685 VPN-ID"?

6. In section 3. VSS Information Definition

For clarity:

   In the event that a VSS Informmation Option and a VSS Information
   Relay Suboption are both received in a particular DHCP client packet,
   the information from the VSS Information Suboption MUST be used in
   preference to the information in the VSS Information Option.

Best if "VSS Information Suboption" was "VSS Information Relay
Suboption".

Though:
- draft-ietf-dhc-agent-vpn-id-04.txt uses "sub-option", not "suboption",
so perhaps sub-option should be used.
- draft-ietf-dhc-agent-vpn-id-04.txt also uses "Virtual Subnet Selection
sub-option" so perhaps the "Relay" part should be removed?
- I think a reference to the sub-option document should be added here
for the first usage?

7. Might be nice in section 2 or elsewhere to make a reference to the
terminology defined in draft-ietf-dhc-agent-vpn-id-04.txt?

NOTE: Some of the above comments also apply to
draft-ietf-dhc-agent-vpn-id-04.txt (such as the "14 hex digits" issue).

Some comments on draft-ietf-dhc-agent-vpn-id-04.txt (excluding the above
issues that also apply to it):

1. In the Abstract:

  If one DHCP server wishes to offer service to DHCP clients on those
     ^^^ -> replace with "a"?

Same in 1. Introduction:

   VPNs contain DHCP clients, and there is a desire to allow one DHCP
                                                             ^^^ a?
2. Section 2 should have a title? Terminology?

I also wonder whether the word "Internet" should be removed from the
definitions?

And:

      o "VPN Identifier"

        The VPN-ID is defined by [RFC 2685] to be a sequence of 14 hex
        digits.

Again, no where in 2685 is "14 hex digits" used. I'd use 7 octet
identifier?

3. In section 3. Virtual Subnet Selection Sub-option Definition

   The second type of identifier which can be placed in the virtual-
   subnet-selection sub-option is an RFC2685 VPN-ID [RFC 2685], which is
   typically 14 hex digits in length (though it can be any length as far
   as the virtual-subnet-selection sub-option is concerned).

The statement in parenthesis is rather odd as RFC 2685 clearly defines
this as 7-octets so why would this be useable for anything else. I think
it best if this text is removed.

4. General issue

This doucment is titled "Virtual Subnet Selection Sub-Option", yet in
the text it generally uses "virtual-subnet-selection sub-option".
Perhaps this should be consistent (either use the hyphen or capitalize?)
Note that the draft-ietf-dhc-vpn-option-06.txt justs used "Virtual
Subnet Selection" or "VSS information".

5. Here's a bit of an odd situation:

In section 3:

   In the event that a virtual-subnet-selection option and a virtual-
   subnet-selection sub-option are both received in a particular DHCP
   client packet, the information from the virtual-subnet-selection
   sub-option MUST be used in preference to the information in the
   virtual-subnet-selection option.

So, let's think this through ... The client adds the option and so does
the relay. The server uses the relay's option. Presumably, the server
doesn't echo the client's option. So, the client will IGNORE the
response from the server. Is this expected?

6. In 4. Security:

   The virtual-subnet-selection sub-option could be used by a client in
   order to obtain an IP address from a VPN other than the one on which
   it resides.  This attack can be partially prevented by the relay
   agent not forwarding any DHCP packet which already contains a relay-
   agent-information option.

No, the sub-option is NOT used by a client; it is used by the relay.

7. In 5. IANA Considerations:

8.  IANA Considerations

   IANA has assigned the value of TBD for the VPN Identifier sub-option
   from the DHCP Relay Agent Sub-options space [RFC 3046] for the VPN
   Identifier sub-option defined in Section 3.

Isn't IANA being REQUESTED to assign a value?

- Bernie

-----Original Message-----
From: Stig Venaas [mailto:[email-masked]] 
Sent: Tuesday, July 10, 2007 9:09 AM
To: dhcwg
Subject: [dhcwg] dhc wg last call on vpn-option and agent-vpn-id drafts

and

Stig

---

From: "David W. Hankins" <[email-masked]>
Date: Sun, 22 Jul 2007 14:54:43 -0500

> Virtual Subnet Selection Option <draft-ietf-dhc-vpn-option-06.txt>

Noting that Bernie has many fine points I will try not to repeat,

   All other values of the type field are invalid as of this memo and
   VSS options containing any other value than zero (0) or one (1)
   SHOULD be ignored.

We want old software to work with new protocol work, should there
ever be a document to assign new type codes.  So I don't understand
the motivation here to cause it to be ignored.  It's your existing
usage, I'm just curious why this was selected rather than allowing
operators to specify the contents by hand or such.

I would suggest simply removing this paragraph if it is not actually
documenting a current practice (in which case everyone really SHOULD
do more or less the same thing).

The Security section says:

   This option SHOULD NOT be used without also making use of the DHCP
   Authentication option [5].

But also says:

   DHCP relays MAY choose to remove the option before passing on
   DHCPDISCOVER packets.

I'm kind of confused.  You should use authentication, but relays MAY
break authentication by altering the client area of the packet?

If a relay strips this option, doesn't that just cause the client to
ignore the server (since it won't contain this option in its reply)?
Why not just drop the packet then?

I wonder if this option is used to assign overlapping address spaces
to different VPN's.  In that case, I wonder if it should contain
(even if there is no current practice) DHCPLEASEQUERY language, to
disambiguate queries.

Or I think possibly it should explicitly mention that the current
usage is not DHCPLEASEQUERY compatible?

> Option for DHCPv4 <draft-ietf-dhc-agent-vpn-id-04.txt>

I think the security section was cut and paste from the client
option.  It doesn't make sense to restrict relay processing to
specific clients served by that relay in this context.

> The last call will conclude at 1700EST on Sun, 2007-07-22.

Yes!  Under the wire!

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg