draft-ietf-dhc-agent-vpn-id-01.txt   draft-ietf-dhc-agent-vpn-id-02.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
March 2002 November 2002
Expires August 2002 Expires May 2003
VPN Identifier sub-option VPN Identifier sub-option
for the Relay Agent Information Option for the Relay Agent Information Option
<draft-ietf-dhc-agent-vpn-id-01.txt> <draft-ietf-dhc-agent-vpn-id-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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.
skipping to change at page 5, line 28 skipping to change at page 5, line 28
In some cases, a DHCP server may use the vpn-id sub-option to inform In some cases, a DHCP server may use the vpn-id sub-option to inform
a relay agent that a particular DHCP client is associated with a par- a relay agent that a particular DHCP client is associated with a par-
ticular VPN. It does this by sending the vpn-id sub-option with the ticular VPN. It does this by sending the vpn-id sub-option with the
appropriate information to the relay agent in the relay-agent- appropriate information to the relay agent in the relay-agent-
information option. If the relay agent is unable to honor the DHCP information option. If the relay agent is unable to honor the DHCP
server's requirement to place the DHCP client into that VPN it MUST server's requirement to place the DHCP client into that VPN it MUST
drop the packet and not send it back to the DHCP client. drop the packet and not send it back to the DHCP client.
4. Security 4. Security
DHCP currently provides no authentication or security mechanisms. Message authentication in DHCP for intradomain use where the out-of-
Potential exposures to attack are discussed is section 7 of the pro- band exchange of a shared secret is feasible is defined in [RFC
tocol specification [RFC2131]. The vpn-id sub-option could allow a 3118]. Potential exposures to attack are discussed in section 7 of
program masquerading as a relay agent to obtain addresses on other the DHCP protocol specification in [RFC 2131].
VPNs than the one on which it resides, possibly aiding in an
address-pool exhaustion attack on that VPN.
This attack can be partially prevented by the relay agent not for- The vpn-id sub-option could be used by a client in order to obtain an
warding any DHCP packet which already contains a relay-agent- IP address from a VPN other than the one on which it resides. This
information option. Any program which unicasts a DHCP packet to the attack can be partially prevented by the relay agent not forwarding
DHCP server with a relay-agent-information option in it with a vpn-id any DHCP packet which already contains a relay-agent-information
for a different VPN would cause the DHCP server to allocate an option.
address from that different VPN, but since the DHCP server cannot (in
general) communicate directly back to the program that sent in the
malicious DHCP packet, the entire cycle of creating a lease will not
be completed. Certainly many leases could be offered, which would
result in a form of address-pool exhaustion.
Under the current DHCP security model there are no methods available Any program which unicasts a DHCP packet to the DHCP server with a
to completely circumvent this type of attack. 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-
ferent VPN, but since the DHCP server cannot (in general) communicate
directly back to the program that sent in the malicious DHCP packet,
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
address-pool exhaustion.
Servers that implement the vpn-id sub-option MUST by default disable
use of the feature; it must specifically be enabled through confi-
guration. Moreover, a server SHOULD provide the ability to selec-
tively enable use of the feature under restricted conditions, e.g.,
by enabling use of the option only from explicitly configured
client-ids, enabling its use only by clients on a particular 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 vpn-id
sub-option. Certain allowable values for this byte are defined in sub-option. Certain allowable values for this byte are defined in
this specification (see Section 3). New values may only be defined this specification (see Section 3). New values may only be defined
skipping to change at page 6, line 39 skipping to change at page 6, line 46
[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.
[RFC 2685] Fox, B., Gleeson, B., "Virtual Private Networks Identif- [RFC 2685] Fox, B., Gleeson, B., "Virtual Private Networks Identif-
ier", Internet RFC 2685, September 1999. 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,
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 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 497-8000 Phone: (978) 497-8000
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
Phone: (408) 526-4000 Phone: (408) 526-4000
 End of changes. 

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