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
- [savi] I-D Action: draft-ietf-savi-dhcp-24.txt internet-drafts
- Re: [savi] I-D Action: draft-ietf-savi-dhcp-24.txt Leaf Yeh