draft-ietf-dhc-agent-vpn-id-03.txt   draft-ietf-dhc-agent-vpn-id-04.txt 
Network Working Group Kim Kinnear Network Working Group Kim Kinnear
INTERNET DRAFT Mark Stapp Internet Draft Mark Stapp
Richard Johnson Intended Status: Standards Track Richard Johnson
Jay Kumarasamy Jay Kumarasamy
Cisco Systems Cisco Systems
February 2005 February 2007
Expires August 2007
Virtual Subnet Selection Sub-Option Virtual Subnet Selection Sub-Option
for the Relay Agent Information Option for the Relay Agent Information Option for DHCPv4
<draft-ietf-dhc-agent-vpn-id-03.txt> <draft-ietf-dhc-agent-vpn-id-04.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which I become aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with RFC 3668. 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The IETF Trust (2007).
Abstract Abstract
In some environments, a relay agent resides in a network element In some environments, a relay agent resides in a network element
which also has access to one or more virtual private networks (VPNs). which also has access to one or more virtual private networks (VPNs).
If one DHCP server wishes to offer service to DHCP clients on those If one DHCP server wishes to offer service to DHCP clients on those
different VPNs the DHCP server needs to know information about the different VPNs the DHCP server needs to know information about the
VPN on which each client resides. The virtual-subnet-selection sub- VPN on which each client resides. The virtual-subnet-selection sub-
option of the relay-agent-information option is used by the relay option of the relay-agent-information option is used by the relay
agent to tell the DHCP server important information about the VPN agent to tell the DHCP server important information about the VPN
skipping to change at page 2, line 22 skipping to change at page 2, line 24
There exist situations where there are multiple VPNs serviced by one There exist situations where there are multiple VPNs serviced by one
or more network elements which also contain relay agents. These or more network elements which also contain relay agents. These
VPNs contain DHCP clients, and there is a desire to allow one DHCP VPNs contain DHCP clients, and there is a desire to allow one DHCP
server to supply the full range of DHCP services to these DHCP server to supply the full range of DHCP services to these DHCP
clients. clients.
The network element which contains the relay agent typically is also The network element which contains the relay agent typically is also
the network element which knows about the VPN association of the DHCP the network element which knows about the VPN association of the DHCP
client and could include information about the VPN in the relay- client and could include information about the VPN in the relay-
agent-information option in the client's DHCP requests. This informa- agent-information option in the client's DHCP requests. This
tion about the VPN is called the Virtual Subnet Selection informa- information about the VPN is called the Virtual Subnet Selection
tion, or VSS information. This document defines a sub-option for the information, or VSS information. This document defines a sub-option
relay-agent-information option which contains this VSS information, for the relay-agent-information option which contains this VSS
and which allows the relay agent to communicate the VSS information information, and which allows the relay agent to communicate the VSS
to the DHCP server. information to the DHCP server.
When the DHCP server sends its response to the relay agent for for- When the DHCP server sends its response to the relay agent for
warding back to the DHCP client, the relay agent will also need to forwarding back to the DHCP client, the relay agent will also need to
use the virtual-subnet-selection sub-option to determine to which VPN use the virtual-subnet-selection sub-option to determine to which VPN
to send the DHCP response. to send the DHCP response.
This sub-option can also be used by the DHCP server to inform a relay This sub-option can also be used by the DHCP server to inform a relay
agent that a particular DHCP client is associated with a particular agent that a particular DHCP client is associated with a particular
VPN by sending the virtual-subnet-selection sub-option in the relay- VPN by sending the virtual-subnet-selection sub-option in the relay-
agent-information option back to the relay agent. agent-information option back to the relay agent.
Consider the following architecture: Consider the following architecture:
skipping to change at page 3, line 46 skipping to change at page 3, line 46
2. 2.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in RFC 2119 [RFC 2119].
This document uses the following terms: This document uses the following terms:
o "DHCP client" o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain confi- A DHCP client is an Internet host using DHCP to obtain
guration parameters such as a network address. configuration parameters such as a network address.
o "DHCP relay agent" o "DHCP relay agent"
A DHCP relay agent is a third-party agent that transfers BOOTP A DHCP relay agent is a third-party agent that transfers BOOTP
and DHCP messages between clients and servers residing on dif- and DHCP messages between clients and servers residing on
ferent subnets, per [RFC 951] and [RFC 1542]. different subnets, per [RFC 951] and [RFC 1542].
o "DHCP server" o "DHCP server"
A DHCP server is an Internet host that returns configuration A DHCP server is an Internet host that returns configuration
parameters to DHCP clients. parameters to DHCP clients.
o "downstream" o "downstream"
Downstream is the direction from the access concentrator towards Downstream is the direction from the access concentrator towards
the subscriber. the subscriber.
skipping to change at page 6, line 10 skipping to change at page 6, line 10
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. virtual-subnet-selection option.
Relay agents which include this sub-option when forwarding DHCP Relay agents which include this sub-option when forwarding DHCP
client requests MUST discard DHCPOFFER or DHCPACK packets that do not client requests MUST discard DHCPOFFER or DHCPACK packets that do not
contain this sub-option in their associated relay-agent-info options. contain this sub-option in their associated relay-agent-info options.
This does not imply any memory of the particular packets forwarded This does not imply any memory of the particular packets forwarded
with this sub-option included. Rather, the expectation is that the with this sub-option included. Rather, the expectation is that the
relay agent will use whatever algorithm that it used on the DHCPDIS- relay agent will use whatever algorithm that it used on the
COVER and DHCPREQUEST packets to decide to include this sub-option on DHCPDISCOVER and DHCPREQUEST packets to decide to include this sub-
the DHCPOFFER and DHCPACK packets to decide if they MUST have this option on the DHCPOFFER and DHCPACK packets to decide if they MUST
sub-option included in their relay-agent-info options. have this sub-option included in their relay-agent-info options.
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 6, line 42 skipping to change at page 6, line 42
the DHCP protocol specification in [RFC 2131]. the DHCP protocol specification in [RFC 2131].
The virtual-subnet-selection sub-option could be used by a client in 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 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 it resides. This attack can be partially prevented by the relay
agent not forwarding any DHCP packet which already contains a relay- agent not forwarding any DHCP packet which already contains a relay-
agent-information option. agent-information option.
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 dif- VPN would cause the DHCP server to allocate an address from that
ferent VPN, but since the DHCP server cannot (in general) communicate different VPN, but since the DHCP server cannot (in general)
directly back to the program that sent in the malicious DHCP packet, communicate directly back to the program that sent in the malicious
the entire cycle of creating a lease will not be completed. Cer- DHCP packet, the entire cycle of creating a lease will not be
tainly many leases could be offered, which would result in a tem- completed. Certainly many leases could be offered, which would
poraty form of address-pool exhaustion. result in a temporaty form of address-pool exhaustion.
Servers that implement the virtual-subnet-selection sub-option MUST Servers that implement the virtual-subnet-selection sub-option MUST
by default disable use of the feature; it must specifically be by default disable use of the feature; it must specifically be
enabled through configuration. Moreover, a server SHOULD provide the enabled through configuration. Moreover, a server SHOULD provide the
ability to selectively enable use of the feature under restricted ability to selectively enable use of the feature under restricted
conditions, e.g., by enabling use of the option only from explicitly conditions, e.g., by enabling use of the option only from explicitly
configured client-ids, enabling its use only by clients on a particu- configured client-ids, enabling its use only by clients on a
lar subnet, or restricting the VPNs from which addresses may be particular subnet, or restricting the VPNs from which addresses may
requested. be requested.
5. IANA Considerations 5. IANA Considerations
IANA has assigned the value of TBD for the VPN Identifier sub-option 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 from the DHCP Relay Agent Sub-options space [RFC 3046] for the VPN
Identifier sub-option defined in Section 3. Identifier sub-option defined in Section 3.
This document defines a number space for the type byte of the This document defines a number space for the type byte of the
virtual-subnet-selection sub-option. Certain allowable values for virtual-subnet-selection sub-option. Certain allowable values for
this byte are defined in this specification (see Section 3). New this byte are defined in this specification (see Section 3). New
skipping to change at page 7, line 34 skipping to change at page 7, line 34
selection option. The type bytes and data formats of the virtual- selection option. The type bytes and data formats of the virtual-
subnet-selection option and virtual-subnet-selection sub-option MUST subnet-selection option and virtual-subnet-selection sub-option MUST
always be identical. always be identical.
6. Acknowledgments 6. Acknowledgments
None. None.
7. Normative References 7. Normative References
[RFC 951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985.
[RFC 1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protol", RFC 1542, October 1993.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor [RFC 2685] Fox, B., Gleeson, B., "Virtual Private Networks
Extensions", Internet RFC 2132, March 1997. Identifier", Internet RFC 2685, September 1999.
[RFC 2685] Fox, B., Gleeson, B., "Virtual Private Networks Identif-
ier", Internet 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 3118] Droms, R. "Authentication for DHCP Messages", RFC 3118, 8. Authors' Addresses
June 2001.
8. Author's information
Kim Kinnear Kim Kinnear
Mark Stapp Mark Stapp
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 8, line 30 skipping to change at page 8, line 30
Richard Johnson Richard Johnson
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
Phone: (408) 526-4000 Phone: (408) 526-4000
EMail: jayk@cisco.com EMail: jayk@cisco.com
raj@cisco.com raj@cisco.com
9. Intellectual Property Statement 9. Full Copyright Statement
The IETF takes no position regarding the validity or scope of any intel- Copyright (C) The IETF Trust (2007).
lectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in this document
or the extent to which any license under such rights might or might not
be available; neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's procedures with
respect to rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made available for
publication and any 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 proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any This document is subject to the rights, licenses and restrictions
copyrights, patents or patent applications, or other proprietary rights contained in BCP 78, and except as set forth therein, the authors retain
which may cover technology that may be required to practice this all their rights.
standard. Please address the information to the IETF Executive Direc- This document and the information contained herein are provided on an
tor. "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
10. Full Copyright Statement 10. Intellectual Property
Copyright (C) The Internet Society (2005). This document is subject to The IETF takes no position regarding the validity or scope of any
the rights, licenses and restrictions contained in BCP 78, and except as Intellectual Property Rights or other rights that might be claimed to
set forth therein, the authors retain all their rights. pertain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; nor does it represent that it has made any
independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79.
This document and the information contained herein are provided on an Copies of IPR disclosures made to the IETF Secretariat and any
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR assurances of licenses to be made available, or the result of an attempt
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET made to obtain a general license or permission for the use of such
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, proprietary rights by implementers or users of this specification can be
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- obtained from the IETF on-line IPR repository at
TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF http://www.ietf.org/ipr.
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this
standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
11. Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 24 change blocks. 
68 lines changed or deleted 71 lines changed or added

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