draft-ietf-dhc-agent-vpn-id-05.txt   draft-ietf-dhc-agent-vpn-id-06.txt 
dhc Working Group Kim Kinnear dhc Working Group Kim Kinnear
Internet Draft Mark Stapp Internet Draft Mark Stapp
Intended Status: Standards Track Richard Johnson Intended Status: Standards Track Richard Johnson
Expires: May 16, 2008 Jay Kumarasamy Expires: June 18, 2008 Jay Kumarasamy
Cisco Systems Cisco Systems
November 16, 2007 December 18, 2007
Virtual Subnet Selection Sub-Option Virtual Subnet Selection Sub-Option
for the Relay Agent Information Option for DHCPv4 for the Relay Agent Information Option for DHCPv4
<draft-ietf-dhc-agent-vpn-id-05.txt> <draft-ietf-dhc-agent-vpn-id-06.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 5, line 36 skipping to change at page 5, line 36
A relay agent which recieves a DHCP request from a DHCP client on a A relay agent which recieves a DHCP request from a DHCP client on a
VPN SHOULD include a Virtual Subnet Selection sub-option in the VPN SHOULD include a Virtual Subnet Selection sub-option in the
relay-agent-information option that it inserts in the DHCP packet relay-agent-information option that it inserts in the DHCP packet
prior to forwarding it on to the DHCP server. prior to forwarding it on to the DHCP server.
The value placed in the Virtual Subnet Selection sub-option SHOULD be The value placed in the Virtual Subnet Selection sub-option SHOULD be
sufficient for the relay agent to properly route any DHCP reply sufficient for the relay agent to properly route any DHCP reply
packet returned from the DHCP server to the DHCP client for which it packet returned from the DHCP server to the DHCP client for which it
is destined. Servers supporting this sub-option MUST return an is destined. Servers supporting this sub-option MUST return an
instance of this sub-option in the relay-agent-info option to any instance of this sub-option in the relay-agent-information option to
relay-agent that sends it. Servers SHOULD return the an exact copy any relay-agent that sends it if the server successfully uses this
of the sub-option unless they desire to change the VPN on which a sub-option to allocate the IP address and SHOULD NOT include this
client was configured, which would typically be a very unusual thing sub-option in the relay-agent-information option if the server was
to do. unable or not configured to support the requested VPN. If they echo
the sub-option, servers SHOULD return the an exact copy of the sub-
option unless they desire to change the VPN on which a client was
configured, which would typically be a very unusual thing to do.
In the event that a Virtual Subnet Selection option and a Virtual In the event that a Virtual Subnet Selection option and a Virtual
Subnet Selection sub-option are both received in a particular DHCP Subnet Selection sub-option are both received in a particular DHCP
client packet, the information from the Virtual Subnet Selection client packet, the information from the Virtual Subnet Selection
sub-option MUST be used in preference to the information in the sub-option MUST be used in preference to the information in the
Virtual Subnet Selection option. This reasoning behind this approach Virtual Subnet Selection option. This reasoning behind this approach
is that the relay-agent is almost certainly more trusted than the is that the relay-agent is almost certainly more trusted than the
DHCP client, and therefore information in the relay-agent-information DHCP client, and therefore information in the relay-agent-information
option that conflicts with information in the packet generated by the option that conflicts with information in the packet generated by the
DHCP client is more likely to be correct. DHCP client is more likely to be correct.
Relay agents which include this sub-option when forwarding DHCP Note that [RFC 3046] specifies that a DHCP server which supports the
client requests should probably discard DHCPOFFER or DHCPACK packets relay-agent-information option SHALL copy all suboptions received in
that do not contain this sub-option in their associated relay-agent- a relay-agent-information option into any outgoing relay-agent-
info options. This does not imply any memory of the particular information option. In the case of the Virtual Subnet Selection
packets forwarded with this sub-option included. Rather, the sub-option, if the server supports this sub-option and for some
expectation is that the relay agent will use whatever algorithm that reason (perhaps administrative control) does not honor this sub-
it used on the DHCPDISCOVER and DHCPREQUEST packets to decide to option from the request then it SHOULD NOT echo this sub-option in
include this sub-option on the DHCPOFFER and DHCPACK packets to the outgoing relay-agent-information option.
decide if they should have this sub-option included in their relay-
agent-info options. Because of the requirements of [RFC 3046], even a server which
doesn't implement support for Virtual Subnet Selection sub-option
will almost certainly copy it into the outgoing relay-agent-
information option. This means that the appearance of the Virtual
Subnet Selection sub-option in a relay-agent-information option
doesn't indicate support for the Virtual Subnet Selection sub-option.
The only information which can be determined from the appearance or
lack of appearance of the Virtual Subnet Selection sub-option in a
relay-agent-information option received by a relay agent from a DHCP
server is that if the Virtual Subnet Selection sub-option does not
appear, then the server was able to support this sub-option but chose
not to do so.
Since this sub-option is placed in the packet in order to change the Since this sub-option is placed in the packet in order to change the
VPN on which an IP address is allocated for a particular DHCP client, VPN on which an IP address is allocated for a particular DHCP client,
one presumes that an allocation on that VPN is necessary for correct one presumes that an allocation on that VPN is necessary for correct
operation. If this presumption is correct, then a relay agent which operation. The relay agent may choose to try to determine whether or
places this sub-option in a packet and doesn't receive it in the not the IP address that was allocated was from the correct VPN (and
returning packet should drop the packet since the IP address that was drop the packet if it was not) or to simply pass the packet along to
allocated will not be in the correct VPN. If an IP address that is the DHCP client and let the client operate to the extent possible.
on the requested VPN is not required, then the relay agent is free to
pass the packet along to the DHCP client with the IP address that is
not on the VPN that the relay agent requested.
Servers that do not understand this option will allocate an address
using their normal algorithms and will not return this option in the
DHCPOFFER or DHCPACK. In this case the client should consider
discarding the DHCPOFFER or DHCPACK, as mentioned above. Servers
that understand this option but are administratively configured to
ignore the option MUST ignore the option, use their normal algorithms
to allocate an address, and MUST NOT return this option in the
DHCPOFFER or DHCPACK such that the client will know that the
allocated address is not in the VPN requested and will consider this
information in deciding whether or not to accept the DHCPOFFER. In
other words, this option MUST NOT appear in a DHCPOFFER or DHCPACK
from a server unless it was used by the server in making or updating
the address allocation requested.
In some cases, a DHCP server may use the Virtual Subnet Selection In some cases, a DHCP server may use the Virtual Subnet Selection
sub-option to inform a relay agent that a particular DHCP client is sub-option to inform a relay agent that a particular DHCP client is
associated with a particular VPN. It does this by sending the associated with a particular VPN. It does this by sending the
Virtual Subnet Selection sub-option with the appropriate information Virtual Subnet Selection sub-option with the appropriate information
to the relay agent in the relay-agent-information option. If the to the relay agent in the relay-agent-information option. If the
relay agent is unable to honor the DHCP server's requirement to place relay agent is unable to honor the DHCP server's requirement to place
the DHCP client into that VPN it MUST drop the packet and not send it the DHCP client into that VPN it MUST drop the packet and not send it
to the DHCP client. to the DHCP client.
skipping to change at page 7, line 19 skipping to change at page 7, line 16
information into a DHCP client packet that it is forwarding, when a information into a DHCP client packet that it is forwarding, when a
relay-agent needs to submit a DHCP Leasequery packet to the DHCP relay-agent needs to submit a DHCP Leasequery packet to the DHCP
server in order to recover information about existing DHCP allocated server in order to recover information about existing DHCP allocated
IP addresses on other than the normal, global VPN, it SHOULD NOT use IP addresses on other than the normal, global VPN, it SHOULD NOT use
this sub-option. Instead, it SHOULD use the Virtual Subnet Selection this sub-option. Instead, it SHOULD use the Virtual Subnet Selection
option, since in the context of a DHCP Leasequery the relay agent is option, since in the context of a DHCP Leasequery the relay agent is
the client and is not relaying a packet for another DHCP client. the client and is not relaying a packet for another DHCP client.
4. Security 4. Security
Message authentication in DHCP relay agents as defined in [RFC 3040] Message authentication in DHCP relay agents as defined in [RFC 4030]
should be considered for relay agents employing this sub-option. should be considered for relay agents employing this sub-option.
Potential exposures to attack are discussed in section 7 of the DHCP Potential exposures to attack are discussed in section 7 of the DHCP
protocol specification in [RFC 2131]. protocol specification in [RFC 2131].
The Virtual Subnet Selection sub-option could be used by a DHCP The Virtual Subnet Selection sub-option could be used by a DHCP
client masquerading as a relay agent in order to obtain an IP address client masquerading as a relay agent in order to obtain an IP address
from a VPN other than the one on which it resides. The DHCP server from a VPN other than the one on which it resides. The DHCP server
processing for this sub-option should be aware of this possibility processing for this sub-option should be aware of this possibility
and use whatever techniques it can devise to prevent such an attack. and use whatever techniques it can devise to prevent such an attack.
Information such as the giaddr might be used to detect and prevent Information such as the giaddr might be used to detect and prevent
this sort of attack, as well as the use of The Authentication this sort of attack, as well as the use of The Authentication
Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay
Agent Option [RFC 3040]. Agent Option [RFC 4030].
Any program which unicasts a DHCP packet to the DHCP server with a Any program which unicasts a DHCP packet to the DHCP server with a
relay-agent-information option in it with a vpn-id for a different relay-agent-information option in it with a vpn-id for a different
VPN would cause the DHCP server to allocate an address from that VPN would cause the DHCP server to allocate an address from that
different VPN, but since the DHCP server cannot (in general) different VPN, but since the DHCP server cannot (in general)
communicate directly back to the program that sent in the malicious communicate directly back to the program that sent in the malicious
DHCP packet, the entire cycle of creating a lease will not be DHCP packet, the entire cycle of creating a lease will not be
completed. Certainly many leases could be offered, which would completed. Certainly many leases could be offered, which would
result in a temporary form of address-pool exhaustion. result in a temporary form of address-pool exhaustion.
skipping to change at page 9, line 16 skipping to change at page 9, line 12
[RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, October IANA Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[RFC 2685] Fox, B., Gleeson, B., "Virtual Private Networks [RFC 2685] Fox, B., Gleeson, B., "Virtual Private Networks
Identifier", RFC 2685, September 1999. Identifier", RFC 2685, September 1999.
[RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC [RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001. 3046, January 2001.
[RFC 3040] Stapp, M. and T. Lemon, "The Authentication Suboption for
the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option"
RFC 3040, March 2005.
[RFC 3942] Volz, B., "Reclassifying Dynamic Host Configuration [RFC 3942] Volz, B., "Reclassifying Dynamic Host Configuration
Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004. Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004.
[RFC 4030] Stapp, M. and T. Lemon, "The Authentication Suboption for
the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option"
RFC 4030, March 2005.
8. Authors' Addresses 8. Authors' Addresses
Kim Kinnear Kim Kinnear
Cisco Systems Cisco Systems
1414 Massachusetts Ave. 1414 Massachusetts Ave.
Boxborough, Massachusetts 01719 Boxborough, Massachusetts 01719
Phone: (978) 936-0000 Phone: (978) 936-0000
EMail: kkinnear@cisco.com EMail: kkinnear@cisco.com
skipping to change at page 11, line 4 skipping to change at page 10, line 45
might not be available; nor does it represent that it has made any might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79. 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an attempt assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be proprietary rights by implementers or users of this specification can be
obtained from the IETF on-line IPR repository at obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this that may cover technology that may be required to implement this
standard. Please address the information to the IETF at
ietf-ipr@ietf.org. standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
11. Acknowledgment 11. Acknowledgment
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
 End of changes. 12 change blocks. 
48 lines changed or deleted 46 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/