Re: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt
"Leaf Yeh" <leaf.yeh.sdo@gmail.com> Tue, 01 April 2014 09:23 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 059091A7D83 for <savi@ietfa.amsl.com>; Tue, 1 Apr 2014 02:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 6yhly5i0JEsB for <savi@ietfa.amsl.com>; Tue, 1 Apr 2014 02:23:33 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B50B21A7035 for <savi@ietf.org>; Tue, 1 Apr 2014 02:23:33 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id z10so9257303pdj.18 for <savi@ietf.org>; Tue, 01 Apr 2014 02:23:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=kuYTh1ytA/cHRFO8zrduTZc4thYqcKwbIUInSclYtcU=; b=YRkNADiAAlT90V7OIpfGpXMfZ7cUA803AwL0LAgeo2VNL0/W+ECK5bFpKz5SMxHMB4 AltR8CcBNWnu4Z/GJ6C+L4/mUxDTHxfTNG9MJ7LukXcx8RiAjYna07sgt4btdjZLDqgp FZ5+iCwsuuX/ENFG/Xuso2s6SwArBPc9nikoc5fgCZrq3aroL+iBNp9um2J6VA2kcVqN 2eWnUwJnV9vdjKMR6eF0DIgdG3rZRjWdmeQivCK2p+xg89SDjd8c5E173WV+lfiE7wdZ JkmVNp661rXLBxFMadpTYgLzZUnzCIwQogtyc9/yjlRt5IgT+1ks3xxjTk7yxieWZTSC Zx5Q==
X-Received: by 10.68.194.202 with SMTP id hy10mr30185016pbc.94.1396344210369; Tue, 01 Apr 2014 02:23:30 -0700 (PDT)
Received: from PC ([218.241.103.53]) by mx.google.com with ESMTPSA id ir10sm48661014pbc.59.2014.04.01.02.23.25 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Apr 2014 02:23:29 -0700 (PDT)
From: Leaf Yeh <leaf.yeh.sdo@gmail.com>
To: 'Guang Yao' <yaoguang@cernet.edu.cn>
References: <20140331054839.12951.1562.idtracker@ietfa.amsl.com> <533a1b73.0382440a.6009.ffffb32a@mx.google.com> <000501cf4d7b$e18af450$a4a0dcf0$@cernet.edu.cn>
In-Reply-To: <000501cf4d7b$e18af450$a4a0dcf0$@cernet.edu.cn>
Date: Tue, 01 Apr 2014 17:23:21 +0800
Message-ID: <533a8591.2ac5440a.0da6.1ee7@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0065_01CF4DCF.180FC750"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQH2W92cm8JJdKosbkMcCGTh4OHxCgI61sxxmpxn5CCAAANv0A==
Content-Language: zh-cn
Archived-At: http://mailarchive.ietf.org/arch/msg/savi/g5iC1KpIulT2R3p4sNNylfq4ozc
Cc: savi@ietf.org, 'Ted Lemon' <ted.lemon@nominum.com>
Subject: Re: [savi] I-D Action: draft-ietf-savi-dhcp-21.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: Tue, 01 Apr 2014 09:23:38 -0000
Guang - R19: We found there is no direct link between SAVI devices, thus we add a new link to illustrate this situation. I guess we could live with the case of 'no direct link between SAVI devices', just because the connection (i.e. Non-SAVI device) between them are in the perimeter. Guang - R20: Since DHCP relay and server are only supposed to send DHCP messages, data packets are not expected from them. If they also send data packet, their roles are changed. How to process the data packet depends on the the role which sends the data packet. DHCP messages is only a kind of control plane packet. DHCP-Trust Attribute sounds only deactivate the blocking against the message from server/relay. If you let the data packet pass, then you will get a more flexible application case as follows within the perimeter: Right? I can't see the negative effect yet when you let the data packet pass through the trust port of SAVI-switch. Best Regards, Leaf -----Original Message----- From: Guang Yao [mailto:yaoguang@cernet.edu.cn] Sent: Tuesday, April 01, 2014 3:28 PM To: 'Leaf Yeh' Cc: savi@ietf.org; 'Jun Bi'; 'Ted Lemon' Subject: RE: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt Hi Leaf, Thank you very much for these comments! The replies are as follows. 1. Q19. I am not sure the reason why there is a new link between SAVI Device C to SAVI Device B in Fig.1. The relation between the SAVI Device A and the SAVI Device B looks more like the case described in the Fig.1 of SAVI arch. (RFC7039). R19: We found there is no direct link between SAVI devices, thus we add a new link to illustrate this situation. 2. Q20. As to DHCP-Trust Attribute, in section 4.2.2, <quote> The "DHCP-Trust Attribute" indicates the DHCP Server-Client messages from the corresponding attachment is trustable. ... </quote> , in section 4.3.2 <quote> (5) Configure DHCP-Trust attribute on the direct attachments of trusted DHCP relays/servers. ... DHCP-Trust attribute is only configured on the inside links of the perimeter. Only DHCP server-client messages originated in the perimeter is trusted. </quote> When the port of SAVI-switch connected to the trusted DHCP relays/servers (in the SAVI-perimeter) is configured DHCP-Trust attribute, how about the data packet forwarding when it is received on this port? I guess the switch will forward the packet as the normal without checking, right? May you need a statement on this case in section 8.1? R20: Thank you for this comment. Since DHCP relay and server are only supposed to send DHCP messages, data packets are not expected from them. If they also send data packet, their roles are changed. How to process the data packet depends on the the role which sends the data packet. We will specify this point in the revision. -----Original Message----- From: Leaf Yeh [ <mailto:leaf.yeh.sdo@gmail.com> mailto:leaf.yeh.sdo@gmail.com] Sent: Tuesday, April 01, 2014 9:51 AM To: 'Guang Yao' Cc: <mailto:savi@ietf.org> savi@ietf.org; 'Jun Bi'; 'Ted Lemon' Subject: RE: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt Hi Guang, Q19. I am not sure the reason why there is a new link between SAVI Device C to SAVI Device B in Fig.1. The relation between the SAVI Device A and the SAVI Device B looks more like the case described in the Fig.1 of SAVI arch. (RFC7039). Q20. As to DHCP-Trust Attribute, in section 4.2.2, <quote> The "DHCP-Trust Attribute" indicates the DHCP Server-Client messages from the corresponding attachment is trustable. ... </quote> , in section 4.3.2 <quote> (5) Configure DHCP-Trust attribute on the direct attachments of trusted DHCP relays/servers. ... DHCP-Trust attribute is only configured on the inside links of the perimeter. Only DHCP server-client messages originated in the perimeter is trusted. </quote> When the port of SAVI-switch connected to the trusted DHCP relays/servers (in the SAVI-perimeter) is configured DHCP-Trust attribute, how about the data packet forwarding when it is received on this port? I guess the switch will forward the packet as the normal without checking, right? May you need a statement on this case in section 8.1? Best Regards, Leaf -----Original Message----- From: savi [ <mailto:savi-bounces@ietf.org> mailto:savi-bounces@ietf.org] On Behalf Of <mailto:internet-drafts@ietf.org> internet-drafts@ietf.org Sent: Monday, March 31, 2014 1:49 PM To: <mailto:i-d-announce@ietf.org> i-d-announce@ietf.org Cc: <mailto:savi@ietf.org> savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-dhcp-21.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-21.txt Pages : 43 Date : 2014-03-30 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/> 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-21> http://tools.ietf.org/html/draft-ietf-savi-dhcp-21 A diff from the previous version is available at: <http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-21> http://www.ietf.org/rfcdiff?url2=draft-ietf-savi-dhcp-21 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/> ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ savi mailing list <mailto:savi@ietf.org> savi@ietf.org <https://www.ietf.org/mailman/listinfo/savi> https://www.ietf.org/mailman/listinfo/savi
- Re: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt Leaf Yeh
- [savi] I-D Action: draft-ietf-savi-dhcp-21.txt internet-drafts
- Re: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt Leaf Yeh
- Re: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt Guang Yao
- Re: [savi] I-D Action: draft-ietf-savi-dhcp-21.txt Guang Yao