Subject: [savi] I-D Action: draft-ietf-savi-dhcp-24.txt

From: [email-masked]
Date: Mon, 05 May 2014 02:18:48 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Source Address Validation Improvements Working Group of the IETF.

        Title           : SAVI Solution for DHCP
        Authors         : Jun Bi
                          Jianping Wu
                          Guang Yao
                          Fred Baker
	Filename        : draft-ietf-savi-dhcp-24.txt
	Pages           : 43
	Date            : 2014-05-05

Abstract:
   This document specifies the procedure for creating a binding between
   a DHCPv4/DHCPv6 assigned IP address and a binding anchor on a SAVI
   (Source Address Validation Improvements) device.  The bindings set up
   by this procedure can be used to filter out packets with forged
   source IP address in DHCP scenario.  This mechanism is proposed as a
   complement to ingress filtering to provide finer-grained source IP
   address validation.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-savi-dhcp/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-savi-dhcp-24

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-24

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Leaf Yeh" <[email-masked]>
Date: Mon, 26 May 2014 18:51:19 +0800

After reading section 6.4 - 'The State Machine of DHCP Snooping Process' of
this draft again, I still need more clarification on it.

#1. 
I am not sure about the reason why the binding entry need necessarily to
record the TID-Transaction ID of the DHCPv6 message.

<quote> @ section 4.2 of RFC3315
        transaction ID            An opaque value used to match responses
                                with replies initiated either by a
                                client or server.
</quote>
<quote> @ section 15.1 of RFC3315
   The "transaction-id" field holds a value used by clients and servers
   to synchronize server responses to client messages.  A client SHOULD
   generate a random number that cannot easily be guessed or predicted
   to use as the transaction ID for each new message it sends.  ...  A
client MUST leave the transaction
   ID unchanged in retransmissions of a message.
</quote>

To my understanding on DHCPv6, the TID of Renew should be a different one as
that of Request.

If the entry in the BST-binding state table includes the field of TID, 
when the VP-Validating Port of SAVI switch receives a Renew message with a
new TID, it needs to update the binding entry with a new TID;
then the TP-Trust Port of SAVI switch receives the Reply message responding
from the server, the reply message could pass the TID check defined in
section 6.3.2 in this draft, <quote>... only if a DHCP message can pass the
following checks, the
   corresponding event is regarded as a valid event:...
   o   TID check: the DHCP Server-Client/Client-Server messages which
       may cause modification on existing binding entries must have
       matched TID with the corresponding entry. ...
</quote>

Right? Moreover, the SAVI switch also need to check the client ID in the
reply message? These sounds a little complex in the implementation, but the
binding entry in the SAVI table could focus on the data packet filtering.

#2. 
<quote> @ section 6.4.2.2 of this draft
   If the status code is "Success", the SAVI device checks the IA
   options in the Reply message.
   ...If the
   SAVI device does not send the LEASEQUERY message, a pre-configured
   lifetime DHCP_DEFAULT_LEASE MUST be set on the corresponding entry.
</quote>

Do we have a recommended value for ' DHCP_DEFAULT_LEASE '? It sounds the
server shall set the value of T1 for some IAs less than DHCP_DEFAULT_LEASE
to guarantee the client sent Renew before the BOND state expired.

#3. 
If a DHCPv6 client physically moves from SAVI-switch-1 to SAVI-switch-2 in
the same broadcasting domain, how to use the Confirm->Reply messages to
remove the binding entry in the SAVI-switch-1 to preserve the coherency in
the same broadcasting domain?

Best Regards,
Leaf

-----Original Message-----
From: savi [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, May 05, 2014 5:19 PM
To: [email-masked]
Cc: [email-masked]
Subject: [savi] I-D Action: draft-ietf-savi-dhcp-24.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Source Address Validation Improvements
Working Group of the IETF.

Abstract:

_______________________________________________
savi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/savi