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

"Leaf Yeh" <leaf.yeh.sdo@gmail.com> Mon, 26 May 2014 10:51 UTC

Return-Path: <leaf.yeh.sdo@gmail.com>
X-Original-To: savi@ietfa.amsl.com
Delivered-To: savi@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF491A00DF for <savi@ietfa.amsl.com>; Mon, 26 May 2014 03:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NJBft65CWku for <savi@ietfa.amsl.com>; Mon, 26 May 2014 03:51:27 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386E11A00DE for <savi@ietf.org>; Mon, 26 May 2014 03:51:27 -0700 (PDT)
Received: by mail-pa0-f43.google.com with SMTP id hz1so7443728pad.2 for <savi@ietf.org>; Mon, 26 May 2014 03:51:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=Q+RsBuIDyypkjte6HRZ9P4ZgTNqTDX0BGzoj07/5AlA=; b=SX7LvyRokqiP/dng42lqAhmoGs23P21WBFaIhdFt1CnIKVubukMBbIH9bY92yOcVnJ L/+abn4KaXm3vuHrJ0y6FMQ64zJNNiBKZVkUH9S3Hf3EoV5jIpu3auFYGqOti0+H/wF9 mkUzx4JEbYVtrPiQz1eF8+CcpRhhIHYS3JIWKWqxYzT54j9ErgXohkwUah0IqAjRu7V/ h77u2mRl48QkQuDxvGEwTTWXjO2wXecLmWi33Dp6AyLosM6oPDDaQ6cNgefQY5SGlMtE zsCrAxxzwLeC1M/Z695ZCi/E+bqZZOJ9TGGiyJMYdvHOD0hbQ9U5JRx/f1c2XAlF+dUZ +SKQ==
X-Received: by 10.66.224.38 with SMTP id qz6mr9255848pac.153.1401101484488; Mon, 26 May 2014 03:51:24 -0700 (PDT)
Received: from PC ([218.241.103.194]) by mx.google.com with ESMTPSA id cj1sm56588763pac.40.2014.05.26.03.51.22 for <savi@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 26 May 2014 03:51:23 -0700 (PDT)
Message-ID: <53831cab.a1b0420a.1cbc.ffff9470@mx.google.com>
X-Google-Original-Message-ID: <002601cf78d0$6f1d5e00$4d581a00$@yeh.sdo@gmail.com>
From: Leaf Yeh <leaf.yeh.sdo@gmail.com>
To: savi@ietf.org
References: <20140505091848.12496.42827.idtracker@ietfa.amsl.com>
In-Reply-To: <20140505091848.12496.42827.idtracker@ietfa.amsl.com>
Date: Mon, 26 May 2014 18:51:19 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac9oQw0qCfx5UrtDQxGIuVCMXgqALAQcqndA
Content-Language: zh-cn
Archived-At: http://mailarchive.ietf.org/arch/msg/savi/nAMbTWnnRZ5mtR9c95-ynCpXif0
Subject: Re: [savi] I-D Action: draft-ietf-savi-dhcp-24.txt
X-BeenThere: savi@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mailing list for the SAVI working group at IETF <savi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/savi>, <mailto:savi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/savi/>
List-Post: <mailto:savi@ietf.org>
List-Help: <mailto:savi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/savi>, <mailto:savi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 May 2014 10:51:29 -0000

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:savi-bounces@ietf.org] On Behalf Of
internet-drafts@ietf.org
Sent: Monday, May 05, 2014 5:19 PM
To: i-d-announce@ietf.org
Cc: savi@ietf.org
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.

        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/

_______________________________________________
savi mailing list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi