< draft-ietf-savi-dhcp-33.txt		draft-ietf-savi-dhcp-34.txt >
	Source Address Validation Improvement J. Bi		Source Address Validation Improvement J. Bi
	Internet-Draft J. Wu		Internet-Draft J. Wu
	Intended status: Standards Track G. Yao		Intended status: Standards Track G. Yao
	Expires: August 16, 2015 Tsinghua Univ.		Expires: August 23, 2015 Tsinghua Univ.
	F. Baker		F. Baker
	Cisco		Cisco
	February 12, 2015		February 19, 2015
	SAVI Solution for DHCP		SAVI Solution for DHCP
	draft-ietf-savi-dhcp-33		draft-ietf-savi-dhcp-34
	Abstract		Abstract
	This document specifies the procedure for creating a binding between		This document specifies the procedure for creating a binding between
	a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source		a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source
	Address Validation Improvements (SAVI) device. The bindings set up		Address Validation Improvements (SAVI) device. The bindings set up
	by this procedure are used to filter packets with forged source IP		by this procedure are used to filter packets with forged source IP
	addresses. This mechanism complements BCP 38 ingress filtering,		addresses. This mechanism complements BCP 38 ingress filtering,
	providing finer-grained source IP address validation.		providing finer-grained source IP address validation.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	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."
	This Internet-Draft will expire on August 16, 2015.		This Internet-Draft will expire on August 23, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 7, line 4 ¶		skipping to change at page 7, line 4 ¶
	DHCP Server-to-Client message: A message that is sent from a DHCP		DHCP Server-to-Client message: A message that is sent from a DHCP
	server to a DHCP client. Such a message is of one of the following		server to a DHCP client. Such a message is of one of the following
	types:		types:
	o DHCPv4 ACK: DHCPACK [RFC2131]		o DHCPv4 ACK: DHCPACK [RFC2131]
	o DHCPv4 NAK: DHCPNAK [RFC2131]		o DHCPv4 NAK: DHCPNAK [RFC2131]
	o DHCPv4 Offer: DHCPOFFER [RFC2131]		o DHCPv4 Offer: DHCPOFFER [RFC2131]
	o DHCPv4 DHCPLEASEACTIVE: A response to a DHCPLEASEQUERY request.		o DHCPv4 DHCPLEASEACTIVE: A response to a DHCPLEASEQUERY request
	[RFC4388]		containing lease information. [RFC4388]
			o DHCPv4 DHCPLEASEUNKNOWN: A response to a DHCPLEASEQUERY request
			indicating that the server does not manage the address. [RFC4388]
			o DHCPv4 DHCPLEASEUNASSIGNED: A response to a DHCPLEASEQUERY request
			indicating that the server manages the address and there is no
			current lease. [RFC4388]
	o DHCPv6 Reply: REPLY [RFC3315]		o DHCPv6 Reply: REPLY [RFC3315]
	o DHCPv6 Advertise: ADVERTISE [RFC3315]		o DHCPv6 Advertise: ADVERTISE [RFC3315]
	o DHCPv6 Reconfigure: RECONFIGURE [RFC3315]		o DHCPv6 Reconfigure: RECONFIGURE [RFC3315]
	o DHCPv6 LEASEQUERY-REPLY: A response to a LEASEQUERY request.		o DHCPv6 LEASEQUERY-REPLY: A response to a LEASEQUERY request.
	[RFC5007]		[RFC5007]
	skipping to change at page 33, line 37 ¶		skipping to change at page 33, line 37 ¶
	EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message		EVE_DATA_CONFLICT: ARP Reply/Neighbor Advertisement(NA) message
	against an address in DETECTION state is received from a host other		against an address in DETECTION state is received from a host other
	than the one for which the entry was added (i.e., a host attached at		than the one for which the entry was added (i.e., a host attached at
	another point than the one on which the triggering data packet was		another point than the one on which the triggering data packet was
	received).		received).
	EVE_DATA_LEASEQUERY:		EVE_DATA_LEASEQUERY:
	o IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option		o IPv4: A DHCPLEASEACTIVE message with IP Address Lease Time option
	is received.		is received. Note that the DHCPLEASEUNKNOWN and
			DHCPLEASEUNASSIGNED replies are ignored.
	o IPv6: A successful LEASEQUERY-REPLY is received.		o IPv6: A successful LEASEQUERY-REPLY is received.
	EVE_DATA_VERIFY: An ARP Reply/Neighbor Advertisement(NA) message has		EVE_DATA_VERIFY: An ARP Reply/Neighbor Advertisement(NA) message has
	been received in the VERIFY state from the device connected to the		been received in the VERIFY state from the device connected to the
	attachment point on which the data packet was received.		attachment point on which the data packet was received.
	The triggering packet should pass the following checks to trigger a		The triggering packet should pass the following checks to trigger a
	valid event:		valid event:
	skipping to change at page 47, line 28 ¶		skipping to change at page 47, line 28 ¶
	(SOL_MAX_RT from [RFC3315])		(SOL_MAX_RT from [RFC3315])
	o MAX_LEASEQUERY_DELAY 10s Maximum LEASEQUERY timeout value		o MAX_LEASEQUERY_DELAY 10s Maximum LEASEQUERY timeout value
	(LQ_MAX_RT from [RFC5007])		(LQ_MAX_RT from [RFC5007])
	o DETECTION_TIMEOUT 0.5s Maximum duration of a hardware address		o DETECTION_TIMEOUT 0.5s Maximum duration of a hardware address
	verification step in the VERIFY state (TENT_LT from [RFC6620])		verification step in the VERIFY state (TENT_LT from [RFC6620])
	o DATA_SNOOPING_INTERVAL Minimum interval between two successive		o DATA_SNOOPING_INTERVAL Minimum interval between two successive
	EVE_DATA_UNMATCH events triggered by an attachment. 60s and		EVE_DATA_UNMATCH events triggered by an attachment. 60s and
	configurable (recommendation)		configurable. (recommendation)
	o OFFLINK_DELAY 30s Period after a client is last detected before		o OFFLINK_DELAY 30s Period after a client is last detected before
	the binding anchor being removed. (recommendation)		the binding anchor being removed. (recommendation)
	11. Security Considerations		11. Security Considerations
	11.1. Security Problems about the Data Snooping Process		11.1. Security Problems about the Data Snooping Process
	There are two security problems about the Data Snooping Process		There are two security problems about the Data Snooping Process
	Section 7:		Section 7:
End of changes. 7 change blocks.
	8 lines changed or deleted		16 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/