draft-ietf-dhc-agent-vpn-id-02.txt   draft-ietf-dhc-agent-vpn-id-03.txt 
Network Working Group Kim Kinnear Network Working Group Kim Kinnear
INTERNET DRAFT Mark Stapp INTERNET DRAFT Mark Stapp
Richard Johnson Richard Johnson
Jay Kumarasamy Jay Kumarasamy
Cisco Systems Cisco Systems
November 2002 February 2005
Expires May 2003 Expires July 2005
VPN Identifier sub-option Virtual Subnet Selection Sub-Option
for the Relay Agent Information Option for the Relay Agent Information Option
<draft-ietf-dhc-agent-vpn-id-02.txt> <draft-ietf-dhc-agent-vpn-id-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
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
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
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 VPNs. If one DHCP server wishes which also has access to one or more virtual private networks (VPNs).
to offer service to DHCP clients on those different VPNs the DHCP If one DHCP server wishes to offer service to DHCP clients on those
server needs to know the VPN on which each client resides. The vpn- different VPNs the DHCP server needs to know information about the
id sub-option of the relay-agent-information option is used by the VPN on which each client resides. The virtual-subnet-selection sub-
relay agent to tell the DHCP server the VPN for every DHCP request it option of the relay-agent-information option is used by the relay
passes on to the DHCP server, and is also used to properly forward agent to tell the DHCP server important information about the VPN
any DHCP reply that the DHCP server sends back to the relay agent. (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.
1. Introduction 1. Introduction
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 this information in the relay-agent- client and could include information about the VPN in the relay-
information option in the client's DHCP requests. This document agent-information option in the client's DHCP requests. This informa-
defines a sub-option for the relay-agent-information option which tion about the VPN is called the Virtual Subnet Selection informa-
contains the vpn-id, and which allows the relay agent to communicate tion, or VSS information. This document defines a sub-option for the
the VPN association to the DHCP server. relay-agent-information option which contains this VSS information,
and which allows the relay agent to communicate the VSS 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 for-
warding back to the DHCP client, the relay agent will also need to warding back to the DHCP client, the relay agent will also need to
use the vpn-id sub-option to determine to which VPN to send the DHCP use the virtual-subnet-selection sub-option to determine to which VPN
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 vpn-id sub-option to the relay agent in the VPN by sending the virtual-subnet-selection sub-option in the relay-
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:
+--------+ +---------------+ +--------+ +---------------+
| DHCP | IP x| Relay Agent | IP z | DHCP | IP x| Relay Agent | IP z
| Server |-.......-| and +---+-------+-------+ | Server |-.......-| and +---+-------+-------+
+--------+ | VPN manager | | | | +--------+ | VPN manager | | | |
+---+-----------+ | | | +---+-----------+ | | |
|IP y +-----+ +--+--+ +--+--+ |IP y +-----+ +--+--+ +--+--+
+-+-----+ |Host1| |Host2| |Host3| +-+-----+ |Host1| |Host2| |Host3|
skipping to change at page 3, line 4 skipping to change at page 3, line 21
+---+-----------+ | | | +---+-----------+ | | |
|IP y +-----+ +--+--+ +--+--+ |IP y +-----+ +--+--+ +--+--+
+-+-----+ |Host1| |Host2| |Host3| +-+-----+ |Host1| |Host2| |Host3|
| | +-----+ +-----+ +-----+ | | +-----+ +-----+ +-----+
| | | |
+-----+ +--+--+ VPN 2 +-----+ +--+--+ VPN 2
|Host1| |Host2| |Host1| |Host2|
+-----+ +-----+ +-----+ +-----+
VPN 1 VPN 1
In this architecture, the relay agent knows the VPN for each of the In this architecture, the relay agent knows the VPN for each of the
DHCP clients, and inserts that information in the vpn-id sub-option DHCP clients, and inserts the VSS information about the VPN in the
in every DHCP request it forwards onto the DHCP server. virtual-subnet-selection sub-option in every DHCP request it forwards
on to the DHCP server.
When the DHCP server copies over the relay-agent-information option When the DHCP server copies over the relay-agent-information option
from the request to the reply packet, it will copy over the vpn-id from the request to the reply packet, it will copy over the virtual-
sub-option as well. subnet-selection sub-option as well.
When the relay agent receives a DHCP reply packet from the server When the relay agent receives a DHCP reply packet from the server
with a vpn-id sub-option, it will forward the packet onto the proper with a virtual-subnet-selection sub-option, it will forward the
VPN based on the value of the vpn-id sub-option. packet onto the proper VPN based on the VSS information in the
virtual-subnet-selection sub-option.
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"
skipping to change at page 3, line 50 skipping to change at page 4, line 26
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.
o "upstream" o "upstream"
Upstream is the direction from the subscriber towards the access Upstream is the direction from the subscriber towards the access
concentrator. concentrator.
o "VSS information"
Information about a VPN necessary to allocate an address to a
DHCP client on that VPN and necessary to forward a DHCP reply
packet to a DHCP client on that VPN.
o "VPN" o "VPN"
Virtual private network. A network which appears to the client Virtual private network. A network which appears to the client
to be a private network. to be a private network.
o "VPN Identifier" o "VPN Identifier"
The VPN-ID is defined by [RFC2685] to be a sequence of 14 hex The VPN-ID is defined by [RFC2685] to be a sequence of 14 hex
digits. digits.
3. VPN identifier sub-option definition 3. Virtual Subnet Selection Sub-Option Definition
The vpn-id sub-option MAY be used by any DHCP relay agent which The virtual-subnet-selection sub-option MAY be used by any DHCP relay
desires to specify the VPN from which a DHCP client request was sent. agent which desires to specify the VSS information about a VPN from
which a DHCP client request was sent.
The vpn-id sub-option contains a generalized VPN identifier. The virtual-subnet-selection sub-option contains a generalized way to
specify the VSS information about a VPN.
The format of the option is: The format of the option is:
SubOpt Len Type VPN identifier SubOpt Len Type VPN identifier
+------+------+------+------+------+------+--- +------+------+------+------+------+------+---
| TBD | n | t | id1 | id2 | id3 | ... | TBD | n | t | id1 | id2 | id3 | ...
+------+------+------+------+------+------+--- +------+------+------+------+------+------+---
Type: 0 NVT ASCII VPN identifier Type: 0 NVT ASCII VPN identifier
1 RFC2685 VPN-ID 1 RFC2685 VPN-ID
2-255 Not Allowed 2-255 Not Allowed
There are two types of identifiers which can be placed in the vpn-id There are two types of identifiers which can be placed in the
sub-option. The first type of identifier which can be placed in the virtual-subnet-selection sub-option. The first type of identifier
vpn-id sub-option is an NVT ASCII string. It MUST NOT be terminated which can be placed in the virtual-subnet-selection sub-option is an
with a zero byte. NVT ASCII string. It MUST NOT be terminated with a zero byte.
The second type of identifier which can be placed in the vpn-id sub- The second type of identifier which can be placed in the virtual-
option is an RFC2685 VPN-ID [RFC 2685], which is typically 14 hex subnet-selection sub-option is an RFC2685 VPN-ID [RFC 2685], which is
digits in length (though it can be any length as far as the vpn-id typically 14 hex digits in length (though it can be any length as far
sub-option is concerned). as the virtual-subnet-selection sub-option is concerned).
All other values of the type field are invalid as of this memo and
VSS sub-options containing any other value than zero (0) or one (1)
SHOULD be ignored.
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 vpn-id sub-option in the relay-agent-information VPN SHOULD include a virtual-subnet-selection sub-option in the
option that it inserts in the DHCP packet prior to forwarding it on relay-agent-information option that it inserts in the DHCP packet
to the DHCP server. prior to forwarding it on to the DHCP server.
The value placed in the vpn-id sub-option SHOULD be sufficient for The value placed in the virtual-subnet-selection sub-option SHOULD be
the relay agent to properly route any DHCP reply packet returned from sufficient for the relay agent to properly route any DHCP reply
the DHCP server to the DHCP client for which it is destined. Servers packet returned from the DHCP server to the DHCP client for which it
supporting this sub-option MUST return an identical copy of the sub- is destined. Servers supporting this sub-option MUST return an
option in the relay-agent-info option to any relay-agent that sends instance of this sub-option in the relay-agent-info option to any
it. relay-agent that sends it. 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 vpn-id option and a vpn-id sub-option are both In the event that a virtual-subnet-selection option and a virtual-
received in a particular DHCP client packet, the information from the subnet-selection sub-option are both received in a particular DHCP
vpn-id sub-option MUST be used in preference to the information in client packet, the information from the virtual-subnet-selection
the vpn-id option. sub-option MUST be used in preference to the information in the
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
with this sub-option included. Rather, the expectation is that the
relay agent will use whatever algorithm that it used on the DHCPDIS-
COVER and DHCPREQUEST packets to decide to include this sub-option on
the DHCPOFFER and DHCPACK packets to decide if they MUST have this
sub-option included in their relay-agent-info options.
In some cases, a DHCP server may use the vpn-id sub-option to inform In some cases, a DHCP server may use the virtual-subnet-selection
a relay agent that a particular DHCP client is associated with a par- sub-option to inform a relay agent that a particular DHCP client is
ticular VPN. It does this by sending the vpn-id sub-option with the associated with a particular VPN. It does this by sending the
appropriate information to the relay agent in the relay-agent- virtual-subnet-selection sub-option with the appropriate information
information option. If the relay agent is unable to honor the DHCP to the relay agent in the relay-agent-information option. If the
server's requirement to place the DHCP client into that VPN it MUST relay agent is unable to honor the DHCP server's requirement to place
drop the packet and not send it back to the DHCP client. the DHCP client into that VPN it MUST drop the packet and not send it
to the DHCP client.
This sub-option SHOULD NOT be used without also making use of some
form of authentication for relay-agent-information option.
4. Security 4. Security
Message authentication in DHCP for intradomain use where the out-of- Message authentication in DHCP for intradomain use where the out-of-
band exchange of a shared secret is feasible is defined in [RFC band exchange of a shared secret is feasible is defined in [RFC
3118]. Potential exposures to attack are discussed in section 7 of 3118]. Potential exposures to attack are discussed in section 7 of
the DHCP protocol specification in [RFC 2131]. the DHCP protocol specification in [RFC 2131].
The vpn-id sub-option could be used by a client in order to obtain an The virtual-subnet-selection sub-option could be used by a client in
IP address from a VPN other than the one on which it resides. This order to obtain an IP address from a VPN other than the one on which
attack can be partially prevented by the relay agent not forwarding it resides. This attack can be partially prevented by the relay
any DHCP packet which already contains a relay-agent-information agent not forwarding any DHCP packet which already contains a relay-
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 dif-
ferent VPN, but since the DHCP server cannot (in general) communicate ferent VPN, but since the DHCP server cannot (in general) communicate
directly back to the program that sent in the malicious DHCP packet, directly back to the program that sent in the malicious DHCP packet,
the entire cycle of creating a lease will not be completed. Cer- the entire cycle of creating a lease will not be completed. Cer-
tainly many leases could be offered, which would result in a form of tainly many leases could be offered, which would result in a tem-
address-pool exhaustion. poraty form of address-pool exhaustion.
Servers that implement the vpn-id sub-option MUST by default disable Servers that implement the virtual-subnet-selection sub-option MUST
use of the feature; it must specifically be enabled through confi- by default disable use of the feature; it must specifically be
guration. Moreover, a server SHOULD provide the ability to selec- enabled through configuration. Moreover, a server SHOULD provide the
tively enable use of the feature under restricted conditions, e.g., ability to selectively enable use of the feature under restricted
by enabling use of the option only from explicitly configured conditions, e.g., by enabling use of the option only from explicitly
client-ids, enabling its use only by clients on a particular subnet, configured client-ids, enabling its use only by clients on a particu-
or restricting the VPNs from which addresses may be requested. lar subnet, or restricting the VPNs from which addresses may 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 vpn-id This document defines a number space for the type byte of the
sub-option. Certain allowable values for this byte are defined in virtual-subnet-selection sub-option. Certain allowable values for
this specification (see Section 3). New values may only be defined this byte are defined in this specification (see Section 3). New
by IETF Consensus, as described in [RFC 2434]. Basically, this means values may only be defined by IETF Consensus, as described in [RFC
that they are defined by RFCs approved by the IESG. 2434]. Basically, this means that they are defined by RFCs approved
by the IESG.
Moreover, any changes or additions to the type byte codes MUST be Moreover, any changes or additions to the type byte codes MUST be
made concurrently in the type byte codes of the vpn-id option. The made concurrently in the type byte codes of the virtual-subnet-
type bytes and data formats of the vpn-id option and vpn-id sub- selection option. The type bytes and data formats of the virtual-
option MUST always be identical. subnet-selection option and virtual-subnet-selection sub-option MUST
always be identical.
6. Acknowledgments 6. Acknowledgments
None (yet). None.
7. References 7. Normative References
[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 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor
Extensions", Internet RFC 2132, March 1997. Extensions", Internet RFC 2132, March 1997.
skipping to change at page 7, line 10 skipping to change at page 8, line 11
3046, January 2001. 3046, January 2001.
[RFC 3118] Droms, R. "Authentication for DHCP Messages", RFC 3118, [RFC 3118] Droms, R. "Authentication for DHCP Messages", RFC 3118,
June 2001. June 2001.
8. Author's information 8. Author's information
Kim Kinnear Kim Kinnear
Mark Stapp Mark Stapp
Cisco Systems Cisco Systems
250 Apollo Drive 1414 Massachusetts Ave.
Chelmsford, MA 01824 Boxborough, Massachusetts 01719
Phone: (978) 497-8000 Phone: (978) 936-0000
EMail: kkinnear@cisco.com EMail: kkinnear@cisco.com
mjs@cisco.com mjs@cisco.com
Jay Kumarasamy Jay Kumarasamy
Richard Johnson Richard Johnson
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
skipping to change at page 7, line 46 skipping to change at page 8, line 47
identify any such rights. Information on the IETF's procedures with identify any such rights. Information on the IETF's procedures with
respect to rights in standards-track and standards-related documentation respect to rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made available for 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 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 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 the use of such proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat. specification can be obtained from the IETF Secretariat.
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
which may cover technology that may be required to practice this stan- which may cover technology that may be required to practice this
dard. Please address the information to the IETF Executive Director.
10. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. standard. Please address the information to the IETF Executive Direc-
tor.
This document and translations of it may be copied and furnished to oth- 10. Full Copyright Statement
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet Stan-
dards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be Copyright (C) The Internet Society (2005). This document is subject to
revoked by the Internet Society or its successors or assigns. the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
This document and the information contained herein is provided on an "AS This document and the information contained herein are provided on an
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA-
NESS FOR A PARTICULAR PURPOSE. TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/