From junbi@tsinghua.edu.cn Sat Apr 11 20:06:07 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E12B13A67A3 for ; Sat, 11 Apr 2009 20:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.293 X-Spam-Level: X-Spam-Status: No, score=0.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMH6ULEpG4+A for ; Sat, 11 Apr 2009 20:06:05 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id D82EA3A689F for ; Sat, 11 Apr 2009 20:05:39 -0700 (PDT) Received: from th053141.ip.tsinghua.edu.cn ([59.66.53.141] helo=userPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Lsq1t-0001qm-D8 for savi@ietf.org; Sun, 12 Apr 2009 11:06:45 +0800 Message-ID: From: "Jun Bi" To: "SAVI Mailing List" References: In-Reply-To: Date: Sun, 12 Apr 2009 11:06:28 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_07F5_01C9BB5E.BA623CD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Subject: Re: [savi] SAVI-CPS X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jun Bi List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 03:06:08 -0000 这是 MIME 格式的多方邮件。 ------=_NextPart_000_07F5_01C9BB5E.BA623CD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_07F6_01C9BB5E.BA6263E0" ------=_NextPart_001_07F6_01C9BB5E.BA6263E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear WG members, A revised version of this draft has been submitted.=20 Thank you for your valuable comments. Best Regards, Jun Bi ----- Original Message -----=20 From: "IETF I-D Submission Tool" To: Cc: ; ; = Sent: Friday, April 10, 2009 11:51 AM Subject: New Version Notification for draft-bi-savi-cps-00=20 >=20 > A new version of I-D, draft-bi-savi-cps-00.txt has been successfuly = submitted by Jun Bi and posted to the IETF repository. >=20 > Filename: draft-bi-savi-cps > Revision: 00 > Title: Control Packet Snooping Based Binding > Creation_date: 2009-04-09 > WG ID: Independent Submission > Number_of_pages: 18 >=20 > Abstract: > This document specifies the Control Packet Snooping (CPS) mechanism=20 > for IP version 4 and IP version 6. This mechanism is used to set up=20 > binding between source IP address and corresponding anchor on the=20 > access device. This binding is always used to perform source address=20 > validation. > = =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > ----- Original Message -----=20 From: Jun Bi=20 To: SAVI Mailing List=20 Cc: Guang Yao=20 Sent: Thursday, March 26, 2009 12:18 AM Subject: [savi] SAVI-CPS Hi All, The attached file is a SAVI-CPS (control packet snooping) solution. Since IETF 73, an early version of this draft, savi-sn, was sent to = some people for review,=20 this is a revised version of savi-sn.=20 On Monday's SAVI WG meeting in IETF 74, I planed a PPT for SAVI-CPS. = But due to the time limitation,=20 I didn't have enough time to present, only mention SAVI-CPS during the = savi progress report.=20 (The PPT on SAVI-CPS is in the SAVI meeting material page).=20 As I introduced at the SAVI progress report PPT on Monday's SAVI WG = meeting, some vendors have support=20 the snooping and binding (it seems not complex for vendors to = implement), and passed our test in Feb. 2009. Please give your valuable comments to help us to improve the draft. Best Regards, Jun Bi and co-authors. -------------------------------------------------------------------------= ----- _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi ------=_NextPart_001_07F6_01C9BB5E.BA6263E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear WG members,
 
A revised version of this draft has been submitted.
 
Thank you for your valuable comments.
 
Best Regards,
Jun Bi
 
----- Original Message -----=20
From: "IETF I-D Submission Tool" <idsubmission@ietf.org>
=
To: <junbi@cernet.edu.cn>
Cc: <jianping@cernet.edu.cn>; = <yaog@netarchlab.tsinghua.= edu.cn>;=20 <fred@cisco.com>
Sent: Friday, April 10, 2009 11:51 AM
Subject: New Version Notification for draft-bi-savi-cps-00 =

>
> A new version of I-D, = draft-bi-savi-cps-00.txt has=20 been successfuly submitted by Jun Bi and posted to the IETF = repository.
>=20
> Filename: draft-bi-savi-cps
> Revision: 00
> Title: = Control=20 Packet Snooping Based Binding
> Creation_date: 2009-04-09
> = WG ID:=20 Independent Submission
> Number_of_pages: 18
>
>=20 Abstract:
> This document specifies the Control Packet Snooping = (CPS)=20 mechanism
> for IP version 4 and IP version 6. This mechanism is = used to=20 set up
> binding between source IP address and corresponding = anchor on=20 the
> access device. This binding is always used to perform = source=20 address
>=20 validation.
>         =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;           =20
>
>
> The IETF Secretariat.
>
>=20
>
----- Original Message -----
From:=20 Jun = Bi=20
Sent: Thursday, March 26, 2009 = 12:18=20 AM
Subject: [savi] SAVI-CPS

Hi All,
 
The attached file is a SAVI-CPS (control packet = snooping)=20 solution.
Since IETF 73, an early version of this = draft, savi-sn,=20 was sent to some people for review,
this is a revised version of savi-sn. =
 
On Monday's SAVI WG meeting in IETF 74, I = planed a=20 PPT for SAVI-CPS.  But due to the time limitation,=20
I didn't have enough time to present, only=20 mention SAVI-CPS during the savi progress report.
(The PPT on SAVI-CPS is in the SAVI meeting = material=20 page).
As I introduced at the SAVI progress report PPT on = Monday's SAVI WG meeting, some vendors=20 have support
the snooping and binding (it seems not complex for = vendors=20 to implement), and passed our test in Feb.=20 2009.
 
Please give your valuable comments to help us to = improve the=20 draft.
 
Best Regards,
Jun Bi and co-authors.
 
 
 

_______________________________________________
savi mailing = = list
savi@ietf.org
https://www.ietf.org/mailman/listinfo/savi
------=_NextPart_001_07F6_01C9BB5E.BA6263E0-- ------=_NextPart_000_07F5_01C9BB5E.BA623CD0 Content-Type: text/plain; name="draft-bi-savi-cps-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-bi-savi-cps-00.txt" SAVI J. Bi, J. Wu, G. Yao =0A= Internet Draft CERNET =0A= Intended status: Standard Tracks F. Baker =0A= Expires: December 2009 Cisco=0A= April 9, 2009 =0A= =0A= =0A= =0A= Control Packet Snooping Based Binding =0A= draft-bi-savi-cps-00.txt =0A= =0A= =0A= Status of this Memo =0A= =0A= This Internet-Draft is submitted to IETF in full conformance with =0A= the provisions of BCP 78 and BCP 79. =0A= =0A= Internet-Drafts are working documents of the Internet Engineering =0A= Task Force (IETF), its areas, and its working groups. Note that =0A= other groups may also distribute working documents as Internet-=0A= Drafts. =0A= =0A= Internet-Drafts are draft documents valid for a maximum of six =0A= months and may be updated, replaced, or obsoleted by other documents =0A= at any time. It is inappropriate to use Internet-Drafts as =0A= reference material or to cite them other than as "work in progress." =0A= =0A= The list of current Internet-Drafts can be accessed at =0A= http://www.ietf.org/ietf/1id-abstracts.txt =0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at =0A= http://www.ietf.org/shadow.html =0A= =0A= This Internet-Draft will expire on October 9, 2009. =0A= =0A= Copyright Notice =0A= =0A= Copyright (c) 2009 IETF Trust and the persons identified as the =0A= document authors. All rights reserved. =0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal =0A= Provisions Relating to IETF Documents in effect on the date of =0A= publication of this document (http://trustee.ietf.org/license-info). =0A= Please review these documents carefully, as they describe your =0A= rights and restrictions with respect to this document. =0A= =0A= Abstract =0A= =0A= =0A= =0A= =0A= Bi Expires December 9,2009 [Page 1] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= This document specifies the Control Packet Snooping (CPS) mechanism =0A= for IP version 4 and IP version 6. This mechanism is used to set up =0A= binding between source IP address and corresponding anchor on the =0A= access device. This binding is always used to perform source address =0A= validation. =0A= =0A= Table of Contents =0A= =0A= =0A= 1. Introduction ................................................ 3 =0A= 2. Conventions used in this document............................ 3 =0A= 3. Terminology ................................................. 3 =0A= 4. Mechanism Overview .......................................... 3 =0A= 5. Related Protocols ........................................... 4 =0A= 6. Definition of Anchor......................................... 4 =0A= 7. Conceptual Data Structures................................... 5 =0A= 8. Control Packet Snooping...................................... 7 =0A= 8.1. DHCPv4 Snooping......................................... 7 =0A= 8.1.1. Process of DHCPv4 Snooping .........................7 =0A= 8.1.2. State Machine of DHCPv4 Snooping ...................7 =0A= 8.2. DHCPv6 Snooping......................................... 8 =0A= 8.2.1. Process of DHCPv6 Snooping .........................8 =0A= 8.2.2. State Machine of DHCPv6 Snooping ...................9 =0A= 8.3. ND Snooping ............................................ 9 =0A= 8.3.1. Process of ND Snooping............................. 9 =0A= 8.3.2. State Machine of ND Snooping ......................10 =0A= 8.4. ARP Snooping .......................................... 10 =0A= 8.4.1. Process of ARP Snooping........................... 10 =0A= 8.4.2. State Machine of ARP Snooping .....................11 =0A= 8.5. Manually Binding....................................... 11 =0A= 9. Clear Binding .............................................. 11 =0A= 10. Solution for Special Situations............................ 12 =0A= 10.1. Multiple Interfaces................................... 12 =0A= 10.2. Port Movement ........................................ 12 =0A= 11. Considerations on Security Risks........................... 13 =0A= 11.1. Operating system support.............................. 13 =0A= 11.2. Detection packet loss................................. 14 =0A= 11.3. Malicious replier..................................... 14 =0A= 11.4. Inactive node ........................................ 15 =0A= 12. Filter Exception .......................................... 15 =0A= 13. Constants ................................................. 15 =0A= 14. Security Considerations.................................... 15 =0A= 15. IANA Considerations........................................ 16 =0A= 16. References ................................................ 16 =0A= 16.1. Normative References.................................. 16 =0A= 16.2. Informative References................................ 16 =0A= 17. Acknowledgments ........................................... 16 =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 2] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= Appendix A. Operating System Support Situation .................17 =0A= Authors' Addresses ............................................ 18 =0A= =0A= 1. Introduction =0A= =0A= This specification defines the Control Packet Snooping (CPS) =0A= mechanism for Internet Protocol version 4 (IPv4) and Internet =0A= Protocol version 6 (IPv6). Access devices (including access switches, =0A= and wireless access point/controller, etc) can use this mechanism to =0A= set up bindings between source IP address of hosts and corresponding =0A= anchors, in accordance with the appointed address assignment method. =0A= These bindings can be used to validate the source IP address in the =0A= packets received from directly attached hosts. =0A= =0A= 2. Conventions used in this document =0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this =0A= document are to be interpreted as described in [RFC2119]. =0A= =0A= 3. Terminology =0A= =0A= Anchor - The entity to bind source IP address with. =0A= =0A= 4. Mechanism Overview =0A= =0A= This mechanism is designed to provide a host level source IP address =0A= validation granularity, as a supplement of BCP38. This mechanism is =0A= deployed on the access device (including access switch, wireless =0A= access point/controller, etc), and performs control protocol =0A= snooping to set up bindings between source IP address and =0A= corresponding anchors. It also allows manually configured binding. =0A= The bindings are then used to check the source address in the =0A= packets from the directly attached hosts. =0A= =0A= This mechanism requires no change on host, and no new protocol is =0A= designed. The deployed devices can work with non-deployed devices; =0A= however, the protection area is limited to the deployed area. =0A= =0A= This mechanism has an assumption that any kind of address is used =0A= only after some duplicate detection protocol is used. If in any =0A= situation the address is used without any detection protocol, such =0A= packets will be regarded as source spoofing packets. However, in =0A= some situations, a source IP address may be used without detection, =0A= but cannot be considered as spoofing. These situations are discussed =0A= in section 9 and section 10. =0A= =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 3] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= The binding entries generally are not permanent. Each binding has a =0A= lifetime, and some event may trigger the binding deletion. When =0A= their lifetime expires, or the event happens, this mechanism will =0A= delete the corresponding entry, or perform some process. =0A= =0A= 5. Related Protocols =0A= =0A= All the protocols related with the IP address assignment are the in =0A= the scope of this mechanism, including: =0A= =0A= Dynamic Host Configuration Protocol version 4 (DHCPv4) - A host may =0A= use this protocol to get an IPv4 address. =0A= =0A= Dynamic Host Configuration Protocol version 6 (DHCPv6) - A host may =0A= use this protocol to get an IPv6 address. =0A= =0A= Neighbor Discovery Protocol (NDP) - Whenever a host wants to assign =0A= an IPv6 address to its interface, it must perform Duplicate Address =0A= Detection first, which is composed of NDP packets. The NDP is also =0A= used to detect whether a host is still reachable. Such NDP packets =0A= can be used to determine whether to delete a binding or not. =0A= =0A= Address Resolution Protocol (ARP) - Whenever a host wants assign an =0A= IPv4 address to its interface, it will send a gratuitous ARP to make =0A= sure this address is not being used. However, this function may not =0A= be supported by all the operating systems. ARP is also used to =0A= determine whether a host is still reachable. Such ARP packets can be =0A= used to determine whether to delete a binding or not. =0A= =0A= Secure Neighbor Discovery Protocol (SeND) - SeND is a special case =0A= of NDP. If a ND packet is also a SeND packet, the validity of the =0A= source address must be checked first before this packet is taken =0A= into the process of this mechanism. There is no other difference for =0A= the mechanism to process plain ND packet and SeND packet. =0A= =0A= 6. Definition of Anchor =0A= =0A= Anchor is an important concept for this mechanism. In this document, =0A= anchor is the entity to bind source address with. To make the =0A= binding secure, the anchor itself must be unspoofable. Generally, =0A= following entities can be used as anchor: =0A= =0A= Exclusive switch port - When a switch port is exclusive for a =0A= host, this port is unspoofable for other hosts. =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 4] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= MAC address in 802.1ae/af and 802.11i - 802.1ae/af and 802.11i =0A= protect the security of MAC address. When such technology is =0A= deployed in the network, MAC address can be used as anchor. =0A= =0A= However, when strict secure anchor is not achievable in the network, =0A= loose secure anchor can be used. Generally, shared switch port and =0A= MAC address are loose secure anchors. Loose secure anchor may cause =0A= false negative, thus it is not recommended to use such anchors. =0A= =0A= This document doesn't specify which entities can be used as anchor, =0A= and how secure these anchors. =0A= =0A= 7. Conceptual Data Structures =0A= =0A= This section describes the possible conceptual data structures used =0A= in this mechanism. =0A= =0A= The deployed device must maintain the following data structures: =0A= =0A= Binding State Table (BST) =0A= =0A= - This table contains this state of binding =0A= between source address and anchor. Entries are =0A= keyed on the anchor and source IP address. Each =0A= entry has a lifetime item which records the =0A= remaining lifetime of this entry, an item which =0A= records the state of this binding and an item =0A= record other information. Whenever the lifetime =0A= expires, the entry should be deleted, except for =0A= the entries with DHCPv4_DETECTION/ =0A= DHCPv4_DETECTION/SAC_START/MANUALv4_START state. =0A= =0A= Filtering Table (FT) =0A= =0A= - This table contains the bindings between anchor =0A= and address, keyed on anchor. This table doesn't =0A= contain any state of the binding. This table is =0A= used to filter packet. Access Control List can =0A= be regarded as an instance of this table. =0A= =0A= The states of binding in Binding State Table are as follows: =0A= =0A= DHCPv4_START A DHCPv4 request is received from host, and it may =0A= trigger a new binding. =0A= =0A= DHCPv4_LIVE The DHCPv4 address is acknowledged by DHCP server. =0A= =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 5] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= DHCPv4_DETECTION A gratuitous ARP has been sent by the host and =0A= it is waiting for the reply. =0A= =0A= DHCPv4_BOUND The address has passed duplicate detection and =0A= it is bound with the anchor. =0A= =0A= DHCPv6_START A DHCPv6 request or confirm is received from host. =0A= =0A= DHCPv6_LIVE A DCHPv6 reply is received from server, and an =0A= address is suggested. =0A= =0A= DHCPv6_DETECTION A Duplicate Address Detection (DAD) Neighbor =0A= Solicitation has been sent by the host, and it =0A= is waiting for the reply. =0A= =0A= DHCPv6_BOUND The address has passed DAD and it is bound with =0A= the anchor. =0A= =0A= SAC_START A DAD NS has been sent by the host. The target =0A= address is neither got from DHCP nor static. =0A= =0A= SAC_BOUND The address has passed DAD and it is bound with =0A= anchor. =0A= =0A= SAC_QUERY The bound address is being queried by another node. =0A= If there is no response in a time constant, the =0A= binding should be deleted. =0A= =0A= MANUALv4_START A gratuitous ARP has been sent by the host. The =0A= target address is neither got from DHCP nor =0A= static. =0A= =0A= MANUALv4_BOUND The address has passed DAD and it is bound with =0A= anchor. =0A= =0A= MANUALv4_QUERY The bound address is being queried by another =0A= node. If there is no response in a time constant, =0A= the binding should be deleted. =0A= =0A= STATIC The address is static and the binding should not =0A= be change. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 6] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= 8. Control Packet Snooping =0A= =0A= 8.1. DHCPv4 Snooping =0A= =0A= 8.1.1. Process of DHCPv4 Snooping =0A= =0A= This process is designed for DHCPv4 assigned address. =0A= =0A= Whenever a DHCPv4 request is received from attaching host, and the =0A= requested IP address does not exist in the binding table, the device =0A= will generate an entry in the Binding State Table (BST), set the =0A= state field to be DHCPv4_START. The lifetime of this entry is set to =0A= be MAX_DHCP_RESPONSE_TIME. The TID field of the request packet is =0A= also recorded in the entry. If an entry is already in the BST and =0A= the state of the entry is DHCPv4_START, set the lifetime field to be =0A= MAX_DHCP_RESPONSE_TIME. =0A= =0A= Whenever a DHCPv4 acknowledgement is received from the DHCP server, =0A= if the TID is in BST, and the state of the entry is DHCPv4_START, =0A= set the state of the entry to be DHCPv4_LIVE. The lifetime of the =0A= entry is set to be MAX_ARP_PREPARE_DELAY. The lease time is also =0A= recorded in the entry. =0A= =0A= Whenever a gratuitous ARP request is received from the host, if the =0A= state of the entry is DHCPv4_LIVE, set the state of the entry to be =0A= DHCPv4_DETECTION. The lifetime of the entry is set to be MAX_ARP =0A= _DELAY. If an ARP response for the address is received from other =0A= nodes, delete the entry. If the lifetime expires, set the state of =0A= the entry to be DHCPv4_BOUND. The lifetime of this entry is set to =0A= the lease time of the entry. An entry is added into the Filter Table. = =0A= =0A= Whenever a DHCPv4 decline is received from the host, if the state of =0A= the entry is DHCPv4_LIVE, delete the entry in BST. =0A= =0A= Whenever a DHCPv4 release is received from the host, if the state of =0A= the entry is DHCPv4_BOUND, delete the entry in BST and Filter Table. =0A= =0A= If a DHCPv4 acknowledgement with renew/rebind sign is received from =0A= the server, set lifetime of the entry in BST to be the new lease =0A= time. =0A= =0A= If the lifetime of an entry with state DHCPv4_BOUND expires, delete =0A= the entry in BST and Filter Table. =0A= =0A= 8.1.2. State Machine of DHCPv4 Snooping =0A= =0A= State Packet/Event Action Next State =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 7] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= Start DHCPv4 REQ Set up new entry DHCPv4_START =0A= =0A= DHCPv4_START DHCPv4 ACK Record lease time DHCPv4_LIVE =0A= =0A= DHCPv4_LIVE Gra ARP REQ - DHCPv4_DETECTION =0A= =0A= DHCPv4_LIVE DHCPv4 DEC Remove entry Start =0A= =0A= DHCPv4_DETECTION Timeout Insert into FT DHCPv4_BOUND =0A= =0A= DHCPv4_DETECTION Gra ARP RPL Remove entry Start =0A= =0A= DHCPv4_DETECTION DHCPv4 DEC Remove entry Start =0A= =0A= DHCPv4_BOUND DHCPv4 REL Remove entry Start =0A= =0A= DHCPv4_BOUND DHCPv4 REN/REB Set new lifetime DHCPv4_BOUND =0A= =0A= 8.2. DHCPv6 Snooping =0A= =0A= 8.2.1. Process of DHCPv6 Snooping =0A= =0A= This process is designed for DHCPv6 assigned address. =0A= =0A= Whenever a DHCPv6 request or confirm is received from attaching host, =0A= and the requested IP address does not exist in the binding table, =0A= the device will generate an entry in the BST, set the state field to =0A= be DHCPv6_START. The lifetime of this entry is set to be =0A= MAX_DHCP_RESPONSE_TIME. The source address of the request packet is =0A= also recorded in the entry. If an entry is already in the BST and =0A= the state of the entry is DHCPv6_START, set the lifetime field to be =0A= MAX_DHCP_RESPONSE_TIME. =0A= =0A= Whenever a DHCPv6 reply is received from the DHCP server, if the TID =0A= is in BST, and the state of the entry is DHCPv6_START, set the state =0A= of the entry to be DHCPv6_LIVE. The lifetime of the entry is set to =0A= be MAX_DAD_PREPARE_DELAY. The lease time is also recorded in the =0A= entry. =0A= =0A= Whenever a DAD NS is received from the host, if the state of the =0A= entry is DHCPv6_LIVE, set the state of the entry to be =0A= DHCPv6_DETECTION. The lifetime of the entry is set to be MAX_DAD =0A= _DELAY. If an NA response for the address is received from other =0A= nodes, delete the entry. If the lifetime expires, set the state of =0A= the entry to be DHCPv6_BOUND. The lifetime of this entry is set to =0A= the lease time of the entry. An entry is added into the Filter Table. = =0A= =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 8] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= Whenever a DHCPv6 decline is received from the host, if the state of =0A= the entry is DHCPv6_LIVE, delete the entry in BST. =0A= =0A= Whenever a DHCPv6 release is received from the host, if the state of =0A= the entry is DHCPv6_BOUND, delete the entry in BST and Filter Table. =0A= =0A= If a DHCPv6 reply with renew/rebind sign is received from the server, =0A= set lifetime of the entry in BST to be the new lease time. =0A= =0A= If the lifetime of an entry with state DHCPv6_BOUND expires, delete =0A= the entry in BST and Filter Table. =0A= =0A= 8.2.2. State Machine of DHCPv6 Snooping =0A= =0A= State Packet/Event Action Next State =0A= =0A= Start DHCPv6 REQ/CON Set up new entry DHCPv6_START =0A= =0A= DHCPv6_START DHCPv6 RLY Record lease time DHCPv6_LIVE =0A= =0A= DHCPv6_LIVE DAD NS - DHCPv6_DETECTION =0A= =0A= DHCPv6_DETECTION Timeout Insert into FT DHCPv6_BOUND =0A= =0A= DHCPv6_DETECTION DAD NA RLY Remove entry Start =0A= =0A= DHCPv6_LIVE DHCPv6 DEC Remove entry Start =0A= =0A= DHCPv6_BOUND DHCPv6 REL Remove entry Start =0A= =0A= DHCPv6_BOUND DHCPv4 REN/REB Set new lifetime DHCPv6_BOUND =0A= =0A= 8.3. ND Snooping =0A= =0A= 8.3.1. Process of ND Snooping =0A= =0A= This process is designed for stateless auto-configuration assigned =0A= IPv6 address and manually configured IPv6 address. =0A= =0A= Whenever a DAD NS is received from the host, if the address is not =0A= in BST and has a permitted prefix, generate a new entry in BST and =0A= set the state of the entry to be SAC_START. The lifetime of the =0A= entry is set to be MAX_DAD _DELAY. If an NA response for the address =0A= is received from other nodes, delete the entry. If the lifetime =0A= expires, set the state of the entry to be SAC_BOUND. The lifetime of =0A= this entry is set to MAX_SAC_LIFETIME. An entry is added into the =0A= Filter Table. =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 9] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= If the lifetime of an entry with state SAC_BOUND expires, set the =0A= lifetime to be MAX_DAD_PREPARE_DELAY and send a NS for the address. =0A= If there is no response before the lifetime expires, delete the =0A= entry in BST and Filter Table. Else set the lifetime to be =0A= MAX_SAC_LIFETIME. =0A= =0A= Whenever a NS with target address set to one of the addresses with =0A= state SAC_BOUND, the state of the entry is set to SAC_QUERY, and the =0A= lifetime is set to MAX_DAD_PREPARE_DELAY. If there is no response =0A= from the host before the lifetime expires, delete the entry in BST =0A= and Filter Table. If a response is received from the host, set the =0A= lifetime of the corresponding entry to be MAX_SAC_LIFETIME. =0A= =0A= 8.3.2. State Machine of ND Snooping =0A= =0A= State Packet/Event Action Next State =0A= =0A= Start DAD NS Set up new entry SAC_START =0A= =0A= SAC_START Timeout Insert into FT SAC_BOUND =0A= =0A= SAC_START DAD NA RLY Remove entry Start =0A= =0A= *SAC_BOUND NS for bound addr - SAC_QUERY =0A= =0A= *SAC_QUERY NA Set lifetime to maximum SAC_BOUND =0A= =0A= *SAC_QUERY Timeout Remove binding Start =0A= =0A= (* denotes optional process.) =0A= =0A= 8.4. ARP Snooping =0A= =0A= 8.4.1. Process of ARP Snooping =0A= =0A= This process is designed for manually configured IPv4 address. =0A= =0A= Whenever a gratuitous ARP is received from the host, if the address =0A= is not in BST and has a permitted prefix, generate a new entry in =0A= BST and set the state of the entry to be MANUALv4_START. The =0A= lifetime of the entry is set to be MAX_ARP_DELAY. If an ARP response =0A= for the address is received from other nodes, delete the entry. If =0A= the lifetime expires, set the state of the entry to be =0A= MANUALv4_BOUND. The lifetime of this entry is set to =0A= MAX_MANUAL_LIFETIME. An entry is added into the Filter Table. =0A= =0A= =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 10] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= If the lifetime of an entry with state MANUALv4_BOUND expires, set =0A= the lifetime to be MAX_ARP_PREPARE_DELAY and send an ARP request for =0A= the address. If there is no response before the lifetime expires, =0A= delete the entry in BST and Filter Table. Else set the lifetime to =0A= be MAX_MANUAL_LIFETIME. =0A= =0A= Whenever an ARP response with target address set to one of the =0A= addresses with state ARP_BOUND, the state of the entry is set to =0A= MANUALv4_QUERY, and the lifetime is set to MAX_ARP_PREPARE_DELAY. If =0A= there is no response from the host before the lifetime expires, =0A= delete the entry in BST and Filter Table. If a response is received =0A= from the host, set the lifetime of the corresponding entry to be =0A= MAX_MANUAL_LIFETIME. =0A= =0A= 8.4.2. State Machine of ARP Snooping =0A= =0A= State Packet/Event Action Next State =0A= =0A= Start Gra ARP REQ Set up new entry MANUALv4_START =0A= =0A= MANUALv4_START Timeout Insert into FT MANUALv4_BOUND =0A= =0A= MANUALv4_START Gra ARP RLY Remove entry Start =0A= =0A= *MANUALv4_BOUND ARP for bound addr MANUALv4_QUERY =0A= =0A= *MANUALv4_QUERY ARP RLY Set lifetime to maximum MANUALv4_BOUND =0A= =0A= *MANUALv4_QUERY Timeout Remove binding Start =0A= =0A= (* denotes optional process.) =0A= =0A= 8.5. Manually Binding =0A= =0A= To be compatible with manually configured static address, the BST is =0A= allowed to be configured manually. The configured binding has state =0A= STATIC and has an infinite lifetime. =0A= =0A= 9. Clear Binding =0A= =0A= Whenever the lifetime of any entry in the BST expires, it MUST be =0A= removed from the BST. If a binding has been inserted in to Filtering =0A= Table, this binding also MUST be removed. =0A= =0A= Whenever a node is disconnected at link layer, the corresponding =0A= binding in BST and Filtering Table MUST be removed unless the state =0A= of the entry is STATIC. =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 11] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= 10. Solution for Special Situations =0A= =0A= Two situations described in the charter of SAVI working group may =0A= cause this mechanism filter packets improperly: multiple interfaces =0A= and port movement. The following is the proper solution for each =0A= situation. =0A= =0A= 10.1. Multiple Interfaces =0A= =0A= If a host has multiple interfaces to the same LAN, generally this =0A= situation can be treated as multiple hosts with single interface =0A= because each interface will only use the address assigned to itself =0A= as source IP address. However, a host may configure the same address =0A= on multiple interfaces for the purpose of load balance. In this =0A= situation, the SAVI device may find an address bound with a anchor =0A= appears with another anchor, just as spoofing. This is the only =0A= multiple interfaces situation that troubles this mechanism. =0A= =0A= When this situation happens, the corresponding binding is seldom =0A= changed. Thus, manual configuration is enough for this situation. =0A= All the anchors with the host can be configured to be used by the =0A= same host and share the same entries in BST and Filtering Table. =0A= =0A= Other mechanisms can also be used to handle this situation, such as =0A= [SAVI-SeND] and [SAVI-HIP]. These mechanisms can be used to test =0A= whether two anchors are belonging to the same host and thus =0A= distinguish multiple interfaces from spoofing. However, all the =0A= mentioned mechanisms bring overhead to data packet process, and are =0A= not recommended. Currently, the only recommended mechanism is manual =0A= configuration. =0A= =0A= However, for the consideration that in the future, a host with =0A= multiple interfaces to the same network may become very common (for =0A= example, a host has a wired network interface and a wireless network =0A= interface attached to the same network, and they are configured to =0A= use the same address), an extension mechanism is still needed. The =0A= design of such mechanism is temporarily out of the scope of this =0A= document. =0A= =0A= 10.2. Port Movement =0A= =0A= DHCP assigned address and stateless address don't have the problem =0A= of port movement. If an address is assigned through DHCP, the =0A= address must be confirmed by DHCP server after port movement, and =0A= the control packets will used to set up new binding. For a stateless =0A= address, a duplicate detection must be performed when the interface =0A= is re-initialized, just as the process of address assignment. =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 12] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= However, if an interface configured a static address changes port, =0A= because the corresponding is manually configured, this movement will =0A= conflict previous binding. =0A= =0A= The situation that a host with static address changes from one port =0A= to another can be handled through one of the following ways: =0A= =0A= - Manual configuration. If the host configured with static address =0A= seldom changes its port, the administrator can manually change the =0A= binding after each movement. =0A= =0A= - Changing anchor. If the anchor is not switch port, port movement =0A= will not cause any trouble. Thus an alternate way is choosing =0A= another entity as anchor, for example, the secure MAC address. =0A= =0A= - Access control mechanisms based on user account. Static address is =0A= always associated with specified user, thus the access control =0A= mechanism based on user account can be used to handle frequent port =0A= movements. 802.1x, PPPoE, and Portal are optional mechanisms. =0A= Whenever the user account is authenticated by there mechanisms, the =0A= corresponding address can be bound on the switch. The related =0A= protocol must be extended to enable such function. =0A= =0A= - Host identifier related mechanisms. [SAVI-SeND] and [SAVI-HIP] =0A= have a secure host identifier associated with the host, and this =0A= identifier can be used to handle port movement. The problem of such =0A= solutions is that they are based on immature techniques. =0A= =0A= 11. Considerations on Security Risks =0A= =0A= This mechanism has some potential risks. Some operating systems =0A= assign an address to interface without any duplicate detection. =0A= Other risks are due to the sync problem between host and SAVI device. = =0A= =0A= 11.1. Operating system support =0A= =0A= The duplicate detection for IPv4 address has been prescribed in =0A= [RFC5227], but currently not all the operating systems perform =0A= duplicate detection on IPv4 address. Because the number of available =0A= IPv4 addresses in a LAN is small, a simplest solution is that =0A= whenever a new IPv4 address appears, the deployed device can perform =0A= duplicate detection instead of the host. However, this function will =0A= take data packet into control panel and would bring additional cost. =0A= A suggestion for the network administrator is IPv4 address should be =0A= assigned through DHCP or static. The supported operating systems are =0A= listed in Appendix A. =0A= =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 13] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= The duplicate detection for IPv6 address has been prescribed in =0A= [RFC4862]. However, some operating systems not supporting IPv6 well =0A= will not perform DAD when assigning IPv6 address. =0A= =0A= It is suggested that the operating systems should be able to update =0A= to support [RFC5227] and [RFC4862]. For the operating system that =0A= cannot be updated, it is suggested to use static address and set up =0A= binding manually. =0A= =0A= 11.2. Detection packet loss =0A= =0A= The false positive of this mechanism is mainly caused by the risk of =0A= detection packet loss. If a critical detection packet is lost on the =0A= link, the binding may not be set up on the access device and the =0A= following data packet will be filtered incorrectly. This situation =0A= is rare for a wired network, and generally host will send the =0A= detection packet several times to avoid possible loss. The =0A= retransmit times of detection packets for IPv6 address can be =0A= configured as described in [RFC4862]. The number of detection packet =0A= for IPv4 address is 3 as described in [RFC5227]. =0A= =0A= However, this situation is still possible if the link quality is =0A= poor, especially in wireless network. If the administrator knows the =0A= link quality is poor, he can turn on the function which performs =0A= duplicate detection instead of the host. However, this function =0A= takes data packet into control panel and costs heavy. In our opinion, =0A= in such a network, the most important task is to improve the quality =0A= of the link, but not bring more burdens to the access device. =0A= =0A= 11.3. Malicious replier =0A= =0A= Another risk is that the detection packet can be replied by a =0A= malicious attacker, and the host will be prevented from getting a =0A= proper address. This problem cannot be easily handled for it is =0A= caused by non-deployed nodes. The deployed device must filter =0A= Neighbor Advertisement packets, not only by source address, but also =0A= by target address. The sender's address in ARP replies should also =0A= be checked. =0A= =0A= A practical solution for this problem is as follows: =0A= =0A= 1. Divide the address space of SAVI nodes and non-SAVI nodes; =0A= =0A= 2. Partition SAVI nodes and non-SAVI nodes to different VLANs. =0A= =0A= Then the SAVI nodes don't have to ask the non-SAVI nodes whether an =0A= address has been used by some of them. =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 14] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= 11.4. Inactive node =0A= =0A= The false negative may be caused by the situation that the detection =0A= packet is not replied by the assigned node. This is a troublesome =0A= situation. It is reasonable for a node to get such address because =0A= it is in accordance with the standard, unless the address is a =0A= static address. A simple process is removing the previous binding =0A= and setting up new binding for the requesting node. A more tolerant =0A= process is the SAVI device can perform ARP/ND proxy for the inactive =0A= node, and reduce the lifetime of binding to 1/4. =0A= =0A= 12. Filter Exception =0A= =0A= The filtering of data packet is based on the Filter Table, and the =0A= related control packet is handed to the Control Packet Snooping =0A= process. The source address of the control packet is always all zero =0A= (DHCPv4, IPv6 Stateless auto-configuration for link-local address) =0A= or unbound address (gratuitous ARP). Such packets don't have to pass =0A= the check on Filter Table. However, the source address of DHCPv6 =0A= request and IPv6 DAD NS for global address must pass the check on =0A= Filter Table, for always a unique link-local address is used. =0A= =0A= The target address in all the Neighbor Advertisement packets and the =0A= sender's address in all ARP relies should also pass the checks on =0A= Filter Table. =0A= =0A= 13. Constants =0A= =0A= MAX_DHCP_RESPONSE_TIME 10s =0A= =0A= MAX_ARP_PREPARE_DELAY 1s =0A= =0A= MAX_ARP_DELAY 1s =0A= =0A= MAX_DAD_PREPARE_DELAY 1s =0A= =0A= MAX_DAD_DELAY 1s =0A= =0A= MAX_SAC_LIFETIME 2h =0A= =0A= MAX_MANUAL_LIFETIME 4h =0A= =0A= 14. Security Considerations =0A= =0A= There are no security considerations currently. =0A= =0A= =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 15] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= 15. IANA Considerations =0A= =0A= There is no IANA consideration currently. =0A= =0A= 16. References =0A= =0A= 16.1. Normative References =0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate =0A= Requirement Levels", BCP 14, RFC 2119, March 1997. =0A= =0A= [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless =0A= Autoconfiguration", RFC4862, September, 2007. =0A= =0A= [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, =0A= July 2008. =0A= =0A= [SAVI-SeND] M. Bagnulo, draft-ietf-savi-send-00.txt. =0A= =0A= [SAVI-HIP] D. Kuptsov, A. Gurtov and J. Bi, draft-kuptsov-sava-hip-=0A= 01.txt. =0A= =0A= 16.2. Informative References =0A= =0A= 17. Acknowledgments =0A= =0A= Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun, Jari =0A= Arkko, David Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert =0A= Raszuk, and Tao Lin for their valuable contributions. =0A= =0A= This document was prepared using 2-Word-v2.0.template.dot. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 16] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= Appendix A. Operating System Support Situation =0A= =0A= Supported systems: Windows XP SP2, Windows XP SP3, Windows Vista, =0A= Sun Solaris. =0A= =0A= Not supported systems: Ubuntu 8.10, Fedora 10. =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 17] =0A= =0C=0A= Internet-Draft Control Packet Snooping Based Binding April 2009 =0A= =0A= =0A= Authors' Addresses =0A= =0A= Jun Bi =0A= CERNET =0A= Network Research Center, Tsinghua University =0A= Beijing 100084 =0A= China =0A= Email: junbi@cernet.edu.cn =0A= =0A= =0A= Jianping Wu =0A= CERNET =0A= Computer Science, Tsinghua University =0A= Beijing 100084 =0A= China =0A= Email: jianping@cernet.edu.cn =0A= =0A= =0A= Guang Yao =0A= CERNET =0A= Network Research Center, Tsinghua University =0A= Beijing 100084 =0A= China =0A= Email: yaog@netarchlab.tsinghua.edu.cn =0A= =0A= =0A= Fred Baker =0A= Cisco Systems =0A= Email: fred@cisco.com =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Bi Expires October 9, 2009 [Page 18] =0A= =0C=0A= ------=_NextPart_000_07F5_01C9BB5E.BA623CD0-- From christian.vogt@ericsson.com Sat Apr 11 20:20:39 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1914F3A6A48 for ; Sat, 11 Apr 2009 20:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah3ZmaBgi2KA for ; Sat, 11 Apr 2009 20:20:38 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 51C463A689F for ; Sat, 11 Apr 2009 20:20:36 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n3C3Ug3p015874 for ; Sat, 11 Apr 2009 22:30:43 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Apr 2009 22:21:45 -0500 Received: from [155.53.229.46] ([155.53.229.46]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Apr 2009 22:21:45 -0500 Message-Id: <8CAA4D13-6238-47A6-A33B-F0D6BB998D0F@ericsson.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 11 Apr 2009 20:21:46 -0700 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Apr 2009 03:21:45.0496 (UTC) FILETIME=[CED01980:01C9BB1D] Subject: [savi] IETF 74 Meeting Materials Online X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 03:20:39 -0000 Hi Folks - All presentations from the SAVI meeting at IETF 74 are now available as PDF online [1]. Meeting minutes will follow shortly. Thanks to our minute takers Hui Deng, Jun Bi, and Bill Fenner! And thanks to Jun Bi also for currently compiling the minutes. - Christian [1] https://datatracker.ietf.org/meeting/74/materials.html From christian.vogt@ericsson.com Sat Apr 11 20:21:11 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00EBE3A697F for ; Sat, 11 Apr 2009 20:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eP6Heb0p1Mbj for ; Sat, 11 Apr 2009 20:21:10 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 361E83A697B for ; Sat, 11 Apr 2009 20:21:10 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n3C3VH9l015930 for ; Sat, 11 Apr 2009 22:31:17 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Apr 2009 22:22:19 -0500 Received: from [155.53.229.46] ([155.53.229.46]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Apr 2009 22:22:19 -0500 Message-Id: From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 11 Apr 2009 20:22:19 -0700 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Apr 2009 03:22:19.0198 (UTC) FILETIME=[E2E69DE0:01C9BB1D] Subject: [savi] Your Vote: Protection Scope on Multi-SAVI-Device Links X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 03:21:11 -0000 Folks - At the SAVI meeting in San Francisco, we discussed issues related to scenarios with multiple SAVI devices per link. In such scenarios, the lack of any coordination between the SAVI devices on a link would enable an attacker to spoof an on-link address in certain cases [1]. The reason is that, without coordination, SAVI devices may have incomplete knowledge of the addresses bound by other SAVI devices on their link, so they can reliably protect only those addresses that are bound by themselves and, consequently, used in a local environment around them. In San Francisco, we voted on whether people think that a local protection scope per SAVI device would be sufficient, or whether people wanted SAVI devices to provide link-wide protection. The result at the meeting was in favor of link-wide protection. I would now like to confirm this vote on this mailing list. On links with multiple SAVI devices, what should the protection scope of each SAVI device be? Please choose one of the following: (1) The protection scope should be link-wide for every SAVI device. (2) The protection scope can be local for a SAVI device. Please vote by Sunday, April 19, 2009. Note that voting for option (1) may, but does not necessarily imply that we need to devise an explicit "binding distribution protocol" for scenarios with multiple SAVI devices. It may be possible for SAVI devices to coordinate implicitly, e.g., by listening to address configuration traffic. More analysis is needed to figure out how the coordination could be realized best (and the discussion we had in San Francisco already provided some very useful input to such an analysis). - Christian [1] SAVI Binding Distribution Protocol (presented by Marcelo Bagnulo) http://www.ietf.org/proceedings/09mar/slides/savi-1.pdf From christian.vogt@ericsson.com Sat Apr 11 20:21:25 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25A63A6A70 for ; Sat, 11 Apr 2009 20:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReJ1W0RCz7Fo for ; Sat, 11 Apr 2009 20:21:25 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id D78DB3A6A48 for ; Sat, 11 Apr 2009 20:21:24 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n3C3VV83015965 for ; Sat, 11 Apr 2009 22:31:31 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Apr 2009 22:22:34 -0500 Received: from [155.53.229.46] ([155.53.229.46]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Apr 2009 22:22:33 -0500 Message-Id: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> From: Christian Vogt To: SAVI Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 11 Apr 2009 20:22:34 -0700 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Apr 2009 03:22:34.0026 (UTC) FILETIME=[EBBD30A0:01C9BB1D] Subject: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 03:21:25 -0000 Folks - At the SAVI meeting in San Francisco, we talked about the incremental deployment of SAVI. One question on this topic was whether we want SAVI devices to function in the presence of legacy switches on the same link. More specifically, we pondered whether we want SAVI to support arbitrary interconnections of SAVI devices and legacy switches on the same link. We voted on this question and the result was in favor of supporting such arbitrary interconnections. I would now like to confirm this vote on this mailing list. Should SAVI support links with arbitrary interconnections of SAVI devices and legacy switches? Please choose one of the following: (1) Yes, arbitrary interconnections of SAVI devices and legacy switches should be supported. (2) No, it is fine for SAVI to restrict how SAVI devices and legacy switches are interconnected. In case you vote for option (2), please describe briefly how you think said restriction should look like, and why you think this would be useful. Please vote by Sunday, April 19, 2009. - Christian From marcelo@it.uc3m.es Sun Apr 12 02:44:10 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B043A6B93 for ; Sun, 12 Apr 2009 02:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbJn3iD1NkF1 for ; Sun, 12 Apr 2009 02:44:09 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 024C23A6839 for ; Sun, 12 Apr 2009 02:44:08 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (138.pool85-53-140.dynamic.orange.es [85.53.140.138]) by smtp01.uc3m.es (Postfix) with ESMTP id 242FFB499EB; Sun, 12 Apr 2009 11:45:16 +0200 (CEST) Message-ID: <49E1B82B.8020103@it.uc3m.es> Date: Sun, 12 Apr 2009 11:45:15 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christian Vogt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16576.005 Cc: SAVI Mailing List Subject: Re: [savi] Your Vote: Protection Scope on Multi-SAVI-Device Links X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 09:44:10 -0000 Hi, My take on this is that it should be optional for savi devices to implement and to run the SAVI protocol (whether a SAVI verification protocol or a savi distribution protocol is a different discussion imho). I mean, i think that there are some topologies where the is no need to exchange any information. The trivial example is the case with a single switch in the link, but there are more interesting topologies. For instance, it seems to me that in some of the topologies considered by the broadband forum, there wouldn't really be a need for exchanging information between the savi devices, due to the characteristics of the topology (but this needs to be analysed in further detail). So, i think that running the savi protocol between devices should be a choice of the admin of the domain, based on the topology and the security level required. That is, in some topologies, the desired level of security can be achieved without running exchanging information between devices, while in other this is not possible. So, imho, what is needed is: - An analysis of the security level that is possible to achieve depending on the topology. - Define the protocol to exchange savi devices as an optional feature (probably in a different spec) Regards, marcelo Christian Vogt escribi: > Folks - > > At the SAVI meeting in San Francisco, we discussed issues related to > scenarios with multiple SAVI devices per link. In such scenarios, the > lack of any coordination between the SAVI devices on a link would enable > an attacker to spoof an on-link address in certain cases [1]. The > reason is that, without coordination, SAVI devices may have incomplete > knowledge of the addresses bound by other SAVI devices on their link, so > they can reliably protect only those addresses that are bound by > themselves and, consequently, used in a local environment around them. > > In San Francisco, we voted on whether people think that a local > protection scope per SAVI device would be sufficient, or whether people > wanted SAVI devices to provide link-wide protection. The result at the > meeting was in favor of link-wide protection. I would now like to > confirm this vote on this mailing list. > > On links with multiple SAVI devices, what should the protection scope of > each SAVI device be? Please choose one of the following: > > (1) The protection scope should be link-wide for every SAVI device. > > (2) The protection scope can be local for a SAVI device. > > Please vote by Sunday, April 19, 2009. > > Note that voting for option (1) may, but does not necessarily imply that > we need to devise an explicit "binding distribution protocol" for > scenarios with multiple SAVI devices. It may be possible for SAVI > devices to coordinate implicitly, e.g., by listening to address > configuration traffic. More analysis is needed to figure out how the > coordination could be realized best (and the discussion we had in San > Francisco already provided some very useful input to such an analysis). > > - Christian > > > [1] SAVI Binding Distribution Protocol (presented by Marcelo Bagnulo) > http://www.ietf.org/proceedings/09mar/slides/savi-1.pdf > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Sun Apr 12 03:08:59 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1FB3A68C5 for ; Sun, 12 Apr 2009 03:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSdMvczOzg4H for ; Sun, 12 Apr 2009 03:08:58 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id E481C3A6839 for ; Sun, 12 Apr 2009 03:08:57 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (138.pool85-53-140.dynamic.orange.es [85.53.140.138]) by smtp03.uc3m.es (Postfix) with ESMTP id AEFC872E1DA; Sun, 12 Apr 2009 12:10:05 +0200 (CEST) Message-ID: <49E1BDFD.6040301@it.uc3m.es> Date: Sun, 12 Apr 2009 12:10:05 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christian Vogt References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> In-Reply-To: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16576.005 Cc: SAVI Mailing List Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 10:08:59 -0000 Hi, I think the question here is what it means to be supported. Does this mean that the resulting security must be the same than if all the devices are SAVI devices? I guess not. So what level of security degradation is acceptable? I think this was not very clearly stated during the discussion in the meeting. I think that it is not very hard to support arbitrary mixes of savi and non savi devices as long we accept a security level degradation. We may want to quantify this. Basically, the impact is that you can track the spoofer up to the link rather than up to the actual host if the link contains a non savi device. The other interesting question is whether imposing some restrictions in the ways savi and non savi devices are interconnected would render some problems easy to deal with. For instance, would this make easier to secure the SAVI protocol? I don't feel i can answer to this question right now, but for me is important to keep in mind that the ways the savi devices and non savi devices are interconnected is another variable we can play with if we need to solve a hard problem. Regards, marcelo Christian Vogt escribi: > Folks - > > At the SAVI meeting in San Francisco, we talked about the incremental > deployment of SAVI. One question on this topic was whether we want SAVI > devices to function in the presence of legacy switches on the same link. > More specifically, we pondered whether we want SAVI to support arbitrary > interconnections of SAVI devices and legacy switches on the same link. > We voted on this question and the result was in favor of supporting such > arbitrary interconnections. I would now like to confirm this vote on > this mailing list. > > Should SAVI support links with arbitrary interconnections of SAVI > devices and legacy switches? Please choose one of the following: > > (1) Yes, arbitrary interconnections of SAVI devices and legacy switches > should be supported. > > (2) No, it is fine for SAVI to restrict how SAVI devices and legacy > switches are interconnected. > > In case you vote for option (2), please describe briefly how you think > said restriction should look like, and why you think this would be > useful. > > Please vote by Sunday, April 19, 2009. > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From christian.vogt@ericsson.com Sun Apr 12 15:28:49 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03A723A67E5 for ; Sun, 12 Apr 2009 15:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLFqVTouqK3f for ; Sun, 12 Apr 2009 15:28:48 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 236DB3A681E for ; Sun, 12 Apr 2009 15:28:48 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n3CMTuTD006698; Sun, 12 Apr 2009 17:29:57 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Apr 2009 17:29:57 -0500 Received: from [155.53.229.46] ([155.53.229.46]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 12 Apr 2009 17:29:56 -0500 Message-Id: <8AD873EB-A674-485B-A886-94929BC5AA55@ericsson.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <49E1BDFD.6040301@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 12 Apr 2009 15:29:55 -0700 References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> <49E1BDFD.6040301@it.uc3m.es> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 12 Apr 2009 22:29:56.0551 (UTC) FILETIME=[3514DD70:01C9BBBE] Cc: SAVI Mailing List Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 22:28:49 -0000 Marcelo - "Support for arbitrary interconnections of SAVI devices and legacy switches" is here meant as a robustness property: Does a SAVI device run havoc if it encounters a legacy switch on its link? Does it produce false positives? Does the binding distribution/verification protocol, if any, work across legacy switches? You are right that there may be security degradations on links with both types of switches. It would be unwise to assume that a link with legacy switches could be equally secured as a link where all switches are SAVI-capable. Personally, I like your idea of leaving us some flexibility with respect to possible link topology restrictions. We might find later that such restrictions can help us in the design of SAVI. At this stage, it is hard to tell whether restrictions could be useful, and if so, which type of restrictions. If you think we should leave us this flexibility, please vote for option (2). This doesn't mean that we shouldn't try to avoid any restrictions. But it means that we could live with them if we find that they are really useful. - Christian On Apr 12, 2009, at 3:10, marcelo bagnulo braun wrote: > Hi, > > I think the question here is what it means to be supported. Does this > mean that the resulting security must be the same than if all the > devices are SAVI devices? I guess not. So what level of security > degradation is acceptable? I think this was not very clearly stated > during the discussion in the meeting. I think that it is not very hard > to support arbitrary mixes of savi and non savi devices as long we > accept a security level degradation. We may want to quantify this. > Basically, the impact is that you can track the spoofer up to the link > rather than up to the actual host if the link contains a non savi > device. > > The other interesting question is whether imposing some restrictions > in > the ways savi and non savi devices are interconnected would render > some > problems easy to deal with. For instance, would this make easier to > secure the SAVI protocol? I don't feel i can answer to this question > right now, but for me is important to keep in mind that the ways the > savi devices and non savi devices are interconnected is another > variable > we can play with if we need to solve a hard problem. > > > Regards, marcelo From kyking6@gmail.com Sun Apr 12 21:54:22 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957203A6452 for ; Sun, 12 Apr 2009 21:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UJGJN9u5uBv for ; Sun, 12 Apr 2009 21:54:21 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id C5EA13A68A3 for ; Sun, 12 Apr 2009 21:54:21 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l35so943649waf.5 for ; Sun, 12 Apr 2009 21:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=g+B1v21RJXbncOyVPSM9o9gtgumZ0xJEoBDkr0WYlXY=; b=bwfApB/InSLfbG42hlk4RrNKdG7G2EtkFMziV8Bj/Ty/1mw/9hELUl3vhJ/t31k31N tecdO1BDhOwv0RWAIKfbugEuZyNtAJjqXPUXcj2a7T4Y0P3vuoZqJeBXqtlnzpKwmJLh 4v9XDgTBJpPy64DETtIH11scg8vub54Mb/32s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ve/ef/Z2eNglHy/XBdlXBZM5wmMNRz1cP+9erWMiqIImNrstkCC5ToohY56yV/EB/2 nZq6hid8rVhELOGFbSCxBSt7v/CZoWf6ooR7wuQkF9zEdVQsJYVNrXS0jlmyFWgQgesB ID/jaQ8flY8XXfLx7Fs+oWAjZLHRNASxF8P/g= MIME-Version: 1.0 Received: by 10.114.146.4 with SMTP id t4mr3011431wad.143.1239598532288; Sun, 12 Apr 2009 21:55:32 -0700 (PDT) In-Reply-To: <8CAA4D13-6238-47A6-A33B-F0D6BB998D0F@ericsson.com> References: <8CAA4D13-6238-47A6-A33B-F0D6BB998D0F@ericsson.com> Date: Mon, 13 Apr 2009 12:55:32 +0800 Message-ID: <3dd97b820904122155v6360a693i8b7a8a92a478c10a@mail.gmail.com> From: Kevin Y To: Christian Vogt Content-Type: multipart/alternative; boundary=0016364589962e60e3046768868a Cc: SAVI Mailing List Subject: Re: [savi] IETF 74 Meeting Materials Online X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 04:54:22 -0000 --0016364589962e60e3046768868a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit hmm..., did try url, there still no minutes yet. /kevin On Sun, Apr 12, 2009 at 11:21 AM, Christian Vogt < christian.vogt@ericsson.com> wrote: > Hi Folks - > > All presentations from the SAVI meeting at IETF 74 are now available as > PDF online [1]. Meeting minutes will follow shortly. Thanks to our > minute takers Hui Deng, Jun Bi, and Bill Fenner! And thanks to Jun Bi > also for currently compiling the minutes. > > - Christian > > > [1] https://datatracker.ietf.org/meeting/74/materials.html > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > --0016364589962e60e3046768868a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
hmm...,=A0 did try url,=A0=A0 there=A0still no minutes yet.
=A0
/kevin

=A0
On Sun, Apr 12, 2009 at 11:21 AM, Christian Vogt= <chris= tian.vogt@ericsson.com> wrote:
Hi Folks -

All presentati= ons from the SAVI meeting at IETF 74 are now available as
PDF online [1]= . =A0Meeting minutes will follow shortly. =A0Thanks to our
minute takers Hui Deng, Jun Bi, and Bill Fenner! =A0And thanks to Jun Bialso for currently compiling the minutes.

- Christian


[1= ] https://datatracker.ietf.org/meeting/74/materials.html



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

--0016364589962e60e3046768868a-- From hiromi@inetcore.com Mon Apr 13 03:07:53 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A663A6D36 for ; Mon, 13 Apr 2009 03:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.45 X-Spam-Level: ** X-Spam-Status: No, score=2.45 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dSKzWLQ7-+X for ; Mon, 13 Apr 2009 03:07:52 -0700 (PDT) Received: from inc.inetcore.com (p0245a2.tokyff01.ap.so-net.ne.jp [121.2.69.162]) by core3.amsl.com (Postfix) with ESMTP id 8972E3A67EF for ; Mon, 13 Apr 2009 03:07:52 -0700 (PDT) Received: from [IPv6:2403:2000:1:1:21b:63ff:fec9:f412] (unknown [IPv6:2403:2000:1:1:21b:63ff:fec9:f412]) by inc.inetcore.com (Postfix) with ESMTPSA id 6DC132C76A0 for ; Mon, 13 Apr 2009 19:08:32 +0900 (JST) Message-Id: From: Ruri Hiromi To: SAVI Mailing List In-Reply-To: <3dd97b820904122155v6360a693i8b7a8a92a478c10a@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 19:08:31 +0900 References: <8CAA4D13-6238-47A6-A33B-F0D6BB998D0F@ericsson.com> <3dd97b820904122155v6360a693i8b7a8a92a478c10a@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [savi] IETF 74 Meeting Materials Online X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 10:07:53 -0000 ... and I also could find at http://tools.ietf.org/wg/savi/minutes On 2009/04/13, at 13:55, Kevin Y wrote: > hmm..., did try url, there still no minutes yet. > > /kevin > > > On Sun, Apr 12, 2009 at 11:21 AM, Christian Vogt > wrote: > Hi Folks - > > All presentations from the SAVI meeting at IETF 74 are now available > as > PDF online [1]. Meeting minutes will follow shortly. Thanks to our > minute takers Hui Deng, Jun Bi, and Bill Fenner! And thanks to Jun Bi > also for currently compiling the minutes. > > - Christian > > > [1] https://datatracker.ietf.org/meeting/74/materials.html > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi ------------------------------- Ruri Hiromi Intec NetCore, Inc. / Keio university hiromi@inetcore.com From hiromi@inetcore.com Mon Apr 13 03:09:30 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8A443A6D38 for ; Mon, 13 Apr 2009 03:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.24 X-Spam-Level: ** X-Spam-Status: No, score=2.24 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN4KRJ+KayaY for ; Mon, 13 Apr 2009 03:09:30 -0700 (PDT) Received: from inc.inetcore.com (p0245a2.tokyff01.ap.so-net.ne.jp [121.2.69.162]) by core3.amsl.com (Postfix) with ESMTP id 36AFE3A6D2F for ; Mon, 13 Apr 2009 03:09:29 -0700 (PDT) Received: from [IPv6:2403:2000:1:1:21b:63ff:fec9:f412] (unknown [IPv6:2403:2000:1:1:21b:63ff:fec9:f412]) by inc.inetcore.com (Postfix) with ESMTPSA id 495392C766A for ; Mon, 13 Apr 2009 19:10:10 +0900 (JST) Message-Id: <404061CC-3D3F-47BB-BFFC-9FE0123032E7@inetcore.com> From: Ruri Hiromi To: SAVI Mailing List In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 19:10:09 +0900 References: <8CAA4D13-6238-47A6-A33B-F0D6BB998D0F@ericsson.com> <3dd97b820904122155v6360a693i8b7a8a92a478c10a@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [savi] IETF 74 Meeting Materials Online X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 10:09:31 -0000 ops, I meant I could NOT... On 2009/04/13, at 19:08, Ruri Hiromi wrote: > ... and I also could find at http://tools.ietf.org/wg/savi/minutes > > On 2009/04/13, at 13:55, Kevin Y wrote: > >> hmm..., did try url, there still no minutes yet. >> >> /kevin >> >> >> On Sun, Apr 12, 2009 at 11:21 AM, Christian Vogt > > wrote: >> Hi Folks - >> >> All presentations from the SAVI meeting at IETF 74 are now >> available as >> PDF online [1]. Meeting minutes will follow shortly. Thanks to our >> minute takers Hui Deng, Jun Bi, and Bill Fenner! And thanks to Jun >> Bi >> also for currently compiling the minutes. >> >> - Christian >> >> >> [1] https://datatracker.ietf.org/meeting/74/materials.html >> >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > ------------------------------- > Ruri Hiromi > Intec NetCore, Inc. / Keio university > hiromi@inetcore.com > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi ------------------------------- Ruri Hiromi Intec NetCore, Inc. / Keio university hiromi@inetcore.com From junbi@cernet.edu.cn Mon Apr 13 09:00:20 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9353A3A69BA for ; Mon, 13 Apr 2009 09:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.511 X-Spam-Level: ** X-Spam-Status: No, score=2.511 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG4v76Ps22pZ for ; Mon, 13 Apr 2009 09:00:20 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 547F93A6801 for ; Mon, 13 Apr 2009 09:00:18 -0700 (PDT) Received: from userPC([59.66.24.184]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm1b49e37a02; Tue, 14 Apr 2009 00:01:28 +0800 Message-ID: <5ED376A47C3A4AB8BFB984D59C7B0F2A@userPC> From: "Jun Bi" To: "Christian Vogt" , "SAVI Mailing List" References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> In-Reply-To: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> Date: Tue, 14 Apr 2009 00:01:08 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: mHKbYtVB Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 16:00:20 -0000 Hi All, I vote (1). Reason: certainly the operator should consider the incremental deployment and the *general* topology. It's easy for the operator to configure the switch with CLI, but it's not easy to change the existing topology. thanks, Jun Bi ----- Original Message ----- > > (1) Yes, arbitrary interconnections of SAVI devices and legacy switches > should be supported. > From junbi@cernet.edu.cn Mon Apr 13 09:15:27 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42E93A6EA5 for ; Mon, 13 Apr 2009 09:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.511 X-Spam-Level: ** X-Spam-Status: No, score=2.511 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_HAS_XAIMC=2.696] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WF4KwNVmh46V for ; Mon, 13 Apr 2009 09:15:27 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 818CA3A6EB2 for ; Mon, 13 Apr 2009 09:15:26 -0700 (PDT) Received: from userPC([59.66.24.184]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm1b49e37d8e; Tue, 14 Apr 2009 00:16:36 +0800 Message-ID: <0BE1E57E88FA44D582D17CE38402425D@userPC> From: "Jun Bi" To: "Christian Vogt" , "SAVI Mailing List" References: In-Reply-To: Date: Tue, 14 Apr 2009 00:16:16 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: mBopYtVB Subject: Re: [savi] Your Vote: Protection Scope on Multi-SAVI-Device Links X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 16:15:27 -0000 ----- Original Message ----- From: "Christian Vogt" To: "SAVI Mailing List" Sent: Sunday, April 12, 2009 11:22 AM Subject: [savi] Your Vote: Protection Scope on Multi-SAVI-Device Links > > (1) The protection scope should be link-wide for every SAVI device. > Hi All, Vote for (1). Reason: If chose (2), it may cause severe problems. E.g. if SAVI device#1 has incomplete knowledge of the addresses bound by SAVI device#2 on their link, then host A under SAVI device#1 may spoof the source address of host B who is already bound under SAVI device#2. > Note that voting for option (1) may, but does not necessarily imply that > we need to devise an explicit "binding distribution protocol" for > scenarios with multiple SAVI devices. It may be possible for SAVI > devices to coordinate implicitly, e.g., by listening to address > configuration traffic. Agree with Christian's note, it is possbile for SAVI devices to coordinate by snooping the control packets. thansk, Jun Bi From dthaler@windows.microsoft.com Mon Apr 13 09:27:36 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 024183A6D99 for ; Mon, 13 Apr 2009 09:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.503 X-Spam-Level: X-Spam-Status: No, score=-110.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOPNBnskgMmx for ; Mon, 13 Apr 2009 09:27:35 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 45A9E3A6C3D for ; Mon, 13 Apr 2009 09:27:35 -0700 (PDT) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 13 Apr 2009 09:28:46 -0700 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.2.99.4; Mon, 13 Apr 2009 09:28:45 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Mon, 13 Apr 2009 09:30:43 -0700 From: Dave Thaler To: Christian Vogt , SAVI Mailing List Date: Mon, 13 Apr 2009 09:28:44 -0700 Thread-Topic: [savi] Your Vote: Incremental SAVI Deployment Thread-Index: Acm7HfST4bGbespfRs+F3rasMEet5QBNtF0g Message-ID: References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> In-Reply-To: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 16:27:36 -0000 For those of us who weren't in the meeting, it would help to vote if we better understood the consequences of (1) and the consequences of (2)= . For example, what's the disadvantage of (1)? -Dave > -----Original Message----- > From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of > Christian Vogt > Sent: Saturday, April 11, 2009 8:23 PM > To: SAVI Mailing List > Subject: [savi] Your Vote: Incremental SAVI Deployment > > Folks - > > At the SAVI meeting in San Francisco, we talked about the incremental > deployment of SAVI. One question on this topic was whether we want > SAVI > devices to function in the presence of legacy switches on the same > link. > More specifically, we pondered whether we want SAVI to support > arbitrary > interconnections of SAVI devices and legacy switches on the same link. > We voted on this question and the result was in favor of supporting > such > arbitrary interconnections. I would now like to confirm this vote on > this mailing list. > > Should SAVI support links with arbitrary interconnections of SAVI > devices and legacy switches? Please choose one of the following: > > (1) Yes, arbitrary interconnections of SAVI devices and legacy switches > should be supported. > > (2) No, it is fine for SAVI to restrict how SAVI devices and legacy > switches are interconnected. > > In case you vote for option (2), please describe briefly how you think > said restriction should look like, and why you think this would be > useful. > > Please vote by Sunday, April 19, 2009. > > - Christian > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From junbi@tsinghua.edu.cn Mon Apr 13 20:11:42 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F73A3A689A for ; Mon, 13 Apr 2009 20:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vap6ODX-ceJt for ; Mon, 13 Apr 2009 20:11:41 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 50AE93A681A for ; Mon, 13 Apr 2009 20:11:40 -0700 (PDT) Received: from th024184.ip.tsinghua.edu.cn ([59.66.24.184] helo=userPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1LtZ4W-0000wO-PF; Tue, 14 Apr 2009 11:12:28 +0800 Message-ID: <4D15419B07B64EADAB02FDB506338123@userPC> From: "Jun Bi" To: "Dave Thaler" , "Christian Vogt" , "SAVI Mailing List" References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> In-Reply-To: Date: Tue, 14 Apr 2009 11:12:09 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jun Bi List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 03:11:42 -0000 Hi, I think here we are voting for the requirements from operators (users of SAVI), not from the viewpoints from solution designers. The scenario is that the operators could not replace all existing legacy switches on one signal day (it's a common case in realistic). So when one legacy switch is out of its lifetime, the operator may replace this old switch with one NEW SAVI device. So the advantage of (1) is to bring more flexibilities to operators. It seems there would be no disadvantage of (1) from operators' viewpoints when deploying SAVI on an existing subnet). The disadvantage of (2) seems to be bring some restricts to operators when they replace a legacy switch on an existing subnet. thanks, Jun Bi ----- Original Message ----- From: "Dave Thaler" To: "Christian Vogt" ; "SAVI Mailing List" Sent: Tuesday, April 14, 2009 12:28 AM Subject: Re: [savi] Your Vote: Incremental SAVI Deployment > For those of us who weren't in the meeting, it would help to vote > if we better understood the consequences of (1) and the consequences of > (2). > For example, what's the disadvantage of (1)? > > -Dave > >> -----Original Message----- >> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf Of >> Christian Vogt >> Sent: Saturday, April 11, 2009 8:23 PM >> To: SAVI Mailing List >> Subject: [savi] Your Vote: Incremental SAVI Deployment >> >> Folks - >> >> At the SAVI meeting in San Francisco, we talked about the incremental >> deployment of SAVI. One question on this topic was whether we want >> SAVI >> devices to function in the presence of legacy switches on the same >> link. >> More specifically, we pondered whether we want SAVI to support >> arbitrary >> interconnections of SAVI devices and legacy switches on the same link. >> We voted on this question and the result was in favor of supporting >> such >> arbitrary interconnections. I would now like to confirm this vote on >> this mailing list. >> >> Should SAVI support links with arbitrary interconnections of SAVI >> devices and legacy switches? Please choose one of the following: >> >> (1) Yes, arbitrary interconnections of SAVI devices and legacy switches >> should be supported. >> >> (2) No, it is fine for SAVI to restrict how SAVI devices and legacy >> switches are interconnected. >> >> In case you vote for option (2), please describe briefly how you think >> said restriction should look like, and why you think this would be >> useful. >> >> Please vote by Sunday, April 19, 2009. >> >> - Christian >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From dthaler@windows.microsoft.com Mon Apr 13 22:01:08 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 953C63A69F1 for ; Mon, 13 Apr 2009 22:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.504 X-Spam-Level: X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ5B8Ud4Bv4m for ; Mon, 13 Apr 2009 22:01:07 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 21C643A6D6E for ; Mon, 13 Apr 2009 22:01:00 -0700 (PDT) Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Mon, 13 Apr 2009 22:02:11 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) with Microsoft SMTP Server id 8.2.99.4; Mon, 13 Apr 2009 22:02:11 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Mon, 13 Apr 2009 22:00:23 -0700 From: Dave Thaler To: Jun Bi , Christian Vogt , SAVI Mailing List Date: Mon, 13 Apr 2009 22:00:21 -0700 Thread-Topic: [savi] Your Vote: Incremental SAVI Deployment Thread-Index: Acm8rxNu/bkMCMYLQeycTUO+il6f8QADq0Bw Message-ID: References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> <4D15419B07B64EADAB02FDB506338123@userPC> In-Reply-To: <4D15419B07B64EADAB02FDB506338123@userPC> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 05:01:08 -0000 If (1) had no disadvantages then why would anyone vote for (2)? There must be something (e.g. complexity of solution). -Dave > -----Original Message----- > From: Jun Bi [mailto:junbi@tsinghua.edu.cn] > Sent: Monday, April 13, 2009 8:12 PM > To: Dave Thaler; Christian Vogt; SAVI Mailing List > Subject: Re: [savi] Your Vote: Incremental SAVI Deployment > > Hi, > > I think here we are voting for the requirements from operators (users > of > SAVI), not from the viewpoints from solution designers. > > The scenario is that the operators could not replace all existing > legacy > switches on one signal day > (it's a common case in realistic). So when one legacy switch is out of > its > lifetime, the operator may replace > this old switch with one NEW SAVI device. > > So the advantage of (1) is to bring more flexibilities to operators. > It seems there would be no disadvantage of (1) from operators' > viewpoints > when deploying SAVI on an existing subnet). > The disadvantage of (2) seems to be bring some restricts to operators > when > they replace a legacy switch on an existing subnet. > > thanks, > Jun Bi > > > > ----- Original Message ----- > From: "Dave Thaler" > To: "Christian Vogt" ; "SAVI Mailing List" > > Sent: Tuesday, April 14, 2009 12:28 AM > Subject: Re: [savi] Your Vote: Incremental SAVI Deployment > > > > For those of us who weren't in the meeting, it would help to vote > > if we better understood the consequences of (1) and the consequences > of > > (2). > > For example, what's the disadvantage of (1)? > > > > -Dave > > > >> -----Original Message----- > >> From: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] On Behalf > Of > >> Christian Vogt > >> Sent: Saturday, April 11, 2009 8:23 PM > >> To: SAVI Mailing List > >> Subject: [savi] Your Vote: Incremental SAVI Deployment > >> > >> Folks - > >> > >> At the SAVI meeting in San Francisco, we talked about the > incremental > >> deployment of SAVI. One question on this topic was whether we want > >> SAVI > >> devices to function in the presence of legacy switches on the same > >> link. > >> More specifically, we pondered whether we want SAVI to support > >> arbitrary > >> interconnections of SAVI devices and legacy switches on the same > link. > >> We voted on this question and the result was in favor of supporting > >> such > >> arbitrary interconnections. I would now like to confirm this vote > on > >> this mailing list. > >> > >> Should SAVI support links with arbitrary interconnections of SAVI > >> devices and legacy switches? Please choose one of the following: > >> > >> (1) Yes, arbitrary interconnections of SAVI devices and legacy > switches > >> should be supported. > >> > >> (2) No, it is fine for SAVI to restrict how SAVI devices and legacy > >> switches are interconnected. > >> > >> In case you vote for option (2), please describe briefly how you > think > >> said restriction should look like, and why you think this would be > >> useful. > >> > >> Please vote by Sunday, April 19, 2009. > >> > >> - Christian > >> > >> > >> _______________________________________________ > >> savi mailing list > >> savi@ietf.org > >> https://www.ietf.org/mailman/listinfo/savi > > > > _______________________________________________ > > savi mailing list > > savi@ietf.org > > https://www.ietf.org/mailman/listinfo/savi > > > > > > From fred@cisco.com Mon Apr 13 23:01:05 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7CDF3A6D93 for ; Mon, 13 Apr 2009 23:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.481 X-Spam-Level: X-Spam-Status: No, score=-106.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0m-y5hqzL0U for ; Mon, 13 Apr 2009 23:01:04 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B565B3A67D1 for ; Mon, 13 Apr 2009 23:00:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,183,1238976000"; d="scan'208";a="285732921" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2009 06:01:47 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3E61l34003785; Mon, 13 Apr 2009 23:01:47 -0700 Received: from [192.168.21.57] (sjc-vpn5-1847.cisco.com [10.21.95.55]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3E61b62013416; Tue, 14 Apr 2009 06:01:43 GMT Message-Id: <98FDC3D5-235C-4564-9E1E-99D4CA9B94F7@cisco.com> From: Fred Baker To: Dave Thaler In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 22:49:50 -0700 References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> <4D15419B07B64EADAB02FDB506338123@userPC> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1982; t=1239688907; x=1240552907; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Your=20Vote=3A=20Incremental=2 0SAVI=20Deployment |Sender:=20; bh=UVBvHk+PLhsF9yPg2fqRVeHEtzut5L2XDAQ7FxGAvkc=; b=kk8/sFpuUEieRfdMEtBPmiSeZRtsDFweO5hygtbP3uLF/p1Rkd17VMMT84 pUcrxQYTIN4je7vo/wYaJjCfOph7p0P0A1zLkTfJNaFZIlsmw0NGp0/QWqo8 4zjF+Z3F3W; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 06:01:05 -0000 > (1) Yes, arbitrary interconnections of SAVI devices and legacy > switches should be supported. > > (2) No, it is fine for SAVI to restrict how SAVI devices and legacy > switches are interconnected. From my perspective, you can hook savi switches together any way you like, but the effects of some configurations may differ from others. SAVI switches are intelligent. They are not magical. The real question here relates to the address distribution protocol that Christian is pushing. I think the SAVI switch is securing the things it serves; it is not securing the entire switching domain. If a savi switch is attached to a non-savi switch, the non-savi switch will not participate in the protocol. The savi switch could determine by observation (snooping or fcfs) what addresses come from it, but it won't know how many ports there are, so it will have limited capabilities at best. If the same savi switch is attached to another savi switch, that savi switch will secure its own ports. So in the first case, the savi switch can't protect against ports not on it, and in the second case it has no need to - the other savi switch will do that. If an attacker uses SLAAC, when it sends out the DAD probe, the user of the address will reply. If a savi switch sees an address being used with the wrong MAC (across a neighboring switch, savi or otherwise), it can reply with a DAD reponse, and the switch can install a filter to make that address go away. That, or we develop a protocol to do the same thing, but only if someone can explain why DAD is insufficient. Consider this. If I have a cheap five port 10/100/1000 switch attached to a network containing several cat 6Ks, the BDP model requires the cheap switch to have enough memory to store the entire savi table for the entire swithed domain. "Cheap" goes straight down the toilet if we do that, and as a result so will the standard. From junbi@tsinghua.edu.cn Tue Apr 14 08:02:19 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A0B3A692C for ; Tue, 14 Apr 2009 08:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.755 X-Spam-Level: X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja4nNoFOCbVy for ; Tue, 14 Apr 2009 08:02:18 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 2AACF3A659C for ; Tue, 14 Apr 2009 08:02:16 -0700 (PDT) Received: from th024184.ip.tsinghua.edu.cn ([59.66.24.184] helo=userPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1LtkAH-0002nI-QL; Tue, 14 Apr 2009 23:03:09 +0800 Message-ID: <9D3EC51661564E449E1DEF012F6CAE3E@userPC> From: "Jun Bi" To: "Fred Baker" , "Dave Thaler" References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> <4D15419B07B64EADAB02FDB506338123@userPC> <98FDC3D5-235C-4564-9E1E-99D4CA9B94F7@cisco.com> In-Reply-To: <98FDC3D5-235C-4564-9E1E-99D4CA9B94F7@cisco.com> Date: Tue, 14 Apr 2009 23:02:48 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jun Bi List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 15:02:19 -0000 Thank Fred's analysis. The words for voting is a little bit confusing. To accurately express my option, I want to express in the following way: "Under the arbitrary interconnections of SAVI devices and legacy switches, SAVI device must LINK-WIDELY CORRECTLY anti-spoof for hosts directly attached to it". For example, we have SAVI devices S1 and S2, and legacy device L1 and L2. S1 directly connects hosts A1, A2 S2 directly connects hosts B1, B2 L1 directly connects hosts C1, C2 Given ANY topology of S1, S2, L2 (arbitrary interconnections), the requirements to solutions are: (1) if source address of A1 is legally assigned, then if any of A2, B1 or B2 uses A1' source address, then the packets would be dropped by S1 or S2, but C1,C2 MAY still send packets with A1's source address. (2) if source address of B1 is legally assigned, then any of A1, A2, B2 could not spoof B1's source address. C1 and C2 MAY still spoof. (3) if source address of C1 is legally assigned, then any of A1, A2, B1, B2, could not spoof C1's source address, but C2 MAY still spoof. Again, I don't mean we need a BDP to achieve this goal, the goal could be achieved by snooping and using the existing control protocols. thanks, Jun Bi ----- Original Message ----- From: "Fred Baker" To: "Dave Thaler" Cc: "Jun Bi" ; "Christian Vogt" ; "SAVI Mailing List" Sent: Tuesday, April 14, 2009 1:49 PM Subject: Re: [savi] Your Vote: Incremental SAVI Deployment >> (1) Yes, arbitrary interconnections of SAVI devices and legacy switches >> should be supported. >> >> (2) No, it is fine for SAVI to restrict how SAVI devices and legacy >> switches are interconnected. > > From my perspective, you can hook savi switches together any way you like, > but the effects of some configurations may differ from others. SAVI > switches are intelligent. They are not magical. > > The real question here relates to the address distribution protocol that > Christian is pushing. > > I think the SAVI switch is securing the things it serves; it is not > securing the entire switching domain. > > If a savi switch is attached to a non-savi switch, the non-savi switch > will not participate in the protocol. The savi switch could determine by > observation (snooping or fcfs) what addresses come from it, but it won't > know how many ports there are, so it will have limited capabilities at > best. If the same savi switch is attached to another savi switch, that > savi switch will secure its own ports. So in the first case, the savi > switch can't protect against ports not on it, and in the second case it > has no need to - the other savi switch will do that. > > If an attacker uses SLAAC, when it sends out the DAD probe, the user of > the address will reply. If a savi switch sees an address being used with > the wrong MAC (across a neighboring switch, savi or otherwise), it can > reply with a DAD reponse, and the switch can install a filter to make > that address go away. That, or we develop a protocol to do the same > thing, but only if someone can explain why DAD is insufficient. > > Consider this. If I have a cheap five port 10/100/1000 switch attached to > a network containing several cat 6Ks, the BDP model requires the cheap > switch to have enough memory to store the entire savi table for the > entire swithed domain. "Cheap" goes straight down the toilet if we do > that, and as a result so will the standard. > > > From fred@cisco.com Tue Apr 14 08:07:47 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BD0E3A6E35 for ; Tue, 14 Apr 2009 08:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrO9CHLGCDwq for ; Tue, 14 Apr 2009 08:07:46 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 29E003A6E30 for ; Tue, 14 Apr 2009 08:07:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,185,1238976000"; d="scan'208";a="153134527" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 14 Apr 2009 15:08:57 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3EF8v23020925; Tue, 14 Apr 2009 08:08:57 -0700 Received: from [192.168.21.57] (sjc-vpn5-1847.cisco.com [10.21.95.55]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3EF8urS028593; Tue, 14 Apr 2009 15:08:57 GMT From: Fred Baker To: "Jun Bi" In-Reply-To: <9D3EC51661564E449E1DEF012F6CAE3E@userPC> X-Priority: 3 References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> <4D15419B07B64EADAB02FDB506338123@userPC> <98FDC3D5-235C-4564-9E1E-99D4CA9B94F7@cisco.com> <9D3EC51661564E449E1DEF012F6CAE3E@userPC> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 08:08:56 -0700 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4107; t=1239721737; x=1240585737; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Your=20Vote=3A=20Incremental=2 0SAVI=20Deployment |Sender:=20; bh=6RScQe2w+ZMG51sBKpA+nRSj64mB1i1GvNlMeq0JRp8=; b=DBUSx1yV/Tvma9f0U7toCwq7y8i19ACwT7m0krT9T4Wio5oEyqN+w2E3Jz LsCmS3+qksW/CtR24LFm4s3wK0YEkZqThvviRf68thW/ofQqJlYjYj284lKB KIH204Tws8; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 15:07:47 -0000 I think you are saying that a network is protected from spoofing by a given host if and only if the switch that host is attached to is protecting the network - eg, is a savi switch. That makes sense to me. On Apr 14, 2009, at 8:02 AM, Jun Bi wrote: > Thank Fred's analysis. > > The words for voting is a little bit confusing. > To accurately express my option, I want to express in the following > way: > > "Under the arbitrary interconnections of SAVI devices and legacy > switches, > SAVI device must LINK-WIDELY CORRECTLY anti-spoof for hosts directly > attached to it". > > For example, we have SAVI devices S1 and S2, and legacy device L1 > and L2. > S1 directly connects hosts A1, A2 > S2 directly connects hosts B1, B2 > L1 directly connects hosts C1, C2 > > Given ANY topology of S1, S2, L2 (arbitrary interconnections), the > requirements to solutions are: > (1) if source address of A1 is legally assigned, then if any of A2, > B1 or B2 > uses A1' source address, then the packets would be dropped by S1 or > S2, but > C1,C2 MAY still send packets with A1's source address. > (2) if source address of B1 is legally assigned, then any of A1, A2, > B2 > could not spoof B1's source address. C1 and C2 MAY still spoof. > (3) if source address of C1 is legally assigned, then any of A1, A2, > B1, B2, > could not spoof C1's source address, but C2 MAY still spoof. > > Again, I don't mean we need a BDP to achieve this goal, the goal > could be achieved by > snooping and using the existing control protocols. > > thanks, > Jun Bi > > > > > > ----- Original Message ----- From: "Fred Baker" > To: "Dave Thaler" > Cc: "Jun Bi" ; "Christian Vogt" > ; "SAVI Mailing List" > Sent: Tuesday, April 14, 2009 1:49 PM > Subject: Re: [savi] Your Vote: Incremental SAVI Deployment > > >>> (1) Yes, arbitrary interconnections of SAVI devices and legacy >>> switches should be supported. >>> >>> (2) No, it is fine for SAVI to restrict how SAVI devices and >>> legacy switches are interconnected. >> >> From my perspective, you can hook savi switches together any way >> you like, but the effects of some configurations may differ from >> others. SAVI switches are intelligent. They are not magical. >> >> The real question here relates to the address distribution >> protocol that Christian is pushing. >> >> I think the SAVI switch is securing the things it serves; it is not >> securing the entire switching domain. >> >> If a savi switch is attached to a non-savi switch, the non-savi >> switch will not participate in the protocol. The savi switch could >> determine by observation (snooping or fcfs) what addresses come >> from it, but it won't know how many ports there are, so it will >> have limited capabilities at best. If the same savi switch is >> attached to another savi switch, that savi switch will secure its >> own ports. So in the first case, the savi switch can't protect >> against ports not on it, and in the second case it has no need to >> - the other savi switch will do that. >> >> If an attacker uses SLAAC, when it sends out the DAD probe, the >> user of the address will reply. If a savi switch sees an address >> being used with the wrong MAC (across a neighboring switch, savi >> or otherwise), it can reply with a DAD reponse, and the switch can >> install a filter to make that address go away. That, or we develop >> a protocol to do the same thing, but only if someone can explain >> why DAD is insufficient. >> >> Consider this. If I have a cheap five port 10/100/1000 switch >> attached to a network containing several cat 6Ks, the BDP model >> requires the cheap switch to have enough memory to store the >> entire savi table for the entire swithed domain. "Cheap" goes >> straight down the toilet if we do that, and as a result so will >> the standard. >> >> >> > > From junbi@tsinghua.edu.cn Tue Apr 14 22:26:42 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7A43A6859 for ; Tue, 14 Apr 2009 22:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtKCWEx1QXGQ for ; Tue, 14 Apr 2009 22:26:41 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 968E73A6778 for ; Tue, 14 Apr 2009 22:26:41 -0700 (PDT) Received: from th053130.ip.tsinghua.edu.cn ([59.66.53.130] helo=userPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Ltxeg-0008Au-PD; Wed, 15 Apr 2009 13:27:26 +0800 Message-ID: <4A9E3CB067A3401C9E7B63EA3CBDE568@userPC> From: "Jun Bi" To: "Fred Baker" References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> <4D15419B07B64EADAB02FDB506338123@userPC> <98FDC3D5-235C-4564-9E1E-99D4CA9B94F7@cisco.com> <9D3EC51661564E449E1DEF012F6CAE3E@userPC> In-Reply-To: Date: Wed, 15 Apr 2009 13:27:04 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jun Bi List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 05:26:42 -0000 Yes, thanks. Jun Bi ----- Original Message ----- From: "Fred Baker" To: "Jun Bi" Cc: "Dave Thaler" ; "Christian Vogt" ; "SAVI Mailing List" Sent: Tuesday, April 14, 2009 11:08 PM Subject: Re: [savi] Your Vote: Incremental SAVI Deployment >I think you are saying that a network is protected from spoofing by a >given host if and only if the switch that host is attached to is >protecting the network - eg, is a savi switch. That makes sense to me. > > On Apr 14, 2009, at 8:02 AM, Jun Bi wrote: > >> Thank Fred's analysis. >> >> The words for voting is a little bit confusing. >> To accurately express my option, I want to express in the following way: >> >> "Under the arbitrary interconnections of SAVI devices and legacy >> switches, >> SAVI device must LINK-WIDELY CORRECTLY anti-spoof for hosts directly >> attached to it". >> >> For example, we have SAVI devices S1 and S2, and legacy device L1 and >> L2. >> S1 directly connects hosts A1, A2 >> S2 directly connects hosts B1, B2 >> L1 directly connects hosts C1, C2 >> >> Given ANY topology of S1, S2, L2 (arbitrary interconnections), the >> requirements to solutions are: >> (1) if source address of A1 is legally assigned, then if any of A2, B1 >> or B2 >> uses A1' source address, then the packets would be dropped by S1 or S2, >> but >> C1,C2 MAY still send packets with A1's source address. >> (2) if source address of B1 is legally assigned, then any of A1, A2, B2 >> could not spoof B1's source address. C1 and C2 MAY still spoof. >> (3) if source address of C1 is legally assigned, then any of A1, A2, B1, >> B2, >> could not spoof C1's source address, but C2 MAY still spoof. >> >> Again, I don't mean we need a BDP to achieve this goal, the goal could >> be achieved by >> snooping and using the existing control protocols. >> >> thanks, >> Jun Bi >> >> >> >> >> >> ----- Original Message ----- From: "Fred Baker" >> To: "Dave Thaler" >> Cc: "Jun Bi" ; "Christian Vogt" >> ; "SAVI Mailing List" >> Sent: Tuesday, April 14, 2009 1:49 PM >> Subject: Re: [savi] Your Vote: Incremental SAVI Deployment >> >> >>>> (1) Yes, arbitrary interconnections of SAVI devices and legacy >>>> switches should be supported. >>>> >>>> (2) No, it is fine for SAVI to restrict how SAVI devices and legacy >>>> switches are interconnected. >>> >>> From my perspective, you can hook savi switches together any way you >>> like, but the effects of some configurations may differ from others. >>> SAVI switches are intelligent. They are not magical. >>> >>> The real question here relates to the address distribution protocol >>> that Christian is pushing. >>> >>> I think the SAVI switch is securing the things it serves; it is not >>> securing the entire switching domain. >>> >>> If a savi switch is attached to a non-savi switch, the non-savi switch >>> will not participate in the protocol. The savi switch could determine >>> by observation (snooping or fcfs) what addresses come from it, but it >>> won't know how many ports there are, so it will have limited >>> capabilities at best. If the same savi switch is attached to another >>> savi switch, that savi switch will secure its own ports. So in the >>> first case, the savi switch can't protect against ports not on it, and >>> in the second case it has no need to - the other savi switch will do >>> that. >>> >>> If an attacker uses SLAAC, when it sends out the DAD probe, the user >>> of the address will reply. If a savi switch sees an address being used >>> with the wrong MAC (across a neighboring switch, savi or otherwise), >>> it can reply with a DAD reponse, and the switch can install a filter >>> to make that address go away. That, or we develop a protocol to do the >>> same thing, but only if someone can explain why DAD is insufficient. >>> >>> Consider this. If I have a cheap five port 10/100/1000 switch attached >>> to a network containing several cat 6Ks, the BDP model requires the >>> cheap switch to have enough memory to store the entire savi table for >>> the entire swithed domain. "Cheap" goes straight down the toilet if we >>> do that, and as a result so will the standard. >>> >>> >>> >> >> > > > From junbi@tsinghua.edu.cn Tue Apr 14 23:37:56 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6400D3A6B97 for ; Tue, 14 Apr 2009 23:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK89nWkZ+5cg for ; Tue, 14 Apr 2009 23:37:55 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id 444763A697F for ; Tue, 14 Apr 2009 23:37:55 -0700 (PDT) Received: from th024184.ip.tsinghua.edu.cn ([59.66.24.184] helo=userPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Ltylm-0005Fl-5R; Wed, 15 Apr 2009 14:38:50 +0800 Message-ID: <184792FD00A5456AA08764D41B0F5355@userPC> From: "Jun Bi" To: "Fred Baker" References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> <4D15419B07B64EADAB02FDB506338123@userPC> <98FDC3D5-235C-4564-9E1E-99D4CA9B94F7@cisco.com> <9D3EC51661564E449E1DEF012F6CAE3E@userPC> In-Reply-To: Date: Wed, 15 Apr 2009 14:38:29 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jun Bi List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 06:37:56 -0000 How about we configure VLANs to divide hosts directly attached to SAVI switches and hosts under legacy switches. Then we may greatly simplify the problem and it's still acceptable some operators viewpoint (configuring, not changing the existing topology). thanks, Jun ----- Original Message ----- From: "Fred Baker" To: "Jun Bi" Cc: "Dave Thaler" ; "Christian Vogt" ; "SAVI Mailing List" Sent: Tuesday, April 14, 2009 11:08 PM Subject: Re: [savi] Your Vote: Incremental SAVI Deployment >I think you are saying that a network is protected from spoofing by a >given host if and only if the switch that host is attached to is >protecting the network - eg, is a savi switch. That makes sense to me. > > On Apr 14, 2009, at 8:02 AM, Jun Bi wrote: > >> Thank Fred's analysis. >> >> The words for voting is a little bit confusing. >> To accurately express my option, I want to express in the following way: >> >> "Under the arbitrary interconnections of SAVI devices and legacy >> switches, >> SAVI device must LINK-WIDELY CORRECTLY anti-spoof for hosts directly >> attached to it". >> >> For example, we have SAVI devices S1 and S2, and legacy device L1 and >> L2. >> S1 directly connects hosts A1, A2 >> S2 directly connects hosts B1, B2 >> L1 directly connects hosts C1, C2 >> >> Given ANY topology of S1, S2, L2 (arbitrary interconnections), the >> requirements to solutions are: >> (1) if source address of A1 is legally assigned, then if any of A2, B1 >> or B2 >> uses A1' source address, then the packets would be dropped by S1 or S2, >> but >> C1,C2 MAY still send packets with A1's source address. >> (2) if source address of B1 is legally assigned, then any of A1, A2, B2 >> could not spoof B1's source address. C1 and C2 MAY still spoof. >> (3) if source address of C1 is legally assigned, then any of A1, A2, B1, >> B2, >> could not spoof C1's source address, but C2 MAY still spoof. >> >> Again, I don't mean we need a BDP to achieve this goal, the goal could >> be achieved by >> snooping and using the existing control protocols. >> >> thanks, >> Jun Bi >> >> >> >> >> >> ----- Original Message ----- From: "Fred Baker" >> To: "Dave Thaler" >> Cc: "Jun Bi" ; "Christian Vogt" >> ; "SAVI Mailing List" >> Sent: Tuesday, April 14, 2009 1:49 PM >> Subject: Re: [savi] Your Vote: Incremental SAVI Deployment >> >> >>>> (1) Yes, arbitrary interconnections of SAVI devices and legacy >>>> switches should be supported. >>>> >>>> (2) No, it is fine for SAVI to restrict how SAVI devices and legacy >>>> switches are interconnected. >>> >>> From my perspective, you can hook savi switches together any way you >>> like, but the effects of some configurations may differ from others. >>> SAVI switches are intelligent. They are not magical. >>> >>> The real question here relates to the address distribution protocol >>> that Christian is pushing. >>> >>> I think the SAVI switch is securing the things it serves; it is not >>> securing the entire switching domain. >>> >>> If a savi switch is attached to a non-savi switch, the non-savi switch >>> will not participate in the protocol. The savi switch could determine >>> by observation (snooping or fcfs) what addresses come from it, but it >>> won't know how many ports there are, so it will have limited >>> capabilities at best. If the same savi switch is attached to another >>> savi switch, that savi switch will secure its own ports. So in the >>> first case, the savi switch can't protect against ports not on it, and >>> in the second case it has no need to - the other savi switch will do >>> that. >>> >>> If an attacker uses SLAAC, when it sends out the DAD probe, the user >>> of the address will reply. If a savi switch sees an address being used >>> with the wrong MAC (across a neighboring switch, savi or otherwise), >>> it can reply with a DAD reponse, and the switch can install a filter >>> to make that address go away. That, or we develop a protocol to do the >>> same thing, but only if someone can explain why DAD is insufficient. >>> >>> Consider this. If I have a cheap five port 10/100/1000 switch attached >>> to a network containing several cat 6Ks, the BDP model requires the >>> cheap switch to have enough memory to store the entire savi table for >>> the entire swithed domain. "Cheap" goes straight down the toilet if we >>> do that, and as a result so will the standard. >>> >>> >>> >> >> > > > From fred@cisco.com Wed Apr 15 03:33:46 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EFE23A6B60 for ; Wed, 15 Apr 2009 03:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.476 X-Spam-Level: X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8P2AwYOBccs for ; Wed, 15 Apr 2009 03:33:45 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9D32F3A6AC3 for ; Wed, 15 Apr 2009 03:33:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="153421214" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2009 10:34:58 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3FAYvXC005812; Wed, 15 Apr 2009 03:34:57 -0700 Received: from [172.16.1.3] (sjc-vpn3-1048.cisco.com [10.21.68.24]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3FAYu1J003156; Wed, 15 Apr 2009 10:34:57 GMT From: Fred Baker To: "Jun Bi" In-Reply-To: <184792FD00A5456AA08764D41B0F5355@userPC> X-Priority: 3 References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> <4D15419B07B64EADAB02FDB506338123@userPC> <98FDC3D5-235C-4564-9E1E-99D4CA9B94F7@cisco.com> <9D3EC51661564E449E1DEF012F6CAE3E@userPC> <184792FD00A5456AA08764D41B0F5355@userPC> Message-Id: <9077D5EB-AD30-49D3-AEBA-71C7533DC598@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 06:34:56 -0400 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=504; t=1239791698; x=1240655698; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20Your=20Vote=3A=20Incremental=2 0SAVI=20Deployment |Sender:=20; bh=R96dOAOmTV/RgU6E3oZNxrFmih9OImliGk5QxmCrBdc=; b=rcN2gy0F+FXuE0Jzg8CXte7iSsyQchMUpH5etfml36PSFDhulTfFiUZ+DM H1eV4IY+xY7IiZ2j0TT5G/Jtg42k31dIWjmQAHz03f0qfaSi3nxaKxYMAvL2 zhEv3sIdsL; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 10:33:46 -0000 On Apr 15, 2009, at 2:38 AM, Jun Bi wrote: > How about we configure VLANs to divide hosts directly attached to > SAVI switches and hosts under legacy switches. Then we may greatly > simplify the problem and it's still acceptable some operators > viewpoint (configuring, not changing the existing topology). That is certainly a recommendation we could include. That said, in my experience people use VLANs for reasons related to their organizations, not related to their switches. From marcelo@it.uc3m.es Wed Apr 15 06:02:48 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552013A6A8B for ; Wed, 15 Apr 2009 06:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tIo8cnrNN43 for ; Wed, 15 Apr 2009 06:02:47 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 2EBA73A6AF5 for ; Wed, 15 Apr 2009 06:02:46 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (234.pool85-53-146.dynamic.orange.es [85.53.146.234]) by smtp02.uc3m.es (Postfix) with ESMTP id 4624F6BA874; Wed, 15 Apr 2009 15:03:57 +0200 (CEST) Message-ID: <49E5DB3C.5020806@it.uc3m.es> Date: Wed, 15 Apr 2009 15:03:56 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: SAVI Mailing List , Suresh Krishnan , Greg Daley Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16582.007 Subject: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 13:02:48 -0000 About why DAD does not work as a SAVI binding distribution protocol. Several people (including myself) have considered using the DAD procedure to distribute SAVI binding information across all the SAVI devices within a link (or broadcast domain). In the last meeting, a couple of people (Greg and Suresh to be precise) explained why this was not possible. I include their argument below, as they explained it to me, since it is relevant for our discussions. Consider the following scenario: +--+ +--+ +--+ +--+ +--+ |HA| |HB| |HC| |HD| |HE| +--+ +--+ +--+ +--+ +--+ | | | | | | +-------------+ +------------+ +----| SWITCHA |---| SWITCHB | +-------------+ +------------+ Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has IPB and so on) Suppose for this example that the lower 24 bits of all the hosts are different (what is actually required is that there is no pair of nodes H1 and H2 located in different switches that have the same lower 24 bits, but anyway) Let's see how does this simple system works in IPv6. Suppose all hosts are using stateless autconfiguration. So, whenever a host HX gets configures its address, it performs the procedure described in RFC4862. This procedure, essentially implies to generate the tentative link local address, join the solicited-node multicast address for that address, send a NSOL for that address to the solicted-node multicast group for that address and wait and see. If nobody replies, it configures the link local address. Using the prefix information available in the RADV, it can then generate the global addresses. So, note that according to RFC2462, stateless address Autoconfiguration is performed only on multicast-capable links. So, suppose that all nodes have configured theu address except for node HA. Node HA performs the DAD procedure to configure its address, the question is who will receive the NSOL that it is issuing? By the assumption we made before, that all the hosts had different lower 24 bits in their addresses, there is no other node that has joined the solicited node multicast group for the candidate address of HA. In particular, no hosts connected to SWITCHB has joined the group. This means that SWITCHA will _not_ forward the NSOL message of HA's DAD procedure to SWITCHB. The implication for SAVI is that the DAD procedure cannot be trusted as a way to distribute binding information accross the SAVI devices connected to the same broadcast domain. Now, this is a problem since we cannot rely on this to distribute the SAVI information. However, it is actually a good thing, in the sense that we can control much more the size of the binding tables in the SAVI devices since we can design much more efficient SAVI verification protocols (pull type of protocols). From marcelo@it.uc3m.es Wed Apr 15 06:57:35 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E5C73A6A67 for ; Wed, 15 Apr 2009 06:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-3.673, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLE+N3l9+SKH for ; Wed, 15 Apr 2009 06:57:34 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 674FC3A6864 for ; Wed, 15 Apr 2009 06:57:34 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (234.pool85-53-146.dynamic.orange.es [85.53.146.234]) by smtp02.uc3m.es (Postfix) with ESMTP id 1FDB16BA8DA; Wed, 15 Apr 2009 15:58:44 +0200 (CEST) Message-ID: <49E5E813.30204@it.uc3m.es> Date: Wed, 15 Apr 2009 15:58:43 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <49E5DB3C.5020806@it.uc3m.es> <004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn> In-Reply-To: <004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16582.007 Cc: 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] =?gb2312?b?tPC4tDogIERBRCBhcyBhIGJpbmRpbmcgZGlzdHJpYnV0?= =?gb2312?b?aW9uIHByb3RvY29sOiB3aHkgbm90?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 13:57:35 -0000 the point being made is that SWITCHB in the figure below, will not receive the NSOL msg, so it won't be able to learn the binding between the src address and the L2 anchor, so if we want SWITCHB to actually defend that binding, we will need to make SWITCHB learn it though another mean Regards, marcelo Guang Yao escribió: > I think you have forgotten a very important thing: > if there is no collision, there is no need to deliver the NSOL to all the > nodes. > > In another word, the NSOL must be delivered to the collision node, no matter > other nodes receive it or not. > > In your scenario, no node pair has collision address, why should the NSOL be > delivered to all of them? > > -----邮件原件----- > 发件人: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] 代表 marcelo > bagnulo braun > 发送时间: 2009年4月15日 21:04 > 收件人: SAVI Mailing List; Suresh Krishnan; Greg Daley > 主题: [savi] DAD as a binding distribution protocol: why not > > About why DAD does not work as a SAVI binding distribution protocol. > > Several people (including myself) have considered using the DAD > procedure to distribute SAVI binding information across all the SAVI > devices within a link (or broadcast domain). > > In the last meeting, a couple of people (Greg and Suresh to be precise) > explained why this was not possible. I include their argument below, > as they explained it to me, since it is relevant for our discussions. > > Consider the following scenario: > > > > > +--+ +--+ +--+ +--+ +--+ > |HA| |HB| |HC| |HD| |HE| > +--+ +--+ +--+ +--+ +--+ > | | | | | > | +-------------+ +------------+ > +----| SWITCHA |---| SWITCHB | > +-------------+ +------------+ > > Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has IPB > and so on) > > Suppose for this example that the lower 24 bits of all the hosts are > different (what is actually required is that there is no pair of nodes > H1 and H2 located in different switches that have the same lower 24 > bits, but anyway) > > Let's see how does this simple system works in IPv6. > > Suppose all hosts are using stateless autconfiguration. > > So, whenever a host HX gets configures its address, it performs the > procedure described in RFC4862. This procedure, essentially implies to > generate the tentative link local address, join the solicited-node > multicast address for that address, send a NSOL for that address to the > solicted-node multicast group for that address and wait and see. If > nobody replies, it configures the link local address. Using the prefix > information available in the RADV, it can then generate the global > addresses. > > So, note that according to RFC2462, stateless address Autoconfiguration > is performed only on multicast-capable links. > So, suppose that all nodes have configured theu address except for node > HA. > Node HA performs the DAD procedure to configure its address, the > question is who will receive the NSOL that it is issuing? > > By the assumption we made before, that all the hosts had different lower > 24 bits in their addresses, there is no other node that has joined the > solicited node multicast group for the candidate address of HA. In > particular, no hosts connected to SWITCHB has joined the group. > > This means that SWITCHA will _not_ forward the NSOL message of HA's DAD > procedure to SWITCHB. > > The implication for SAVI is that the DAD procedure cannot be trusted as > a way to distribute binding information accross the SAVI devices > connected to the same broadcast domain. > > Now, this is a problem since we cannot rely on this to distribute the > SAVI information. However, it is actually a good thing, in the sense > that we can control much more the size of the binding tables in the SAVI > devices since we can design much more efficient SAVI verification > protocols (pull type of protocols). > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > > From fred@cisco.com Wed Apr 15 07:08:50 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53B028C1D9 for ; Wed, 15 Apr 2009 07:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDZOKwii+g8L for ; Wed, 15 Apr 2009 07:08:49 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id EDC4828C213 for ; Wed, 15 Apr 2009 07:08:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="41894996" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Apr 2009 14:09:42 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FE9gwL024151; Wed, 15 Apr 2009 10:09:42 -0400 Received: from dhcp-64-100-227-211.cisco.com (dhcp-64-100-227-211.cisco.com [64.100.227.211]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3FE9gNY014218; Wed, 15 Apr 2009 14:09:42 GMT Message-Id: From: Fred Baker To: marcelo bagnulo braun In-Reply-To: <49E5DB3C.5020806@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 10:09:41 -0400 References: <49E5DB3C.5020806@it.uc3m.es> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3472; t=1239804582; x=1240668582; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20DAD=20as=20a=20binding=20distr ibution=20protocol=3A=20why=20not |Sender:=20 |To:=20marcelo=20bagnulo=20braun=20; bh=0D4eKYaUOCu3TLcxpwo2ayfYsJBiXpVU/Sb78TNPoLo=; b=PXjwQ3MbaxBtBCiLZsuh60MTokA/NoeB2zsI3xI7yG0ow2OHRSr0SF/wt4 Td1sLMDQ9I+OnsiyiTHAAHDAXSvhglQafcHEyXG17GhCqa9PCMBra/OuC07n 5UHAJNR6SU; Authentication-Results: rtp-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SAVI Mailing List , Suresh Krishnan , Greg Daley Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:08:50 -0000 Have you considered my comments on why a Binding Distribution Protocol is a bad idea? Or are you arguing the next step - what protocol to use to implement the bad idea? On Apr 15, 2009, at 9:03 AM, marcelo bagnulo braun wrote: > About why DAD does not work as a SAVI binding distribution protocol. > > Several people (including myself) have considered using the DAD > procedure to distribute SAVI binding information across all the SAVI > devices within a link (or broadcast domain). > > In the last meeting, a couple of people (Greg and Suresh to be > precise) > explained why this was not possible. I include their argument below, > as they explained it to me, since it is relevant for our discussions. > > Consider the following scenario: > > > > > +--+ +--+ +--+ +--+ +--+ > |HA| |HB| |HC| |HD| |HE| > +--+ +--+ +--+ +--+ +--+ > | | | | | > | +-------------+ +------------+ > +----| SWITCHA |---| SWITCHB | > +-------------+ +------------+ > > Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has > IPB > and so on) > > Suppose for this example that the lower 24 bits of all the hosts are > different (what is actually required is that there is no pair of nodes > H1 and H2 located in different switches that have the same lower 24 > bits, but anyway) > > Let's see how does this simple system works in IPv6. > > Suppose all hosts are using stateless autconfiguration. > > So, whenever a host HX gets configures its address, it performs the > procedure described in RFC4862. This procedure, essentially implies to > generate the tentative link local address, join the solicited-node > multicast address for that address, send a NSOL for that address to > the > solicted-node multicast group for that address and wait and see. If > nobody replies, it configures the link local address. Using the prefix > information available in the RADV, it can then generate the global > addresses. > > So, note that according to RFC2462, stateless address > Autoconfiguration > is performed only on multicast-capable links. > So, suppose that all nodes have configured theu address except for > node > HA. > Node HA performs the DAD procedure to configure its address, the > question is who will receive the NSOL that it is issuing? > > By the assumption we made before, that all the hosts had different > lower > 24 bits in their addresses, there is no other node that has joined the > solicited node multicast group for the candidate address of HA. In > particular, no hosts connected to SWITCHB has joined the group. > > This means that SWITCHA will _not_ forward the NSOL message of HA's > DAD > procedure to SWITCHB. > > The implication for SAVI is that the DAD procedure cannot be trusted > as > a way to distribute binding information accross the SAVI devices > connected to the same broadcast domain. > > Now, this is a problem since we cannot rely on this to distribute the > SAVI information. However, it is actually a good thing, in the sense > that we can control much more the size of the binding tables in the > SAVI > devices since we can design much more efficient SAVI verification > protocols (pull type of protocols). > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From gdaley@netstarnetworks.com Wed Apr 15 07:19:27 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C841528C203 for ; Wed, 15 Apr 2009 07:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRZei2l7D+We for ; Wed, 15 Apr 2009 07:19:27 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id A7D8728C1FF for ; Wed, 15 Apr 2009 07:19:26 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n3FEKcRs031929; Thu, 16 Apr 2009 00:20:39 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 00:20:23 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 00:20:21 +1000 Message-ID: <6983BF97BFC24D4EA551F14071232918FD82C6@melmail.netstarnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [savi] DAD as a binding distribution protocol: why not Thread-Index: Acm909VXcobbDm9fSLidCy2KZurlOgAAOFHQ References: <49E5DB3C.5020806@it.uc3m.es> From: "Greg Daley" To: "Fred Baker" , "marcelo bagnulo braun" X-OriginalArrivalTime: 15 Apr 2009 14:20:23.0073 (UTC) FILETIME=[505D1110:01C9BDD5] Cc: SAVI Mailing List , Suresh Krishnan Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:19:27 -0000 Regardless of whether a binding distribution protocol is worthwhile, DAD isn't it.=20 Greg Daley -----Original Message----- From: Fred Baker [mailto:fred@cisco.com]=20 Sent: Thursday, 16 April 2009 12:10 AM To: marcelo bagnulo braun Cc: SAVI Mailing List; Suresh Krishnan; Greg Daley Subject: Re: [savi] DAD as a binding distribution protocol: why not Have you considered my comments on why a Binding Distribution Protocol is a bad idea? Or are you arguing the next step - what protocol to use to implement the bad idea? On Apr 15, 2009, at 9:03 AM, marcelo bagnulo braun wrote: > About why DAD does not work as a SAVI binding distribution protocol. > > Several people (including myself) have considered using the DAD=20 > procedure to distribute SAVI binding information across all the SAVI=20 > devices within a link (or broadcast domain). > > In the last meeting, a couple of people (Greg and Suresh to be > precise) > explained why this was not possible. I include their argument below,=20 > as they explained it to me, since it is relevant for our discussions. > > Consider the following scenario: > > > > > +--+ +--+ +--+ +--+ +--+ > |HA| |HB| |HC| |HD| |HE| > +--+ +--+ +--+ +--+ +--+ > | | | | | > | +-------------+ +------------+ > +----| SWITCHA |---| SWITCHB | > +-------------+ +------------+ > > Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has=20 > IPB and so on) > > Suppose for this example that the lower 24 bits of all the hosts are=20 > different (what is actually required is that there is no pair of nodes > H1 and H2 located in different switches that have the same lower 24=20 > bits, but anyway) > > Let's see how does this simple system works in IPv6. > > Suppose all hosts are using stateless autconfiguration. > > So, whenever a host HX gets configures its address, it performs the=20 > procedure described in RFC4862. This procedure, essentially implies to > generate the tentative link local address, join the solicited-node=20 > multicast address for that address, send a NSOL for that address to=20 > the solicted-node multicast group for that address and wait and see.=20 > If nobody replies, it configures the link local address. Using the=20 > prefix information available in the RADV, it can then generate the=20 > global addresses. > > So, note that according to RFC2462, stateless address =20 > Autoconfiguration > is performed only on multicast-capable links. > So, suppose that all nodes have configured theu address except for=20 > node HA. > Node HA performs the DAD procedure to configure its address, the=20 > question is who will receive the NSOL that it is issuing? > > By the assumption we made before, that all the hosts had different=20 > lower > 24 bits in their addresses, there is no other node that has joined the > solicited node multicast group for the candidate address of HA. In=20 > particular, no hosts connected to SWITCHB has joined the group. > > This means that SWITCHA will _not_ forward the NSOL message of HA's=20 > DAD procedure to SWITCHB. > > The implication for SAVI is that the DAD procedure cannot be trusted=20 > as a way to distribute binding information accross the SAVI devices=20 > connected to the same broadcast domain. > > Now, this is a problem since we cannot rely on this to distribute the=20 > SAVI information. However, it is actually a good thing, in the sense=20 > that we can control much more the size of the binding tables in the=20 > SAVI devices since we can design much more efficient SAVI verification > protocols (pull type of protocols). > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From marcelo@it.uc3m.es Wed Apr 15 07:27:17 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69FD13A6979 for ; Wed, 15 Apr 2009 07:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zM7UGcvbCTE for ; Wed, 15 Apr 2009 07:27:16 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 21BF13A694A for ; Wed, 15 Apr 2009 07:27:15 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (234.pool85-53-146.dynamic.orange.es [85.53.146.234]) by smtp02.uc3m.es (Postfix) with ESMTP id 74A796C144B; Wed, 15 Apr 2009 16:28:25 +0200 (CEST) Message-ID: <49E5EF09.5060908@it.uc3m.es> Date: Wed, 15 Apr 2009 16:28:25 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Fred Baker References: <49E5DB3C.5020806@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16582.007 Cc: SAVI Mailing List , Suresh Krishnan , Greg Daley Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:27:17 -0000 Fred, My understanding is the following: In the last meeting, there was rough consensus on the requirements that the protection domain of a SAVI solution should cover a whole link In oher words, suppose we have the following topology +--+ +--+ +--+ +--+ +--+ |HA| |HB| |HC| |HD| |HE| +--+ +--+ +--+ +--+ +--+ | | | | | | +-------------+ +------------+ +----| SWITCHA |---| SWITCHB | +-------------+ +------------+ suppose both SWITCHA and SWITCHB are SAVI devices Now, a SAVI solution sould not only protect that HB and HC don't spoof HA address but also must prevent HD and HE to spoof HA source address Do you agree on that or do you think it is ok to have a savi solution that only prevents HB and HC from spoofing HA address, but does not prevents HD nor HE to spoof HA address? Now, if we want this extended protection domain, we need to coordinate between the SAVI devices that are in the same link What i understood you stated in the last meeting is that having all savi devices storing all bindings for a whole link would render the solution economically non viable that restriction makes perfect sense to me I think it is possible to actually have the extended domain and not have all savi devices have all the bindings. Instead of using a push approach we can use a pull approach I think this is perfectly feasible. would that make sense to you? Moreover, i think that whatever SAVI protocol we define, if we do so, shpould be optional. I mean, depending on the topology and the level of protection desired, it is perfectly possible that this is achieved without the SAVI protocol. So, i think that the SAVI protocol should be a separate component of the solution About what i brought the description why DAD cannot be used, i thought it was worth describing this in detail cause i felt there was some people confused about the possibility of using DAD for this (in particular, i was confused since i thought is was possible to use it) so i thought it was worth clarifying it. Sorry if this caused more confusion. regards, marcelo Fred Baker escribi: > Have you considered my comments on why a Binding Distribution Protocol > is a bad idea? Or are you arguing the next step - what protocol to use > to implement the bad idea? > > On Apr 15, 2009, at 9:03 AM, marcelo bagnulo braun wrote: > >> About why DAD does not work as a SAVI binding distribution protocol. >> >> Several people (including myself) have considered using the DAD >> procedure to distribute SAVI binding information across all the SAVI >> devices within a link (or broadcast domain). >> >> In the last meeting, a couple of people (Greg and Suresh to be precise) >> explained why this was not possible. I include their argument below, >> as they explained it to me, since it is relevant for our discussions. >> >> Consider the following scenario: >> >> >> >> >> +--+ +--+ +--+ +--+ +--+ >> |HA| |HB| |HC| |HD| |HE| >> +--+ +--+ +--+ +--+ +--+ >> | | | | | >> | +-------------+ +------------+ >> +----| SWITCHA |---| SWITCHB | >> +-------------+ +------------+ >> >> Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has IPB >> and so on) >> >> Suppose for this example that the lower 24 bits of all the hosts are >> different (what is actually required is that there is no pair of nodes >> H1 and H2 located in different switches that have the same lower 24 >> bits, but anyway) >> >> Let's see how does this simple system works in IPv6. >> >> Suppose all hosts are using stateless autconfiguration. >> >> So, whenever a host HX gets configures its address, it performs the >> procedure described in RFC4862. This procedure, essentially implies to >> generate the tentative link local address, join the solicited-node >> multicast address for that address, send a NSOL for that address to the >> solicted-node multicast group for that address and wait and see. If >> nobody replies, it configures the link local address. Using the prefix >> information available in the RADV, it can then generate the global >> addresses. >> >> So, note that according to RFC2462, stateless address Autoconfiguration >> is performed only on multicast-capable links. >> So, suppose that all nodes have configured theu address except for node >> HA. >> Node HA performs the DAD procedure to configure its address, the >> question is who will receive the NSOL that it is issuing? >> >> By the assumption we made before, that all the hosts had different lower >> 24 bits in their addresses, there is no other node that has joined the >> solicited node multicast group for the candidate address of HA. In >> particular, no hosts connected to SWITCHB has joined the group. >> >> This means that SWITCHA will _not_ forward the NSOL message of HA's DAD >> procedure to SWITCHB. >> >> The implication for SAVI is that the DAD procedure cannot be trusted as >> a way to distribute binding information accross the SAVI devices >> connected to the same broadcast domain. >> >> Now, this is a problem since we cannot rely on this to distribute the >> SAVI information. However, it is actually a good thing, in the sense >> that we can control much more the size of the binding tables in the SAVI >> devices since we can design much more efficient SAVI verification >> protocols (pull type of protocols). >> >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > From marcelo@it.uc3m.es Wed Apr 15 08:02:59 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211923A6E92 for ; Wed, 15 Apr 2009 08:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=-3.648, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxGAwAxGh4VJ for ; Wed, 15 Apr 2009 08:02:58 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id B8D733A6EB4 for ; Wed, 15 Apr 2009 08:02:57 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (234.pool85-53-146.dynamic.orange.es [85.53.146.234]) by smtp03.uc3m.es (Postfix) with ESMTP id EF52572C28A; Wed, 15 Apr 2009 17:04:07 +0200 (CEST) Message-ID: <49E5F768.1050307@it.uc3m.es> Date: Wed, 15 Apr 2009 17:04:08 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <49E5DB3C.5020806@it.uc3m.es> <004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn> <49E5E813.30204@it.uc3m.es> <000301c9bdd6$b3c0ae50$1b420af0$@tsinghua.edu.cn> In-Reply-To: <000301c9bdd6$b3c0ae50$1b420af0$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16584.000 Cc: 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] =?gb2312?b?tPC4tDogILTwuLQ6ICBEQUQgYXMgYSBiaW5kaW5nIGRp?= =?gb2312?b?c3RyaWJ1dGlvbiBwcm90b2NvbDogd2h5IG5vdA==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 15:02:59 -0000 Guang Yao escribió: > 1, If the anchor is port, there is no need for the SWITCHB to protect the > binding. Why doesn't SWITCHA protect it? > In the figure below, HE can sppof HA addresses when talking to devices tha are not conencted to SWITCHA (e.g. when talking to HD) in order to protect this we need SWITCHB to be involved this applies both when we use MAC addresses and ports as lower layer anchors Regards, marcelo > SWITCHB has little capability to protect the hosts far from it. I think SAVI > device should only protect the host directly attached. This is a strong > security. > If we design a BDP just to enable it has the ability to perform a > "ingress-filtering"-like check, it is not worthwhile. And there is no > incentive for the deployer. > > 2, If the anchor is MAC, currently there is no secure MAC that can step > across switch. 802.1ae/af can only work on directly attached switch. > > Regards, Guang > > -----邮件原件----- > 发件人: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] 代表 marcelo > bagnulo braun > 发送时间: 2009年4月15日 21:59 > 收件人: Guang Yao > 抄送: 'SAVI Mailing List'; 'Suresh Krishnan'; 'Greg Daley' > 主题: Re: [savi] 答复: DAD as a binding distribution protocol: why not > > the point being made is that SWITCHB in the figure below, will not > receive the NSOL msg, so it won't be able to learn the binding between > the src address and the L2 anchor, so if we want SWITCHB to actually > defend that binding, we will need to make SWITCHB learn it though > another mean > > Regards, marcelo > > > Guang Yao escribió: > >> I think you have forgotten a very important thing: >> if there is no collision, there is no need to deliver the NSOL to all the >> nodes. >> >> In another word, the NSOL must be delivered to the collision node, no >> > matter > >> other nodes receive it or not. >> >> In your scenario, no node pair has collision address, why should the NSOL >> > be > >> delivered to all of them? >> >> -----邮件原件----- >> 发件人: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] 代表 marcelo >> bagnulo braun >> 发送时间: 2009年4月15日 21:04 >> 收件人: SAVI Mailing List; Suresh Krishnan; Greg Daley >> 主题: [savi] DAD as a binding distribution protocol: why not >> >> About why DAD does not work as a SAVI binding distribution protocol. >> >> Several people (including myself) have considered using the DAD >> procedure to distribute SAVI binding information across all the SAVI >> devices within a link (or broadcast domain). >> >> In the last meeting, a couple of people (Greg and Suresh to be precise) >> explained why this was not possible. I include their argument below, >> as they explained it to me, since it is relevant for our discussions. >> >> Consider the following scenario: >> >> >> >> >> +--+ +--+ +--+ +--+ +--+ >> |HA| |HB| |HC| |HD| |HE| >> +--+ +--+ +--+ +--+ +--+ >> | | | | | >> | +-------------+ +------------+ >> +----| SWITCHA |---| SWITCHB | >> +-------------+ +------------+ >> >> Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has IPB >> and so on) >> >> Suppose for this example that the lower 24 bits of all the hosts are >> different (what is actually required is that there is no pair of nodes >> H1 and H2 located in different switches that have the same lower 24 >> bits, but anyway) >> >> Let's see how does this simple system works in IPv6. >> >> Suppose all hosts are using stateless autconfiguration. >> >> So, whenever a host HX gets configures its address, it performs the >> procedure described in RFC4862. This procedure, essentially implies to >> generate the tentative link local address, join the solicited-node >> multicast address for that address, send a NSOL for that address to the >> solicted-node multicast group for that address and wait and see. If >> nobody replies, it configures the link local address. Using the prefix >> information available in the RADV, it can then generate the global >> addresses. >> >> So, note that according to RFC2462, stateless address Autoconfiguration >> is performed only on multicast-capable links. >> So, suppose that all nodes have configured theu address except for node >> HA. >> Node HA performs the DAD procedure to configure its address, the >> question is who will receive the NSOL that it is issuing? >> >> By the assumption we made before, that all the hosts had different lower >> 24 bits in their addresses, there is no other node that has joined the >> solicited node multicast group for the candidate address of HA. In >> particular, no hosts connected to SWITCHB has joined the group. >> >> This means that SWITCHA will _not_ forward the NSOL message of HA's DAD >> procedure to SWITCHB. >> >> The implication for SAVI is that the DAD procedure cannot be trusted as >> a way to distribute binding information accross the SAVI devices >> connected to the same broadcast domain. >> >> Now, this is a problem since we cannot rely on this to distribute the >> SAVI information. However, it is actually a good thing, in the sense >> that we can control much more the size of the binding tables in the SAVI >> devices since we can design much more efficient SAVI verification >> protocols (pull type of protocols). >> >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> >> >> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > > > From elevyabe@cisco.com Wed Apr 15 08:32:07 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AE593A6B53 for ; Wed, 15 Apr 2009 08:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTKGd3m67uHf for ; Wed, 15 Apr 2009 08:32:06 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A4B023A6AD2 for ; Wed, 15 Apr 2009 08:32:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,192,1238976000"; d="scan'208";a="38374013" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2009 15:33:16 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FFXGt6007692; Wed, 15 Apr 2009 17:33:16 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FFXG8t012049; Wed, 15 Apr 2009 15:33:16 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 17:33:16 +0200 Received: from [144.254.53.110] ([144.254.53.110]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 17:33:16 +0200 Message-ID: <49E5FE3B.9080607@cisco.com> Date: Wed, 15 Apr 2009 17:33:15 +0200 From: Eric Levy-Abegnoli User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: marcelo bagnulo braun References: <49E5DB3C.5020806@it.uc3m.es> In-Reply-To: <49E5DB3C.5020806@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Apr 2009 15:33:16.0537 (UTC) FILETIME=[7F26B690:01C9BDDF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4176; t=1239809596; x=1240673596; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20Re=3A=20[savi]=20DAD=20as=20a=20binding=20distr ibution=20protocol=3A=20why=20not |Sender:=20; bh=FiLWvK8Z1npvwqNMQjgvaGgtFxzH9acz0nnSz4Nswh8=; b=u7GGWziEDcGMPeVM3j3jrnC0lgGm8yf+RaUNPzrbR6zhogQw7ekh42qwMz hgif+75iigVX5kv9qdxbUg//AVJ/uzY62XcHweyVMaCaNk/QD3+mlX17h2v9 +ijrQ3yZM5; Authentication-Results: ams-dkim-1; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: SAVI Mailing List , Suresh Krishnan , Greg Daley Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 15:32:07 -0000 Marcelo, The function that would prevent SWITCHA to forward DAD packets to SWITCHB in this scenario is_not_dictated by RFC4862 or even RFC3810 (MLD). The switches are L2 devices and not expected to limit the multicast forwarding to L3-devices who have joined the group. In theory, DAD multicast should be forwarded to trunks, regardless of who joined. If switches perm MLD snooping, there could be a problem, however RFC4541 is very cautious with regard to switch deciding not_to copy traffic to a port where no join was seen. It looks to me that in this scenario, for switches doing mld snooping, it would not be un-reasonnable to have a configuration option on SWITCHA to enable copy of multicast traffic on its trunks regardless of snooped groups. SWITCHB could still decide not to deliver the traffic to any device if nobody joined the group. That would enable DAD to be usable as a binding distribution protocol. Eric marcelo bagnulo braun a 閏rit : > About why DAD does not work as a SAVI binding distribution protocol. > > Several people (including myself) have considered using the DAD > procedure to distribute SAVI binding information across all the SAVI > devices within a link (or broadcast domain). > > In the last meeting, a couple of people (Greg and Suresh to be precise) > explained why this was not possible. I include their argument below, > as they explained it to me, since it is relevant for our discussions. > > Consider the following scenario: > > > > > +--+ +--+ +--+ +--+ +--+ > |HA| |HB| |HC| |HD| |HE| > +--+ +--+ +--+ +--+ +--+ > | | | | | > | +-------------+ +------------+ > +----| SWITCHA |---| SWITCHB | > +-------------+ +------------+ > > Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has IPB > and so on) > > Suppose for this example that the lower 24 bits of all the hosts are > different (what is actually required is that there is no pair of nodes > H1 and H2 located in different switches that have the same lower 24 > bits, but anyway) > > Let's see how does this simple system works in IPv6. > > Suppose all hosts are using stateless autconfiguration. > > So, whenever a host HX gets configures its address, it performs the > procedure described in RFC4862. This procedure, essentially implies to > generate the tentative link local address, join the solicited-node > multicast address for that address, send a NSOL for that address to the > solicted-node multicast group for that address and wait and see. If > nobody replies, it configures the link local address. Using the prefix > information available in the RADV, it can then generate the global > addresses. > > So, note that according to RFC2462, stateless address Autoconfiguration > is performed only on multicast-capable links. > So, suppose that all nodes have configured theu address except for node > HA. > Node HA performs the DAD procedure to configure its address, the > question is who will receive the NSOL that it is issuing? > > By the assumption we made before, that all the hosts had different lower > 24 bits in their addresses, there is no other node that has joined the > solicited node multicast group for the candidate address of HA. In > particular, no hosts connected to SWITCHB has joined the group. > > This means that SWITCHA will _not_ forward the NSOL message of HA's DAD > procedure to SWITCHB. > > The implication for SAVI is that the DAD procedure cannot be trusted as > a way to distribute binding information accross the SAVI devices > connected to the same broadcast domain. > > Now, this is a problem since we cannot rely on this to distribute the > SAVI information. However, it is actually a good thing, in the sense > that we can control much more the size of the binding tables in the SAVI > devices since we can design much more efficient SAVI verification > protocols (pull type of protocols). > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@tsinghua.edu.cn Wed Apr 15 10:22:32 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D82A3A6BBE for ; Wed, 15 Apr 2009 10:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.153 X-Spam-Level: *** X-Spam-Status: No, score=3.153 tagged_above=-999 required=5 tests=[AWL=-3.978, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DNS_FROM_RFC_DSN=1.495, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04AHyx2oY19l for ; Wed, 15 Apr 2009 10:22:31 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id D60A23A6B43 for ; Wed, 15 Apr 2009 10:22:30 -0700 (PDT) Received: from th053130.ip.tsinghua.edu.cn ([59.66.53.130] helo=userPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Lu8pd-00017o-KU; Thu, 16 Apr 2009 01:23:29 +0800 Message-ID: <942B2D1A792F43DAAB3662B5E59FD727@userPC> From: "Jun Bi" To: "marcelo bagnulo braun" , "Guang Yao" References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn> <49E5E813.30204@it.uc3m.es> In-Reply-To: <49E5E813.30204@it.uc3m.es> Date: Thu, 16 Apr 2009 01:21:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] =?gb2312?b?tPC4tDogIERBRCBhcyBhIGJpbmRpbmcgZGlzdHJpYnV0?= =?gb2312?b?aW9uIHByb3RvY29sOiB3aHkgbm90?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jun Bi List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 17:22:32 -0000 Here I don't want to use the term BDP (do we really need a BDP to achieve the anti-spoof-ability ?), just see how we achieve the goals of anti-spoofing. I think when Christian visting Tsinghua today, we discussed the samilar question. If the solution is SAVI-CPS, then we didn't see any porblem to anti-spoof. (I don't want to say that SAVI-CPS uses DAD as a BDP, because in SAVI-CPS, no new protocol is designed, just snooping the existing control protocol). If the solution is SAVI-FCFS, then it will be a problem without BDP. IF the binding table is set up by SAVI-CPS, even if switch B dones't konw the binding table of switchA, HD, HE still could not spoof the source address of HA,HB,HC. The intial binding table of SwitchB is empty for HD and HE, the binding is set up based on the control protocol snooping. If HD is an attaker and tried to send packets use source address of HA, then BEFORE the binding, swtichB will will wait for the DAD-NS, then forward the DAD-NS to SwitchA (because the src addr of the DAD-NS wants used is within the same multicast group of HA. Then swtichB will see the confict (DAD-NA from HA), the drop HD's packets. (Please see the draft of SAVI-CPS). Considering the incrementatl depolyment, the operator could configure three types of ports for the SAVI swtich: SAVI-HOST (savi switch to savi host), SAVI-SAVI (savi switch to savi switch), SAVI-Legacy (savi switch to legacy switch). SAVI switch will trust packets from SAVI-SAVI port. SAVI switch will snoop control packets of SAVI-HOST port and setup the intial binding. thanks, Jun Bi ----- Original Message ----- From: "marcelo bagnulo braun" To: "Guang Yao" Cc: "'SAVI Mailing List'" ; "'Suresh Krishnan'" ; "'Greg Daley'" Sent: Wednesday, April 15, 2009 9:58 PM Subject: Re: [savi] 答复: DAD as a binding distribution protocol: why not > the point being made is that SWITCHB in the figure below, will not > receive the NSOL msg, so it won't be able to learn the binding between > the src address and the L2 anchor, so if we want SWITCHB to actually > defend that binding, we will need to make SWITCHB learn it though > another mean > > Regards, marcelo > > > Guang Yao escribió: >> I think you have forgotten a very important thing: >> if there is no collision, there is no need to deliver the NSOL to all the >> nodes. >> >> In another word, the NSOL must be delivered to the collision node, no >> matter >> other nodes receive it or not. >> >> In your scenario, no node pair has collision address, why should the NSOL >> be >> delivered to all of them? >> >> -----邮件原件----- >> 发件人: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] 代表 marcelo >> bagnulo braun >> 发送时间: 2009年4月15日 21:04 >> 收件人: SAVI Mailing List; Suresh Krishnan; Greg Daley >> 主题: [savi] DAD as a binding distribution protocol: why not >> >> About why DAD does not work as a SAVI binding distribution protocol. >> >> Several people (including myself) have considered using the DAD >> procedure to distribute SAVI binding information across all the SAVI >> devices within a link (or broadcast domain). >> >> In the last meeting, a couple of people (Greg and Suresh to be precise) >> explained why this was not possible. I include their argument below, >> as they explained it to me, since it is relevant for our discussions. >> >> Consider the following scenario: >> >> >> >> >> +--+ +--+ +--+ +--+ +--+ >> |HA| |HB| |HC| |HD| |HE| >> +--+ +--+ +--+ +--+ +--+ >> | | | | | >> | +-------------+ +------------+ >> +----| SWITCHA |---| SWITCHB | >> +-------------+ +------------+ >> >> Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has IPB >> and so on) >> >> Suppose for this example that the lower 24 bits of all the hosts are >> different (what is actually required is that there is no pair of nodes >> H1 and H2 located in different switches that have the same lower 24 >> bits, but anyway) >> >> Let's see how does this simple system works in IPv6. >> >> Suppose all hosts are using stateless autconfiguration. >> >> So, whenever a host HX gets configures its address, it performs the >> procedure described in RFC4862. This procedure, essentially implies to >> generate the tentative link local address, join the solicited-node >> multicast address for that address, send a NSOL for that address to the >> solicted-node multicast group for that address and wait and see. If >> nobody replies, it configures the link local address. Using the prefix >> information available in the RADV, it can then generate the global >> addresses. >> >> So, note that according to RFC2462, stateless address Autoconfiguration >> is performed only on multicast-capable links. >> So, suppose that all nodes have configured theu address except for node >> HA. >> Node HA performs the DAD procedure to configure its address, the >> question is who will receive the NSOL that it is issuing? >> >> By the assumption we made before, that all the hosts had different lower >> 24 bits in their addresses, there is no other node that has joined the >> solicited node multicast group for the candidate address of HA. In >> particular, no hosts connected to SWITCHB has joined the group. >> >> This means that SWITCHA will _not_ forward the NSOL message of HA's DAD >> procedure to SWITCHB. >> >> The implication for SAVI is that the DAD procedure cannot be trusted as >> a way to distribute binding information accross the SAVI devices >> connected to the same broadcast domain. >> >> Now, this is a problem since we cannot rely on this to distribute the >> SAVI information. However, it is actually a good thing, in the sense >> that we can control much more the size of the binding tables in the SAVI >> devices since we can design much more efficient SAVI verification >> protocols (pull type of protocols). >> >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> >> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@cernet.edu.cn Wed Apr 15 10:28:22 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 564FA3A6BC7 for ; Wed, 15 Apr 2009 10:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.304 X-Spam-Level: * X-Spam-Status: No, score=1.304 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvCIztdFbHRe for ; Wed, 15 Apr 2009 10:28:21 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id AEBF23A6C0E for ; Wed, 15 Apr 2009 10:28:20 -0700 (PDT) Received: from userPC([59.66.53.130]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm5649e61cfe; Thu, 16 Apr 2009 01:29:26 +0800 Message-ID: From: "Jun Bi" To: "Greg Daley" , "Fred Baker" , "marcelo bagnulo braun" References: <49E5DB3C.5020806@it.uc3m.es> <6983BF97BFC24D4EA551F14071232918FD82C6@melmail.netstarnetworks.com> In-Reply-To: <6983BF97BFC24D4EA551F14071232918FD82C6@melmail.netstarnetworks.com> Date: Thu, 16 Apr 2009 01:29:04 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: aEYvIuVB Cc: SAVI Mailing List , Suresh Krishnan Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 17:28:22 -0000 Exactly, DAD is not a BDP. A real BDP will be very complex, if we use SAVI-FCFS. The question is: if we use SAVI-CPS (please see the draft we sent to the mailing list and IETF) to setup the binding table, do we still need an additional complex BDP to distribute the binding table ? Currently, I see no need for a BDP. Maybe I am wrong, but we could discuss the potential issues and enhance the solution. thanks, Jun Bi ----- Original Message ----- From: "Greg Daley" To: "Fred Baker" ; "marcelo bagnulo braun" Cc: "SAVI Mailing List" ; "Suresh Krishnan" Sent: Wednesday, April 15, 2009 10:20 PM Subject: Re: [savi] DAD as a binding distribution protocol: why not > Regardless of whether a binding distribution protocol is worthwhile, DAD > isn't it. > > > Greg Daley > > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Thursday, 16 April 2009 12:10 AM > To: marcelo bagnulo braun > Cc: SAVI Mailing List; Suresh Krishnan; Greg Daley > Subject: Re: [savi] DAD as a binding distribution protocol: why not > > Have you considered my comments on why a Binding Distribution Protocol > is a bad idea? Or are you arguing the next step - what protocol to use > to implement the bad idea? > > On Apr 15, 2009, at 9:03 AM, marcelo bagnulo braun wrote: > >> About why DAD does not work as a SAVI binding distribution protocol. >> >> Several people (including myself) have considered using the DAD >> procedure to distribute SAVI binding information across all the SAVI >> devices within a link (or broadcast domain). >> >> In the last meeting, a couple of people (Greg and Suresh to be >> precise) >> explained why this was not possible. I include their argument below, >> as they explained it to me, since it is relevant for our discussions. >> >> Consider the following scenario: >> >> >> >> >> +--+ +--+ +--+ +--+ +--+ >> |HA| |HB| |HC| |HD| |HE| >> +--+ +--+ +--+ +--+ +--+ >> | | | | | >> | +-------------+ +------------+ >> +----| SWITCHA |---| SWITCHB | >> +-------------+ +------------+ >> >> Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has >> IPB and so on) >> >> Suppose for this example that the lower 24 bits of all the hosts are >> different (what is actually required is that there is no pair of nodes >> H1 and H2 located in different switches that have the same lower 24 >> bits, but anyway) >> >> Let's see how does this simple system works in IPv6. >> >> Suppose all hosts are using stateless autconfiguration. >> >> So, whenever a host HX gets configures its address, it performs the >> procedure described in RFC4862. This procedure, essentially implies to > >> generate the tentative link local address, join the solicited-node >> multicast address for that address, send a NSOL for that address to >> the solicted-node multicast group for that address and wait and see. >> If nobody replies, it configures the link local address. Using the >> prefix information available in the RADV, it can then generate the >> global addresses. >> >> So, note that according to RFC2462, stateless address >> Autoconfiguration >> is performed only on multicast-capable links. >> So, suppose that all nodes have configured theu address except for >> node HA. >> Node HA performs the DAD procedure to configure its address, the >> question is who will receive the NSOL that it is issuing? >> >> By the assumption we made before, that all the hosts had different >> lower >> 24 bits in their addresses, there is no other node that has joined the > >> solicited node multicast group for the candidate address of HA. In >> particular, no hosts connected to SWITCHB has joined the group. >> >> This means that SWITCHA will _not_ forward the NSOL message of HA's >> DAD procedure to SWITCHB. >> >> The implication for SAVI is that the DAD procedure cannot be trusted >> as a way to distribute binding information accross the SAVI devices >> connected to the same broadcast domain. >> >> Now, this is a problem since we cannot rely on this to distribute the >> SAVI information. However, it is actually a good thing, in the sense >> that we can control much more the size of the binding tables in the >> SAVI devices since we can design much more efficient SAVI verification > >> protocols (pull type of protocols). >> >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > > From marcelo@it.uc3m.es Wed Apr 15 10:38:16 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E0B23A6B7D for ; Wed, 15 Apr 2009 10:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-3.923, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGJA2derzxnJ for ; Wed, 15 Apr 2009 10:38:15 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id CAEC93A6A2C for ; Wed, 15 Apr 2009 10:38:14 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (234.pool85-53-146.dynamic.orange.es [85.53.146.234]) by smtp03.uc3m.es (Postfix) with ESMTP id EA1D07EF0E2; Wed, 15 Apr 2009 19:39:24 +0200 (CEST) Message-ID: <49E61BCC.70806@it.uc3m.es> Date: Wed, 15 Apr 2009 19:39:24 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jun Bi References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn> <49E5E813.30204@it.uc3m.es> <942B2D1A792F43DAAB3662B5E59FD727@userPC> In-Reply-To: <942B2D1A792F43DAAB3662B5E59FD727@userPC> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16584.000 Cc: Guang Yao , 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] =?gb2312?b?tPC4tDogIERBRCBhcyBhIGJpbmRpbmcgZGlzdHJpYnV0?= =?gb2312?b?aW9uIHByb3RvY29sOiB3aHkgbm90?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 17:38:16 -0000 Jun Bi escribió: > Here I don't want to use the term BDP (do we really need a BDP to > achieve the anti-spoof-ability ?), > just see how we achieve the goals of anti-spoofing. > > I think when Christian visting Tsinghua today, we discussed the > samilar question. > If the solution is SAVI-CPS, then we didn't see any porblem to > anti-spoof. (I don't want to say that SAVI-CPS uses DAD as a BDP, > because in SAVI-CPS, no new protocol is designed, just snooping the > existing control protocol). > If the solution is SAVI-FCFS, then it will be a problem without BDP. > > IF the binding table is set up by SAVI-CPS, even if switch B dones't > konw the binding table of switchA, HD, HE still could not spoof the > source address of HA,HB,HC. The intial binding table of SwitchB is > empty for HD and HE, the binding is set up based on the control > protocol snooping. If HD is an attaker and tried to send packets use > source address of HA, then BEFORE the binding, swtichB will will wait > for the DAD-NS, then forward the DAD-NS to SwitchA (because the src > addr of the DAD-NS wants used is within the same multicast group of > HA. Then swtichB will see the confict (DAD-NA from HA), the drop HD's > packets. (Please see the draft of SAVI-CPS). So, if i understand it correctly, the default action is in the SAVI CPS is to drop packets i.e. if the savi device has not seen a signalling packet before, it will drop the packet. I am not very comfortable with that approach. consider the following situations: - what happens if the switch is rebooted? I mean, suppose that you have a bunch or computers connected to a savi switch. They all have performed the DAD and the SAVI data base is populated. Now the switch is rebooted and the data base information is lost. what happens? AFAIU, the SAVI device will start dropping all the packets, right? - what happens if the DAD packet is lost? DAD is by definition an unreliable procedure, so it may happen. Moreover, since the DAD is the first packet an interface sends, whenever technology takes some time to move to up state, the first packet is the one with most probabilities to get lost. - are you planning to do some garbage collection? I mean, as Fred has been saying, we need to keep the tables small. So, at some point the SAVI device will need to perform some form of garbage collection, what happens when the entry of a host is deleted by the garbage collection process? the hsot will not perform the DAD process again, so what happens? (and i am not even considering the case where an attacker is creating savi entries in a bulk manner) So, imho, having a default behaviour of dropping packets seems like the wrong approach. The savi device must learn and be able to recover state when it is lost while still being able to tell if this is an attacker or not > > Considering the incrementatl depolyment, the operator could configure > three types of ports for the SAVI swtich: SAVI-HOST (savi switch to > savi host), SAVI-SAVI (savi switch to savi switch), SAVI-Legacy (savi > switch to legacy switch). SAVI switch will trust packets from > SAVI-SAVI port. SAVI switch will snoop control packets of SAVI-HOST > port and setup the intial binding. > sure, this sounds the reasonable thing to secure any SAVI protocol Regards, marcelo > thanks, > Jun Bi > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "Guang Yao" > Cc: "'SAVI Mailing List'" ; "'Suresh Krishnan'" > ; "'Greg Daley'" > > Sent: Wednesday, April 15, 2009 9:58 PM > Subject: Re: [savi] 答复: DAD as a binding distribution protocol: why not > > >> the point being made is that SWITCHB in the figure below, will not >> receive the NSOL msg, so it won't be able to learn the binding between >> the src address and the L2 anchor, so if we want SWITCHB to actually >> defend that binding, we will need to make SWITCHB learn it though >> another mean >> >> Regards, marcelo >> >> >> Guang Yao escribió: >>> I think you have forgotten a very important thing: >>> if there is no collision, there is no need to deliver the NSOL to >>> all the >>> nodes. >>> >>> In another word, the NSOL must be delivered to the collision node, >>> no matter >>> other nodes receive it or not. >>> >>> In your scenario, no node pair has collision address, why should the >>> NSOL be >>> delivered to all of them? >>> >>> -----邮件原件----- >>> 发件人: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] 代表 >>> marcelo >>> bagnulo braun >>> 发送时间: 2009年4月15日 21:04 >>> 收件人: SAVI Mailing List; Suresh Krishnan; Greg Daley >>> 主题: [savi] DAD as a binding distribution protocol: why not >>> >>> About why DAD does not work as a SAVI binding distribution protocol. >>> >>> Several people (including myself) have considered using the DAD >>> procedure to distribute SAVI binding information across all the SAVI >>> devices within a link (or broadcast domain). >>> >>> In the last meeting, a couple of people (Greg and Suresh to be precise) >>> explained why this was not possible. I include their argument below, >>> as they explained it to me, since it is relevant for our discussions. >>> >>> Consider the following scenario: >>> >>> >>> >>> >>> +--+ +--+ +--+ +--+ +--+ >>> |HA| |HB| |HC| |HD| |HE| >>> +--+ +--+ +--+ +--+ +--+ >>> | | | | | >>> | +-------------+ +------------+ >>> +----| SWITCHA |---| SWITCHB | >>> +-------------+ +------------+ >>> >>> Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has IPB >>> and so on) >>> >>> Suppose for this example that the lower 24 bits of all the hosts are >>> different (what is actually required is that there is no pair of nodes >>> H1 and H2 located in different switches that have the same lower 24 >>> bits, but anyway) >>> >>> Let's see how does this simple system works in IPv6. >>> >>> Suppose all hosts are using stateless autconfiguration. >>> >>> So, whenever a host HX gets configures its address, it performs the >>> procedure described in RFC4862. This procedure, essentially implies to >>> generate the tentative link local address, join the solicited-node >>> multicast address for that address, send a NSOL for that address to the >>> solicted-node multicast group for that address and wait and see. If >>> nobody replies, it configures the link local address. Using the prefix >>> information available in the RADV, it can then generate the global >>> addresses. >>> >>> So, note that according to RFC2462, stateless address Autoconfiguration >>> is performed only on multicast-capable links. >>> So, suppose that all nodes have configured theu address except for node >>> HA. >>> Node HA performs the DAD procedure to configure its address, the >>> question is who will receive the NSOL that it is issuing? >>> >>> By the assumption we made before, that all the hosts had different >>> lower >>> 24 bits in their addresses, there is no other node that has joined the >>> solicited node multicast group for the candidate address of HA. In >>> particular, no hosts connected to SWITCHB has joined the group. >>> >>> This means that SWITCHA will _not_ forward the NSOL message of HA's DAD >>> procedure to SWITCHB. >>> >>> The implication for SAVI is that the DAD procedure cannot be trusted as >>> a way to distribute binding information accross the SAVI devices >>> connected to the same broadcast domain. >>> >>> Now, this is a problem since we cannot rely on this to distribute the >>> SAVI information. However, it is actually a good thing, in the sense >>> that we can control much more the size of the binding tables in the >>> SAVI >>> devices since we can design much more efficient SAVI verification >>> protocols (pull type of protocols). >>> >>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >>> >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > > From junbi@cernet.edu.cn Wed Apr 15 10:58:52 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3EFA3A6B52 for ; Wed, 15 Apr 2009 10:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.202 X-Spam-Level: * X-Spam-Status: No, score=1.202 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QczjpTXRhdhm for ; Wed, 15 Apr 2009 10:58:52 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 57AE73A6C4D for ; Wed, 15 Apr 2009 10:58:51 -0700 (PDT) Received: from userPC([59.66.53.130]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm3c49e62423; Thu, 16 Apr 2009 01:59:56 +0800 Message-ID: From: "Jun Bi" To: "Eric Levy-Abegnoli" , "marcelo bagnulo braun" References: <49E5DB3C.5020806@it.uc3m.es> <49E5FE3B.9080607@cisco.com> In-Reply-To: <49E5FE3B.9080607@cisco.com> Date: Thu, 16 Apr 2009 01:57:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: aZuYJuVB Cc: SAVI Mailing List , Suresh Krishnan , Greg Daley Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 17:58:53 -0000 I agree all of your points, thanks a lot! I would like to propose change the expression of the following sentence "That would enable DAD to be usable as a binding distribution protocol." to "That would enable DAD to be usable for setting up the initial binding table". I know your really meant DAD is good to be used to ant-spoof, yes, thanks. But conceptually, DAD is not a BDP I think. Because, BDP means "Binding table distribution in SAVI switch", DAD indeed doesn't distribute any table in SAVI switch. So conceptually, DAD is not a BDP. DAD is the duplicate detection, but we could make full use of it to achieve the goal of anti-spoofing (by correctly set up the binding table). By the way, the charter doesn't say we have to design a BDP. ----- Original Message ----- From: "Eric Levy-Abegnoli" To: "marcelo bagnulo braun" Cc: "SAVI Mailing List" ; "Suresh Krishnan" ; "Greg Daley" Sent: Wednesday, April 15, 2009 11:33 PM Subject: Re: [savi] DAD as a binding distribution protocol: why not Marcelo, The function that would prevent SWITCHA to forward DAD packets to SWITCHB in this scenario is_not_dictated by RFC4862 or even RFC3810 (MLD). The switches are L2 devices and not expected to limit the multicast forwarding to L3-devices who have joined the group. In theory, DAD multicast should be forwarded to trunks, regardless of who joined. If switches perm MLD snooping, there could be a problem, however RFC4541 is very cautious with regard to switch deciding not_to copy traffic to a port where no join was seen. It looks to me that in this scenario, for switches doing mld snooping, it would not be un-reasonnable to have a configuration option on SWITCHA to enable copy of multicast traffic on its trunks regardless of snooped groups. SWITCHB could still decide not to deliver the traffic to any device if nobody joined the group.concept That would enable DAD to be usable as a binding distribution protocol. Eric marcelo bagnulo braun a 閏rit : > About why DAD does not work as a SAVI binding distribution protocol. > > Several people (including myself) have considered using the DAD > procedure to distribute SAVI binding information across all the SAVI > devices within a link (or broadcast domain). > > In the last meeting, a couple of people (Greg and Suresh to be precise) > explained why this was not possible. I include their argument below, > as they explained it to me, since it is relevant for our discussions. > > Consider the following scenario: > > > > > +--+ +--+ +--+ +--+ +--+ > |HA| |HB| |HC| |HD| |HE| > +--+ +--+ +--+ +--+ +--+ > | | | | | > | +-------------+ +------------+ > +----| SWITCHA |---| SWITCHB | > +-------------+ +------------+ > > Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has IPB > and so on) > > Suppose for this example that the lower 24 bits of all the hosts are > different (what is actually required is that there is no pair of nodes > H1 and H2 located in different switches that have the same lower 24 > bits, but anyway) > > Let's see how does this simple system works in IPv6. > > Suppose all hosts are using stateless autconfiguration. > > So, whenever a host HX gets configures its address, it performs the > procedure described in RFC4862. This procedure, essentially implies to > generate the tentative link local address, join the solicited-node > multicast address for that address, send a NSOL for that address to the > solicted-node multicast group for that address and wait and see. If > nobody replies, it configures the link local address. Using the prefix > information available in the RADV, it can then generate the global > addresses. > > So, note that according to RFC2462, stateless address Autoconfiguration > is performed only on multicast-capable links. > So, suppose that all nodes have configured theu address except for node > HA. > Node HA performs the DAD procedure to configure its address, the > question is who will receive the NSOL that it is issuing? > > By the assumption we made before, that all the hosts had different lower > 24 bits in their addresses, there is no other node that has joined the > solicited node multicast group for the candidate address of HA. In > particular, no hosts connected to SWITCHB has joined the group. > > This means that SWITCHA will _not_ forward the NSOL message of HA's DAD > procedure to SWITCHB. > > The implication for SAVI is that the DAD procedure cannot be trusted as > a way to distribute binding information accross the SAVI devices > connected to the same broadcast domain. > > Now, this is a problem since we cannot rely on this to distribute the > SAVI information. However, it is actually a good thing, in the sense > that we can control much more the size of the binding tables in the SAVI > devices since we can design much more efficient SAVI verification > protocols (pull type of protocols). > > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From junbi@cernet.edu.cn Wed Apr 15 11:00:04 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5553A6E70 for ; Wed, 15 Apr 2009 11:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.593 X-Spam-Level: **** X-Spam-Status: No, score=4.593 tagged_above=-999 required=5 tests=[AWL=-3.139, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, FH_HAS_XAIMC=2.696, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BysIuVPF9bdX for ; Wed, 15 Apr 2009 11:00:03 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 09E623A6B52 for ; Wed, 15 Apr 2009 11:00:02 -0700 (PDT) Received: from userPC([59.66.53.130]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm5649e62424; Thu, 16 Apr 2009 01:59:56 +0800 Message-ID: <81CC4D5082704D0A8A8EFB9BABA51291@userPC> From: "Jun Bi" To: "marcelo bagnulo braun" References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> In-Reply-To: <49E61BCC.70806@it.uc3m.es> Date: Thu, 16 Apr 2009 01:58:37 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: a0uYJuVB Cc: Guang Yao , 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] =?gb2312?b?tPC4tDogIERBRCBhcyBhIGJpbmRpbmcgZGlzdHJpYnV0?= =?gb2312?b?aW9uIHByb3RvY29sOiB3aHkgbm90?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 18:00:05 -0000 > > - what happens if the switch is rebooted? I mean, suppose that you have > a bunch or computers connected to a savi switch. They all have performed > the DAD and the SAVI data base is populated. Now the switch is rebooted > and the data base information is lost. what happens? AFAIU, the SAVI > device will start dropping all the packets, right? We did some test and showed a demo to Chrtion today, we the link is down and up, (you plug the calbe out and intert it again. The switch rebooting is samilar) the host will try to get new address. It's also good for the changing port case. We are writting a SAV experimental draft based on Christian's suggestin. You resonable question are always welcome, because that would be the inputs of our experimental draft. We will do more test to answer those questions and make a report. So you could ask more. If will helpful to make the solution more perfect. > - what happens if the DAD packet is lost? DAD is by definition an > unreliable procedure, so it may happen. Moreover, since the DAD is the > first packet an interface sends, whenever technology takes some time to > move to up state, the first packet is the one with most probabilities to > get lost. Actually, we discussed with Christian during this afternoon's meeting. The Operating systems should send redundancy detection packets. We could make use of the RFCs. IPv4: 3 detection packets.[RFC5227] IPv6: Not specified but it's configurable.[RFC4862] > - are you planning to do some garbage collection? I mean, as Fred has > been saying, we need to keep the tables small. So, at some point the > SAVI device will need to perform some form of garbage collection, what > happens when the entry of a host is deleted by the garbage collection > process? the hsot will not perform the DAD process again, so what > happens? Before clean the entry, the SAVI switch could send out some prob packets to see if the host is still alive. >(and i am not even considering the case where an attacker is > creating savi entries in a bulk manner) If the attack is under SAVI switch, if a host is trying to get too many addresses, the SAVI switch has the ability to contol the suspicious host. > > > So, imho, having a default behaviour of dropping packets seems like the > wrong approach. > > The savi device must learn and be able to recover state when it is lost > while still being able to tell if this is an attacker or not Please give more explaination on your points, we will answer (if we could answer by analysis, then we will answer it soon, otherwise, we will do the experients). Again, you inputs are welcome. > >> >> Considering the incrementatl depolyment, the operator could configure >> three types of ports for the SAVI swtich: SAVI-HOST (savi switch to >> savi host), SAVI-SAVI (savi switch to savi switch), SAVI-Legacy (savi >> switch to legacy switch). SAVI switch will trust packets from >> SAVI-SAVI port. SAVI switch will snoop control packets of SAVI-HOST >> port and setup the intial binding. >> > sure, this sounds the reasonable thing to secure any SAVI protocol > > > Regards, marcelo > >> thanks, >> Jun Bi >> >> ----- Original Message ----- From: "marcelo bagnulo braun" >> >> To: "Guang Yao" >> Cc: "'SAVI Mailing List'" ; "'Suresh Krishnan'" >> ; "'Greg Daley'" >> >> Sent: Wednesday, April 15, 2009 9:58 PM >> Subject: Re: [savi] 答复: DAD as a binding distribution protocol: why not >> >> >>> the point being made is that SWITCHB in the figure below, will not >>> receive the NSOL msg, so it won't be able to learn the binding between >>> the src address and the L2 anchor, so if we want SWITCHB to actually >>> defend that binding, we will need to make SWITCHB learn it though >>> another mean >>> >>> Regards, marcelo >>> >>> >>> Guang Yao escribió: >>>> I think you have forgotten a very important thing: >>>> if there is no collision, there is no need to deliver the NSOL to >>>> all the >>>> nodes. >>>> >>>> In another word, the NSOL must be delivered to the collision node, >>>> no matter >>>> other nodes receive it or not. >>>> >>>> In your scenario, no node pair has collision address, why should the >>>> NSOL be >>>> delivered to all of them? >>>> >>>> -----邮件原件----- >>>> 发件人: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] 代表 >>>> marcelo >>>> bagnulo braun >>>> 发送时间: 2009年4月15日 21:04 >>>> 收件人: SAVI Mailing List; Suresh Krishnan; Greg Daley >>>> 主题: [savi] DAD as a binding distribution protocol: why not >>>> >>>> About why DAD does not work as a SAVI binding distribution protocol. >>>> >>>> Several people (including myself) have considered using the DAD >>>> procedure to distribute SAVI binding information across all the SAVI >>>> devices within a link (or broadcast domain). >>>> >>>> In the last meeting, a couple of people (Greg and Suresh to be precise) >>>> explained why this was not possible. I include their argument below, >>>> as they explained it to me, since it is relevant for our discussions. >>>> >>>> Consider the following scenario: >>>> >>>> >>>> >>>> >>>> +--+ +--+ +--+ +--+ +--+ >>>> |HA| |HB| |HC| |HD| |HE| >>>> +--+ +--+ +--+ +--+ +--+ >>>> | | | | | >>>> | +-------------+ +------------+ >>>> +----| SWITCHA |---| SWITCHB | >>>> +-------------+ +------------+ >>>> >>>> Suppose Host HX has configured address IPX (i.e. HA has IPA, HB has IPB >>>> and so on) >>>> >>>> Suppose for this example that the lower 24 bits of all the hosts are >>>> different (what is actually required is that there is no pair of nodes >>>> H1 and H2 located in different switches that have the same lower 24 >>>> bits, but anyway) >>>> >>>> Let's see how does this simple system works in IPv6. >>>> >>>> Suppose all hosts are using stateless autconfiguration. >>>> >>>> So, whenever a host HX gets configures its address, it performs the >>>> procedure described in RFC4862. This procedure, essentially implies to >>>> generate the tentative link local address, join the solicited-node >>>> multicast address for that address, send a NSOL for that address to the >>>> solicted-node multicast group for that address and wait and see. If >>>> nobody replies, it configures the link local address. Using the prefix >>>> information available in the RADV, it can then generate the global >>>> addresses. >>>> >>>> So, note that according to RFC2462, stateless address Autoconfiguration >>>> is performed only on multicast-capable links. >>>> So, suppose that all nodes have configured theu address except for node >>>> HA. >>>> Node HA performs the DAD procedure to configure its address, the >>>> question is who will receive the NSOL that it is issuing? >>>> >>>> By the assumption we made before, that all the hosts had different >>>> lower >>>> 24 bits in their addresses, there is no other node that has joined the >>>> solicited node multicast group for the candidate address of HA. In >>>> particular, no hosts connected to SWITCHB has joined the group. >>>> >>>> This means that SWITCHA will _not_ forward the NSOL message of HA's DAD >>>> procedure to SWITCHB. >>>> >>>> The implication for SAVI is that the DAD procedure cannot be trusted as >>>> a way to distribute binding information accross the SAVI devices >>>> connected to the same broadcast domain. >>>> >>>> Now, this is a problem since we cannot rely on this to distribute the >>>> SAVI information. However, it is actually a good thing, in the sense >>>> that we can control much more the size of the binding tables in the >>>> SAVI >>>> devices since we can design much more efficient SAVI verification >>>> protocols (pull type of protocols). >>>> >>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>>> >>>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> >> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Wed Apr 15 11:28:26 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC5F3A6F31 for ; Wed, 15 Apr 2009 11:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.035 X-Spam-Level: * X-Spam-Status: No, score=1.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXF3Yq4HQod1 for ; Wed, 15 Apr 2009 11:28:25 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 975393A69F7 for ; Wed, 15 Apr 2009 11:28:24 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (29.pool85-59-200.dynamic.orange.es [85.59.200.29]) by smtp02.uc3m.es (Postfix) with ESMTP id 5E5096C1490; Wed, 15 Apr 2009 20:29:35 +0200 (CEST) Message-ID: <49E6278F.3010603@it.uc3m.es> Date: Wed, 15 Apr 2009 20:29:35 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jun Bi References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> <8439113D7A9F46799815AB8AD2480869@userPC> In-Reply-To: <8439113D7A9F46799815AB8AD2480869@userPC> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16584.001 Cc: Guang Yao , 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] =?gb2312?b?tPC4tDogIERBRCBhcyBhIGJpbmRpbmcgZGlzdHJpYnV0?= =?gb2312?b?aW9uIHByb3RvY29sOiB3aHkgbm90?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 18:28:26 -0000 Jun Bi escribió: > >> >> So, imho, having a default behaviour of dropping packets seems like the >> wrong approach. >> >> The savi device must learn and be able to recover state when it is lost >> while still being able to tell if this is an attacker or not > > When the host wants to use a new address, it has to pass the duplicate > address detection > (please note that SAVI-CPS also works on DHCPv6 and DHCPv4 case for > the duplicate address detection), > otherwise it could not send packets. It is a reasonable logic for > normal users. right, but if something goes wrong, like the DAD packet is lost or the switch state is lost, the host is disconnected from the network, and there doesn't seem to be an easy way to recover, other than rebooting the interface So my concern is that a failure mode of SAVI CPS can have a very serious impact in the network. Regards, marcelo > > thanks, > Jun Bi > >> >>> >>> Considering the incrementatl depolyment, the operator could configure >>> three types of ports for the SAVI swtich: SAVI-HOST (savi switch to >>> savi host), SAVI-SAVI (savi switch to savi switch), SAVI-Legacy (savi >>> switch to legacy switch). SAVI switch will trust packets from >>> SAVI-SAVI port. SAVI switch will snoop control packets of SAVI-HOST >>> port and setup the intial binding. >>> >> sure, this sounds the reasonable thing to secure any SAVI protocol >> >> >> Regards, marcelo >> >>> thanks, >>> Jun Bi >>> >>> ----- Original Message ----- From: "marcelo bagnulo braun" >>> >>> To: "Guang Yao" >>> Cc: "'SAVI Mailing List'" ; "'Suresh Krishnan'" >>> ; "'Greg Daley'" >>> >>> Sent: Wednesday, April 15, 2009 9:58 PM >>> Subject: Re: [savi] 答复: DAD as a binding distribution protocol: >>> why not >>> >>> >>>> the point being made is that SWITCHB in the figure below, will not >>>> receive the NSOL msg, so it won't be able to learn the binding between >>>> the src address and the L2 anchor, so if we want SWITCHB to actually >>>> defend that binding, we will need to make SWITCHB learn it though >>>> another mean >>>> >>>> Regards, marcelo >>>> >>>> >>>> Guang Yao escribió: >>>>> I think you have forgotten a very important thing: >>>>> if there is no collision, there is no need to deliver the NSOL to >>>>> all the >>>>> nodes. >>>>> >>>>> In another word, the NSOL must be delivered to the collision node, >>>>> no matter >>>>> other nodes receive it or not. >>>>> >>>>> In your scenario, no node pair has collision address, why should the >>>>> NSOL be >>>>> delivered to all of them? >>>>> >>>>> -----邮件原件----- >>>>> 发件人: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] 代表 >>>>> marcelo >>>>> bagnulo braun >>>>> 发送时间: 2009年4月15日 21:04 >>>>> 收件人: SAVI Mailing List; Suresh Krishnan; Greg Daley >>>>> 主题: [savi] DAD as a binding distribution protocol: why not >>>>> >>>>> About why DAD does not work as a SAVI binding distribution protocol. >>>>> >>>>> Several people (including myself) have considered using the DAD >>>>> procedure to distribute SAVI binding information across all the SAVI >>>>> devices within a link (or broadcast domain). >>>>> >>>>> In the last meeting, a couple of people (Greg and Suresh to be >>>>> precise) >>>>> explained why this was not possible. I include their argument below, >>>>> as they explained it to me, since it is relevant for our discussions. >>>>> >>>>> Consider the following scenario: >>>>> >>>>> >>>>> >>>>> >>>>> +--+ +--+ +--+ +--+ +--+ >>>>> |HA| |HB| |HC| |HD| |HE| >>>>> +--+ +--+ +--+ +--+ +--+ >>>>> | | | | | >>>>> | +-------------+ +------------+ >>>>> +----| SWITCHA |---| SWITCHB | >>>>> +-------------+ +------------+ >>>>> >>>>> Suppose Host HX has configured address IPX (i.e. HA has IPA, HB >>>>> has IPB >>>>> and so on) >>>>> >>>>> Suppose for this example that the lower 24 bits of all the hosts are >>>>> different (what is actually required is that there is no pair of >>>>> nodes >>>>> H1 and H2 located in different switches that have the same lower 24 >>>>> bits, but anyway) >>>>> >>>>> Let's see how does this simple system works in IPv6. >>>>> >>>>> Suppose all hosts are using stateless autconfiguration. >>>>> >>>>> So, whenever a host HX gets configures its address, it performs the >>>>> procedure described in RFC4862. This procedure, essentially >>>>> implies to >>>>> generate the tentative link local address, join the solicited-node >>>>> multicast address for that address, send a NSOL for that address >>>>> to the >>>>> solicted-node multicast group for that address and wait and see. If >>>>> nobody replies, it configures the link local address. Using the >>>>> prefix >>>>> information available in the RADV, it can then generate the global >>>>> addresses. >>>>> >>>>> So, note that according to RFC2462, stateless address >>>>> Autoconfiguration >>>>> is performed only on multicast-capable links. >>>>> So, suppose that all nodes have configured theu address except for >>>>> node >>>>> HA. >>>>> Node HA performs the DAD procedure to configure its address, the >>>>> question is who will receive the NSOL that it is issuing? >>>>> >>>>> By the assumption we made before, that all the hosts had different >>>>> lower >>>>> 24 bits in their addresses, there is no other node that has joined >>>>> the >>>>> solicited node multicast group for the candidate address of HA. In >>>>> particular, no hosts connected to SWITCHB has joined the group. >>>>> >>>>> This means that SWITCHA will _not_ forward the NSOL message of >>>>> HA's DAD >>>>> procedure to SWITCHB. >>>>> >>>>> The implication for SAVI is that the DAD procedure cannot be >>>>> trusted as >>>>> a way to distribute binding information accross the SAVI devices >>>>> connected to the same broadcast domain. >>>>> >>>>> Now, this is a problem since we cannot rely on this to distribute the >>>>> SAVI information. However, it is actually a good thing, in the sense >>>>> that we can control much more the size of the binding tables in the >>>>> SAVI >>>>> devices since we can design much more efficient SAVI verification >>>>> protocols (pull type of protocols). >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>> >>> >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > > From marcelo@it.uc3m.es Wed Apr 15 11:28:32 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C9EE3A6F2D for ; Wed, 15 Apr 2009 11:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.035 X-Spam-Level: * X-Spam-Status: No, score=1.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SuNKpSQzrX4 for ; Wed, 15 Apr 2009 11:28:30 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 51F1E28C189 for ; Wed, 15 Apr 2009 11:28:30 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (29.pool85-59-200.dynamic.orange.es [85.59.200.29]) by smtp03.uc3m.es (Postfix) with ESMTP id EFB4F730F3A; Wed, 15 Apr 2009 20:29:40 +0200 (CEST) Message-ID: <49E62793.8080108@it.uc3m.es> Date: Wed, 15 Apr 2009 20:29:39 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jun Bi References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> <81CC4D5082704D0A8A8EFB9BABA51291@userPC> In-Reply-To: <81CC4D5082704D0A8A8EFB9BABA51291@userPC> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16584.001 Cc: Guang Yao , 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] =?gb2312?b?tPC4tDogIERBRCBhcyBhIGJpbmRpbmcgZGlzdHJpYnV0?= =?gb2312?b?aW9uIHByb3RvY29sOiB3aHkgbm90?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 18:28:32 -0000 Jun Bi escribió: >> >> - what happens if the switch is rebooted? I mean, suppose that you have >> a bunch or computers connected to a savi switch. They all have performed >> the DAD and the SAVI data base is populated. Now the switch is rebooted >> and the data base information is lost. what happens? AFAIU, the SAVI >> device will start dropping all the packets, right? > > We did some test and showed a demo to Chrtion today, we the link is > down and up, > (you plug the calbe out and intert it again. The switch rebooting is > samilar) > the host will try to get new address. according to rfc4862 5.3. Creation of Link-Local Addresses A node forms a link-local address whenever an interface becomes enabled. An interface may become enabled after any of the following events: - The interface is initialized at system startup time. - The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management. - The interface attaches to a link for the first time. This includes the case where the attached link is dynamically changed due to a change of the access point of wireless networks. - The interface becomes enabled by system management after having been administratively disabled. So it is not obvious to me that you can rely on all the implementations performing the DAD procedure when the switch is rebooted besides, there are several failure modes in a switch, that may result in different behaviour, i guess > It's also good for the changing port case. > We are writting a SAV experimental draft based on Christian's suggestin. > You resonable question are always welcome, because that would be the > inputs > of our experimental draft. We will do more test to answer those > questions and make a report. > So you could ask more. If will helpful to make the solution more perfect. > > >> - what happens if the DAD packet is lost? DAD is by definition an >> unreliable procedure, so it may happen. Moreover, since the DAD is the >> first packet an interface sends, whenever technology takes some time to >> move to up state, the first packet is the one with most probabilities to >> get lost. > > Actually, we discussed with Christian during this afternoon's meeting. > The Operating systems should send redundancy detection packets. We > could make use of the RFCs. > IPv4: 3 detection packets.[RFC5227] > IPv6: Not specified but it's configurable.[RFC4862] yes, but the default value is 1 from rfc4862: DupAddrDetectTransmits The number of consecutive Neighbor Solicitation messages sent while performing Duplicate Address Detection on a tentative address. A value of zero indicates that Duplicate Address Detection is not performed on tentative addresses. A value of one indicates a single transmission with no follow-up retransmissions. Default: 1, but may be overridden by a link-type specific value in the document that covers issues related to the transmission of IP over a particular link type (e.g., [RFC2464]). so loosing that packet would make the host to be disconnected from the network > >> - are you planning to do some garbage collection? I mean, as Fred has >> been saying, we need to keep the tables small. So, at some point the >> SAVI device will need to perform some form of garbage collection, what >> happens when the entry of a host is deleted by the garbage collection >> process? the hsot will not perform the DAD process again, so what >> happens? > > Before clean the entry, the SAVI switch could send out some prob > packets to see if the host is still alive. > makes sense to me > >> (and i am not even considering the case where an attacker is >> creating savi entries in a bulk manner) > > If the attack is under SAVI switch, if a host is trying to get too > many addresses, the SAVI switch has the ability to contol the > suspicious host. > but that is far from obvious how to do it, especially when you have a legacy switch connected to the savi device. I mean, if you have a host, maybe, you need to consider the impact of privacy addresses and his type of things, but still, but when you have a switch connected, i am not sure what number should be reaosnable to have that is compatible with having small tables regards, marcelo > > >> >> >> So, imho, having a default behaviour of dropping packets seems like the >> wrong approach. >> >> The savi device must learn and be able to recover state when it is lost >> while still being able to tell if this is an attacker or not > > Please give more explaination on your points, we will answer (if we > could answer by analysis, then we will answer it soon, > otherwise, we will do the experients). Again, you inputs are welcome. > > > > >> >>> >>> Considering the incrementatl depolyment, the operator could configure >>> three types of ports for the SAVI swtich: SAVI-HOST (savi switch to >>> savi host), SAVI-SAVI (savi switch to savi switch), SAVI-Legacy (savi >>> switch to legacy switch). SAVI switch will trust packets from >>> SAVI-SAVI port. SAVI switch will snoop control packets of SAVI-HOST >>> port and setup the intial binding. >>> >> sure, this sounds the reasonable thing to secure any SAVI protocol >> >> >> Regards, marcelo >> >>> thanks, >>> Jun Bi >>> >>> ----- Original Message ----- From: "marcelo bagnulo braun" >>> >>> To: "Guang Yao" >>> Cc: "'SAVI Mailing List'" ; "'Suresh Krishnan'" >>> ; "'Greg Daley'" >>> >>> Sent: Wednesday, April 15, 2009 9:58 PM >>> Subject: Re: [savi] 答复: DAD as a binding distribution protocol: >>> why not >>> >>> >>>> the point being made is that SWITCHB in the figure below, will not >>>> receive the NSOL msg, so it won't be able to learn the binding between >>>> the src address and the L2 anchor, so if we want SWITCHB to actually >>>> defend that binding, we will need to make SWITCHB learn it though >>>> another mean >>>> >>>> Regards, marcelo >>>> >>>> >>>> Guang Yao escribió: >>>>> I think you have forgotten a very important thing: >>>>> if there is no collision, there is no need to deliver the NSOL to >>>>> all the >>>>> nodes. >>>>> >>>>> In another word, the NSOL must be delivered to the collision node, >>>>> no matter >>>>> other nodes receive it or not. >>>>> >>>>> In your scenario, no node pair has collision address, why should the >>>>> NSOL be >>>>> delivered to all of them? >>>>> >>>>> -----邮件原件----- >>>>> 发件人: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] 代表 >>>>> marcelo >>>>> bagnulo braun >>>>> 发送时间: 2009年4月15日 21:04 >>>>> 收件人: SAVI Mailing List; Suresh Krishnan; Greg Daley >>>>> 主题: [savi] DAD as a binding distribution protocol: why not >>>>> >>>>> About why DAD does not work as a SAVI binding distribution protocol. >>>>> >>>>> Several people (including myself) have considered using the DAD >>>>> procedure to distribute SAVI binding information across all the SAVI >>>>> devices within a link (or broadcast domain). >>>>> >>>>> In the last meeting, a couple of people (Greg and Suresh to be >>>>> precise) >>>>> explained why this was not possible. I include their argument below, >>>>> as they explained it to me, since it is relevant for our discussions. >>>>> >>>>> Consider the following scenario: >>>>> >>>>> >>>>> >>>>> >>>>> +--+ +--+ +--+ +--+ +--+ >>>>> |HA| |HB| |HC| |HD| |HE| >>>>> +--+ +--+ +--+ +--+ +--+ >>>>> | | | | | >>>>> | +-------------+ +------------+ >>>>> +----| SWITCHA |---| SWITCHB | >>>>> +-------------+ +------------+ >>>>> >>>>> Suppose Host HX has configured address IPX (i.e. HA has IPA, HB >>>>> has IPB >>>>> and so on) >>>>> >>>>> Suppose for this example that the lower 24 bits of all the hosts are >>>>> different (what is actually required is that there is no pair of >>>>> nodes >>>>> H1 and H2 located in different switches that have the same lower 24 >>>>> bits, but anyway) >>>>> >>>>> Let's see how does this simple system works in IPv6. >>>>> >>>>> Suppose all hosts are using stateless autconfiguration. >>>>> >>>>> So, whenever a host HX gets configures its address, it performs the >>>>> procedure described in RFC4862. This procedure, essentially >>>>> implies to >>>>> generate the tentative link local address, join the solicited-node >>>>> multicast address for that address, send a NSOL for that address >>>>> to the >>>>> solicted-node multicast group for that address and wait and see. If >>>>> nobody replies, it configures the link local address. Using the >>>>> prefix >>>>> information available in the RADV, it can then generate the global >>>>> addresses. >>>>> >>>>> So, note that according to RFC2462, stateless address >>>>> Autoconfiguration >>>>> is performed only on multicast-capable links. >>>>> So, suppose that all nodes have configured theu address except for >>>>> node >>>>> HA. >>>>> Node HA performs the DAD procedure to configure its address, the >>>>> question is who will receive the NSOL that it is issuing? >>>>> >>>>> By the assumption we made before, that all the hosts had different >>>>> lower >>>>> 24 bits in their addresses, there is no other node that has joined >>>>> the >>>>> solicited node multicast group for the candidate address of HA. In >>>>> particular, no hosts connected to SWITCHB has joined the group. >>>>> >>>>> This means that SWITCHA will _not_ forward the NSOL message of >>>>> HA's DAD >>>>> procedure to SWITCHB. >>>>> >>>>> The implication for SAVI is that the DAD procedure cannot be >>>>> trusted as >>>>> a way to distribute binding information accross the SAVI devices >>>>> connected to the same broadcast domain. >>>>> >>>>> Now, this is a problem since we cannot rely on this to distribute the >>>>> SAVI information. However, it is actually a good thing, in the sense >>>>> that we can control much more the size of the binding tables in the >>>>> SAVI >>>>> devices since we can design much more efficient SAVI verification >>>>> protocols (pull type of protocols). >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>> >>> >>> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > > From fred@cisco.com Wed Apr 15 11:46:57 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 676093A6E77 for ; Wed, 15 Apr 2009 11:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.651 X-Spam-Level: X-Spam-Status: No, score=-103.651 tagged_above=-999 required=5 tests=[AWL=-1.896, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2414AAYZcoz for ; Wed, 15 Apr 2009 11:46:56 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 602DD28C1BD for ; Wed, 15 Apr 2009 11:46:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,193,1238976000"; d="scan'208";a="41923934" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Apr 2009 18:47:25 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3FIlPIr020913; Wed, 15 Apr 2009 14:47:25 -0400 Received: from dhcp-64-100-227-211.cisco.com (dhcp-64-100-227-211.cisco.com [64.100.227.211]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3FIlP3v003025; Wed, 15 Apr 2009 18:47:25 GMT Message-Id: From: Fred Baker To: marcelo bagnulo braun In-Reply-To: <49E6278F.3010603@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 15 Apr 2009 14:47:24 -0400 References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> <8439113D7A9F46799815AB8AD2480869@userPC> <49E6278F.3010603@it.uc3m.es> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=930; t=1239821245; x=1240685245; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20=3D?GB2312?Q?Re=3A_[savi]_=3DB4=3DF0=3DB8=3DB4= 3A__DAD_as_a_binding_distributi?=3D=0A=20=3D?GB2312?Q?on_pro tocol=3A_why_not?=3D |Sender:=20 |To:=20marcelo=20bagnulo=20braun=20; bh=RXNY0wabuH0a5T45CvPPnQrBcGAmBrELlqMWF7r/XjE=; b=BO4ZflnkydI+Tdui31akp9H+y4sVzcqLMtD7ePejdYNlfGWQ8o6bqL9Jca qHR3aLOsozIksRp+Ifg9mUnZS3VWrkXZJAjdvZn4bLbxIhghea87O7o9/qu6 YxIt8DV/IM; Authentication-Results: rtp-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: Guang Yao , 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] =?gb2312?b?tPC4tDogIERBRCBhcyBhIGJpbmRpbmcgZGlzdHJpYnV0?= =?gb2312?b?aW9uIHByb3RvY29sOiB3aHkgbm90?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 18:46:57 -0000 On Apr 15, 2009, at 2:29 PM, marcelo bagnulo braun wrote: > So my concern is that a failure mode of SAVI CPS can have a very > serious > impact in the network. May I balance that statement a little? Yes, failure modes create issues. I can think of some interesting, and related, failure modes in FCFS as well - if a datagram that was in fact the first user of an address is lost, someone else might accidentally concoct the same address and try to use it. I will point out, however, that ALL of today's fielded proto-savi equipment (Cisco, Extreme, and I think others) depend on DHCP snooping, which is one instance of CPS. I'm sure that there is an occasional glitch, but as near as we can tell they all in fact work to their administrator's satisfaction. The reason we have DHCPv6 address assignment is that operators have told us they would like that to be among their options... From junbi@tsinghua.edu.cn Wed Apr 15 17:55:29 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AA123A6B64 for ; Wed, 15 Apr 2009 17:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.516 X-Spam-Level: *** X-Spam-Status: No, score=3.516 tagged_above=-999 required=5 tests=[AWL=-3.015, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, DNS_FROM_RFC_DSN=1.495, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDfEuoddmGwQ for ; Wed, 15 Apr 2009 17:55:28 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id 0B5093A6975 for ; Wed, 15 Apr 2009 17:55:28 -0700 (PDT) Received: from th053130.ip.tsinghua.edu.cn ([59.66.53.130] helo=userPC) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1LuFtx-0007ID-LN; Thu, 16 Apr 2009 08:56:25 +0800 Message-ID: <77A0148AB18541428E47DB28CCEDA526@userPC> From: "Jun Bi" To: "marcelo bagnulo braun" References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC><49E61BCC.70806@it.uc3m.es><8439113D7A9F46799815AB8AD2480869@userPC> <49E6278F.3010603@it.uc3m.es> In-Reply-To: <49E6278F.3010603@it.uc3m.es> Date: Thu, 16 Apr 2009 08:56:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="gb2312"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 Cc: Guang Yao , 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] =?gb2312?b?tPC4tDogIERBRCBhcyBhIGJpbmRpbmcgZGlzdHJpYnV0?= =?gb2312?b?aW9uIHByb3RvY29sOiB3aHkgbm90?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Jun Bi List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 00:55:29 -0000 In 802.1x access, the defaul is dropping packets. it has been widely deployed, after the password checking (also stored some states for hosts), the user could communicated. I didn't see any problem from 802.1x. SAVI-CPS' requirement is less than 802.1x, so I think it won't be a problem. thanks, Jun Bi ----- Original Message ----- From: "marcelo bagnulo braun" To: "Jun Bi" Cc: "Guang Yao" ; "'SAVI Mailing List'" ; "'Suresh Krishnan'" ; "'Greg Daley'" Sent: Thursday, April 16, 2009 2:29 AM Subject: Re: [savi] 答复: DAD as a binding distribution protocol: why not > Jun Bi escribió: >> >>> >>> So, imho, having a default behaviour of dropping packets seems like the >>> wrong approach. >>> >>> The savi device must learn and be able to recover state when it is lost >>> while still being able to tell if this is an attacker or not >> >> When the host wants to use a new address, it has to pass the duplicate >> address detection >> (please note that SAVI-CPS also works on DHCPv6 and DHCPv4 case for >> the duplicate address detection), >> otherwise it could not send packets. It is a reasonable logic for >> normal users. > > right, but if something goes wrong, like the DAD packet is lost or the > switch state is lost, the host is disconnected from the network, and > there doesn't seem to be an easy way to recover, other than rebooting > the interface > So my concern is that a failure mode of SAVI CPS can have a very serious > impact in the network. > > Regards, marcelo > > >> >> thanks, >> Jun Bi >> >>> >>>> >>>> Considering the incrementatl depolyment, the operator could configure >>>> three types of ports for the SAVI swtich: SAVI-HOST (savi switch to >>>> savi host), SAVI-SAVI (savi switch to savi switch), SAVI-Legacy (savi >>>> switch to legacy switch). SAVI switch will trust packets from >>>> SAVI-SAVI port. SAVI switch will snoop control packets of SAVI-HOST >>>> port and setup the intial binding. >>>> >>> sure, this sounds the reasonable thing to secure any SAVI protocol >>> >>> >>> Regards, marcelo >>> >>>> thanks, >>>> Jun Bi >>>> >>>> ----- Original Message ----- From: "marcelo bagnulo braun" >>>> >>>> To: "Guang Yao" >>>> Cc: "'SAVI Mailing List'" ; "'Suresh Krishnan'" >>>> ; "'Greg Daley'" >>>> >>>> Sent: Wednesday, April 15, 2009 9:58 PM >>>> Subject: Re: [savi] 答复: DAD as a binding distribution protocol: >>>> why not >>>> >>>> >>>>> the point being made is that SWITCHB in the figure below, will not >>>>> receive the NSOL msg, so it won't be able to learn the binding between >>>>> the src address and the L2 anchor, so if we want SWITCHB to actually >>>>> defend that binding, we will need to make SWITCHB learn it though >>>>> another mean >>>>> >>>>> Regards, marcelo >>>>> >>>>> >>>>> Guang Yao escribió: >>>>>> I think you have forgotten a very important thing: >>>>>> if there is no collision, there is no need to deliver the NSOL to >>>>>> all the >>>>>> nodes. >>>>>> >>>>>> In another word, the NSOL must be delivered to the collision node, >>>>>> no matter >>>>>> other nodes receive it or not. >>>>>> >>>>>> In your scenario, no node pair has collision address, why should the >>>>>> NSOL be >>>>>> delivered to all of them? >>>>>> >>>>>> -----邮件原件----- >>>>>> 发件人: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] 代表 >>>>>> marcelo >>>>>> bagnulo braun >>>>>> 发送时间: 2009年4月15日 21:04 >>>>>> 收件人: SAVI Mailing List; Suresh Krishnan; Greg Daley >>>>>> 主题: [savi] DAD as a binding distribution protocol: why not >>>>>> >>>>>> About why DAD does not work as a SAVI binding distribution protocol. >>>>>> >>>>>> Several people (including myself) have considered using the DAD >>>>>> procedure to distribute SAVI binding information across all the SAVI >>>>>> devices within a link (or broadcast domain). >>>>>> >>>>>> In the last meeting, a couple of people (Greg and Suresh to be >>>>>> precise) >>>>>> explained why this was not possible. I include their argument below, >>>>>> as they explained it to me, since it is relevant for our discussions. >>>>>> >>>>>> Consider the following scenario: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> +--+ +--+ +--+ +--+ +--+ >>>>>> |HA| |HB| |HC| |HD| |HE| >>>>>> +--+ +--+ +--+ +--+ +--+ >>>>>> | | | | | >>>>>> | +-------------+ +------------+ >>>>>> +----| SWITCHA |---| SWITCHB | >>>>>> +-------------+ +------------+ >>>>>> >>>>>> Suppose Host HX has configured address IPX (i.e. HA has IPA, HB >>>>>> has IPB >>>>>> and so on) >>>>>> >>>>>> Suppose for this example that the lower 24 bits of all the hosts are >>>>>> different (what is actually required is that there is no pair of >>>>>> nodes >>>>>> H1 and H2 located in different switches that have the same lower 24 >>>>>> bits, but anyway) >>>>>> >>>>>> Let's see how does this simple system works in IPv6. >>>>>> >>>>>> Suppose all hosts are using stateless autconfiguration. >>>>>> >>>>>> So, whenever a host HX gets configures its address, it performs the >>>>>> procedure described in RFC4862. This procedure, essentially >>>>>> implies to >>>>>> generate the tentative link local address, join the solicited-node >>>>>> multicast address for that address, send a NSOL for that address >>>>>> to the >>>>>> solicted-node multicast group for that address and wait and see. If >>>>>> nobody replies, it configures the link local address. Using the >>>>>> prefix >>>>>> information available in the RADV, it can then generate the global >>>>>> addresses. >>>>>> >>>>>> So, note that according to RFC2462, stateless address >>>>>> Autoconfiguration >>>>>> is performed only on multicast-capable links. >>>>>> So, suppose that all nodes have configured theu address except for >>>>>> node >>>>>> HA. >>>>>> Node HA performs the DAD procedure to configure its address, the >>>>>> question is who will receive the NSOL that it is issuing? >>>>>> >>>>>> By the assumption we made before, that all the hosts had different >>>>>> lower >>>>>> 24 bits in their addresses, there is no other node that has joined >>>>>> the >>>>>> solicited node multicast group for the candidate address of HA. In >>>>>> particular, no hosts connected to SWITCHB has joined the group. >>>>>> >>>>>> This means that SWITCHA will _not_ forward the NSOL message of >>>>>> HA's DAD >>>>>> procedure to SWITCHB. >>>>>> >>>>>> The implication for SAVI is that the DAD procedure cannot be >>>>>> trusted as >>>>>> a way to distribute binding information accross the SAVI devices >>>>>> connected to the same broadcast domain. >>>>>> >>>>>> Now, this is a problem since we cannot rely on this to distribute the >>>>>> SAVI information. However, it is actually a good thing, in the sense >>>>>> that we can control much more the size of the binding tables in the >>>>>> SAVI >>>>>> devices since we can design much more efficient SAVI verification >>>>>> protocols (pull type of protocols). >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> >> >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@cernet.edu.cn Wed Apr 15 17:57:40 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 853F13A6B64 for ; Wed, 15 Apr 2009 17:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.347 X-Spam-Level: ** X-Spam-Status: No, score=2.347 tagged_above=-999 required=5 tests=[AWL=1.798, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYNuT0Y9iCp5 for ; Wed, 15 Apr 2009 17:57:39 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 31E333A6AD2 for ; Wed, 15 Apr 2009 17:57:38 -0700 (PDT) Received: from userPC([59.66.53.130]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm549e7029d; Thu, 16 Apr 2009 08:58:45 +0800 Message-ID: From: "Jun Bi" To: "Fred Baker" , "marcelo bagnulo braun" References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> <8439113D7A9F46799815AB8AD2480869@userPC> <49E6278F.3010603@it.uc3m.es> In-Reply-To: Date: Thu, 16 Apr 2009 08:58:16 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: soNwPuVB Cc: Guang Yao , 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] =?utf-8?b?562U5aSNOiAgREFEIGFzIGEgYmluZGluZyBkaXN0cmlidXRp?= =?utf-8?q?on_protocol=3A_why_not?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 00:57:40 -0000 ----- Original Message ----- From: "Fred Baker" To: "marcelo bagnulo braun" Cc: "Jun Bi" ; "Guang Yao" ; "'SAVI Mailing List'" ; "'Suresh Krishnan'" ; "'Greg Daley'" Sent: Thursday, April 16, 2009 2:47 AM Subject: Re: [savi] 绛斿: DAD as a binding distribution protocol: why not > > On Apr 15, 2009, at 2:29 PM, marcelo bagnulo braun wrote: > >> So my concern is that a failure mode of SAVI CPS can have a very serious >> impact in the network. > > May I balance that statement a little? > > Yes, failure modes create issues. I can think of some interesting, and > related, failure modes in FCFS as well - if a datagram that was in fact > the first user of an address is lost, someone else might accidentally > concoct the same address and try to use it. > > I will point out, however, that ALL of today's fielded proto-savi > equipment (Cisco, Extreme, and I think others) depend on DHCP snooping, > which is one instance of CPS. I'm sure that there is an occasional > glitch, but as near as we can tell they all in fact work to their > administrator's satisfaction. Agree! > > The reason we have DHCPv6 address assignment is that operators have told > us they would like that to be among their options... Yes, tasteful address assignment is better. From junbi@cernet.edu.cn Wed Apr 15 18:11:57 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8F933A6C60 for ; Wed, 15 Apr 2009 18:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.122 X-Spam-Level: ** X-Spam-Status: No, score=2.122 tagged_above=-999 required=5 tests=[AWL=1.573, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Epj76ELCBRly for ; Wed, 15 Apr 2009 18:11:57 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 7BA373A6C27 for ; Wed, 15 Apr 2009 18:11:56 -0700 (PDT) Received: from userPC([59.66.53.130]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm4549e705f2; Thu, 16 Apr 2009 09:12:58 +0800 Message-ID: From: "Jun Bi" To: "Fred Baker" , "marcelo bagnulo braun" References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> <8439113D7A9F46799815AB8AD2480869@userPC> <49E6278F.3010603@it.uc3m.es> In-Reply-To: Date: Thu, 16 Apr 2009 09:12:27 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: skyJQuVB Cc: Guang Yao , 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] =?utf-8?b?562U5aSNOiAgREFEIGFzIGEgYmluZGluZyBkaXN0cmlidXRp?= =?utf-8?q?on_protocol=3A_why_not?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 01:11:57 -0000 ----- Original Message ----- From: "Fred Baker" To: "marcelo bagnulo braun" Cc: "Jun Bi" ; "Guang Yao" ; "'SAVI Mailing List'" ; "'Suresh Krishnan'" ; "'Greg Daley'" Sent: Thursday, April 16, 2009 2:47 AM Subject: Re: [savi] 绛斿: DAD as a binding distribution protocol: why not > > On Apr 15, 2009, at 2:29 PM, marcelo bagnulo braun wrote: > >> So my concern is that a failure mode of SAVI CPS can have a very serious >> impact in the network. > > May I balance that statement a little? > > Yes, failure modes create issues. I can think of some interesting, and > related, failure modes in FCFS as well - if a datagram that was in fact > the first user of an address is lost, someone else might accidentally > concoct the same address and try to use it. I agree. Currently at least there 2 RFCs to support redundent duplicate address detections. (it's reasonable). If we let the hosts to send the same data packets several times, the operating system vednors may feel strange. And how you define the "first" packet? So you may also need a state for data packets, otherwise, the host has to send deplicate packets for all data packets many times. Is the state of SAVI switch of the "first" packet always equal to the host's state? In control protocol, it is easy to define the state with clear concepts, it conforms to RFCs. But the FCFS may affect the nature of data packets. So I think SAVI-CPS is in a better situation. Certainly, the major problem of SAVI-FCFS is not only the first packet lost. Even the first packet is not lost, FCFS still need a BDP, and it might be complex when we have multiple SAVI-swtiches (the real-time sync requirements), we even didn't see a prototype of BDP yet. But SAVI-CPS doesn't need the BDP, just need some enhancement. thanks, Jun Bi From marcelo@it.uc3m.es Thu Apr 16 01:39:24 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888223A6845 for ; Thu, 16 Apr 2009 01:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgLwEfSkm2QK for ; Thu, 16 Apr 2009 01:39:23 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 5EAE03A6359 for ; Thu, 16 Apr 2009 01:39:23 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id CBA11B49B1E; Thu, 16 Apr 2009 10:40:34 +0200 (CEST) Message-ID: <49E6EF02.3090104@it.uc3m.es> Date: Thu, 16 Apr 2009 10:40:34 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Fred Baker References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> <8439113D7A9F46799815AB8AD2480869@userPC> <49E6278F.3010603@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16584.006 Cc: Guang Yao , 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] =?windows-1252?q?=3F=3F=3A__DAD_as_a_binding_distribution_?= =?windows-1252?q?protocol=3A_why_not?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 08:39:24 -0000 Fred Baker escribi: > > On Apr 15, 2009, at 2:29 PM, marcelo bagnulo braun wrote: > >> So my concern is that a failure mode of SAVI CPS can have a very serious >> impact in the network. > > May I balance that statement a little? > > Yes, failure modes create issues. I can think of some interesting, and > related, failure modes in FCFS as well - if a datagram that was in > fact the first user of an address is lost, someone else might > accidentally concoct the same address and try to use it. SAVI FCFS uses both data packets as well as ND packet for the creation of the binding. In case the first packet is lost (which is probably the DAD NSOL), both solutions don't create a binding (cause the packet is lost). the different is that from then on, SAVI FCFS can create binding using data packets ,while SAVI CPS will simply drop all the following packets. About the case you mention, you mean that the first packet is lost and i guess this would be the NSOL packet. At that moment another node sends a packet with that source address. If it is legitimate node, this packet will be the NSOL of the DAD procedure of the otgher node. The first node will receive that packet and reply with NADV defending its address. The FCFS SAVI is designed to track the whole DAD procedure, so it wouldn't create a binding for the new node, but will honour the first node. If the first packet is a data packet, this is likely to be an attack. The problem here is that the attacker needs to be able to intercept the first packet and drop it (doesn't seem tto be a very useful attack to me to simply wait and see if the first packet is lost, i guess). So, if an attacker is able to intercept packet, then i guess it can launch any kind of attacks that i guess are out of the scope of the protection we designing savi for. > > I will point out, however, that ALL of today's fielded proto-savi > equipment (Cisco, Extreme, and I think others) depend on DHCP > snooping, which is one instance of CPS. I'm sure that there is an > occasional glitch, but as near as we can tell they all in fact work to > their administrator's satisfaction. > > The reason we have DHCPv6 address assignment is that operators have > told us they would like that to be among their options... Right I all for having a DHCP based solution (if you remember, in the last meeting i actually asked for that) DHCP based snooping seems different to me. First of all, dhcp packet exchange is reliable, in the sense that ACK are used for the assignment. In case one packet is lost, there will be retrial until the packet is acked. So, since it is inherently more reliabel than DAD procedure, i believe it is much more safer to trust in dhcp snooping than in DAD snooping. makes sense? Regards, marcelo From fred@cisco.com Thu Apr 16 02:38:55 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1BEB3A6CF9 for ; Thu, 16 Apr 2009 02:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.477 X-Spam-Level: X-Spam-Status: No, score=-106.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+VjkLWlSpPz for ; Thu, 16 Apr 2009 02:38:54 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A433F3A680A for ; Thu, 16 Apr 2009 02:38:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,197,1238976000"; d="scan'208";a="287241078" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 16 Apr 2009 09:40:07 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3G9e76v013486; Thu, 16 Apr 2009 02:40:07 -0700 Received: from [172.16.1.3] (sjc-vpn3-917.cisco.com [10.21.67.149]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3G9e6bj029760; Thu, 16 Apr 2009 09:40:06 GMT Message-Id: <4668AF4B-2260-4679-A9B9-F3804F53EE50@cisco.com> From: Fred Baker To: marcelo bagnulo braun In-Reply-To: <49E6EF02.3090104@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 05:40:06 -0400 References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> <8439113D7A9F46799815AB8AD2480869@userPC> <49E6278F.3010603@it.uc3m.es> <49E6EF02.3090104@it.uc3m.es> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2935; t=1239874807; x=1240738807; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20??=3A=20=20DAD=20as=20a=20bind ing=20distribution=20protocol=3A=20why=20not |Sender:=20; bh=VlnSpDzE+QhzGXpO56UbAtQhpdt2xiQ5udtv8tVUxQ8=; b=dudS0kYLx+gZCPXD01n9zQ64Q5QJaGrcU5by9Kz3wLjZEV9k56TCs0I+z1 ulHeOGJvAsIlEDCzCQVUTl27JqAU4oaBlmBH5VilBxF8KA9chdGX/vOUab9R VKj/E4sDq1; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Guang Yao , 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] ??: DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 09:38:55 -0000 On Apr 16, 2009, at 4:40 AM, marcelo bagnulo braun wrote: > DHCP based snooping seems different to me. First of all, dhcp packet > exchange is reliable, in the sense that ACK are used for the > assignment. In case one packet is lost, there will be retrial until > the packet is acked. So, since it is inherently more reliabel than > DAD procedure, i believe it is much more safer to trust in dhcp > snooping than in DAD snooping. Well, they are both snooping on an exchange that the switch is not a party to, so while it may be reliable for the endpoints, it is not necessarily reliable for the third party. But you are looking at different cases. With DHCP snooping, a central controller assigns an address to a system; with the DAD procedure, the assumption is that the system that originated the datagram simply sent it (which would happen if it had been manually configured and you were running FCFS), and you are dealing with what may be a configuration error. If DHCP is in use, or any of the other protocols that CPS applies to, so be it. The address is assigned and the switch refuses any other source addresses. Done. If FCFS is in use, one of three things is happening: - SLAAC, which implies DAD - Manual configuration - Attacks DAD for SLAAC is intended to deal with the issue in the end system, which is of course the preferred option. SAVI is intended to isolate attacks and manual misconfigurations. The question before the house has been what to do in a multi-switch network. I assert that having every SAVI switch have knowledge of every IPv6 address in the LAN imposes an undue burden (and therefore monetary cost in a market that is very cost-sensitive) on the switches; they do need to know about their own client systems, but not the clients of other switches. And they have no way of knowing the IP or MAC address of the switch that forwarded the conflicting datagram. Hence, they cannot send an error response to the specific switch in question. So we have two options for dealing with attacks and manual misconfigurations via neighboring switches. We design a protocol and have the switch that detects the conflict multicast to "all SAVI switches" that {IPv6 Address, MAC Address} is an inappropriate combination, or we use some existing protocol that is intended to say the same thing. DAD is such a protocol, and it seems like we should be able to use it. Yes, the solution is not perfect. However, there is an attack in using multicast error responses as well - a system that wants to attack the network generates a long stream of erroneous messages, knowing that the various switches will pummel each other with multicasts. So that is not perfect either. Between two imperfect solutions, I'm in favor of the unicast one that has a high probability of success. From marcelo@it.uc3m.es Thu Apr 16 03:21:31 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519A13A69B1 for ; Thu, 16 Apr 2009 03:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbIYf-I7aAPE for ; Thu, 16 Apr 2009 03:21:30 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id EE35D3A69B0 for ; Thu, 16 Apr 2009 03:21:29 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp01.uc3m.es (Postfix) with ESMTP id 7D015B9FE81; Thu, 16 Apr 2009 12:22:40 +0200 (CEST) Message-ID: <49E706F0.9070101@it.uc3m.es> Date: Thu, 16 Apr 2009 12:22:40 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Fred Baker References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> <8439113D7A9F46799815AB8AD2480869@userPC> <49E6278F.3010603@it.uc3m.es> <49E6EF02.3090104@it.uc3m.es> <4668AF4B-2260-4679-A9B9-F3804F53EE50@cisco.com> In-Reply-To: <4668AF4B-2260-4679-A9B9-F3804F53EE50@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16584.006 Cc: Guang Yao , 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] ??: DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 10:21:31 -0000 Fred Baker escribi: > > On Apr 16, 2009, at 4:40 AM, marcelo bagnulo braun wrote: > >> DHCP based snooping seems different to me. First of all, dhcp packet >> exchange is reliable, in the sense that ACK are used for the >> assignment. In case one packet is lost, there will be retrial until >> the packet is acked. So, since it is inherently more reliabel than >> DAD procedure, i believe it is much more safer to trust in dhcp >> snooping than in DAD snooping. > > Well, they are both snooping on an exchange that the switch is not a > party to, so while it may be reliable for the endpoints, it is not > necessarily reliable for the third party. right, but the packets are only delivered is they pass through the switch, so if we have two endpoints that have reliable exchange, the only way it can be succesfully completed, is if and only if the switch in the middle has forwarded the packet, hence it is also reliable for the middle device. > > But you are looking at different cases. With DHCP snooping, a central > controller assigns an address to a system; with the DAD procedure, the > assumption is that the system that originated the datagram simply sent > it (which would happen if it had been manually configured and you were > running FCFS), and you are dealing with what may be a configuration > error. right as i said, i don't have a problem with using snooping for dhcp > > If DHCP is in use, or any of the other protocols that CPS applies to, > so be it. The address is assigned and the switch refuses any other > source addresses. Done. > not done if the packet is lost, which is possible is the transport iof the packet is unreliable, the host is disconnected from the network, and the only clear way to make it work is to restart the host interface My concren here is that if this solution is dpeloyed, the solution itslef will be a source of attacks to the network. > If FCFS is in use, one of three things is happening: > - SLAAC, which implies DAD > - Manual configuration > - Attacks > > DAD for SLAAC is intended to deal with the issue in the end system, > which is of course the preferred option. SAVI is intended to isolate > attacks and manual misconfigurations. > > The question before the house has been what to do in a multi-switch > network. I assert that having every SAVI switch have knowledge of > every IPv6 address in the LAN imposes an undue burden (and therefore > monetary cost in a market that is very cost-sensitive) on the switches; i agree with that but as i said beofre there is no need for that, you can use, as you call it a binding verification protocol moreover, in simple topologies this is no needed > they do need to know about their own client systems, but not the > clients of other switches. And they have no way of knowing the IP or > MAC address of the switch that forwarded the conflicting datagram. > Hence, they cannot send an error response to the specific switch in > question. > but they not need to know the mac address of the end host that has the source address If i am switch a, i can ask to switch b if it knows a given source address. If switch b knows it, switch b only needs to know that this address can only come from the port connected to switch b no need to know the mac address of the node that has this address > So we have two options for dealing with attacks and manual > misconfigurations via neighboring switches. We design a protocol and > have the switch that detects the conflict multicast to "all SAVI > switches" that {IPv6 Address, MAC Address} is an inappropriate > combination, or we use some existing protocol that is intended to say > the same thing. DAD is such a protocol, and it seems like we should be > able to use it. i am lst here are you propsoing the switches to issue DAD packets? or simply snoop the DAD performed by the hosts? > Yes, the solution is not perfect. However, there is an attack in using > multicast error responses as well - a system that wants to attack the > network generates a long stream of erroneous messages, knowing that > the various switches will pummel each other with multicasts. So that > is not perfect either. > > Between two imperfect solutions, I'm in favor of the unicast one that > has a high probability of success. > but the analysis is not as simple as both are imperfect, but we need to understand what are the consequences of the failure modes my worry is that the consequence of SAV CPS failure modes are serious Regards, marcelo From marcelo@it.uc3m.es Thu Apr 16 03:28:02 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34CC33A6803 for ; Thu, 16 Apr 2009 03:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-4.117, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_64=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a01T6-mVGyIc for ; Thu, 16 Apr 2009 03:28:00 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 37F1C3A67D9 for ; Thu, 16 Apr 2009 03:27:59 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 7A25A6BA9AE; Thu, 16 Apr 2009 12:29:11 +0200 (CEST) Message-ID: <49E70877.1020903@it.uc3m.es> Date: Thu, 16 Apr 2009 12:29:11 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jun Bi References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> <81CC4D5082704D0A8A8EFB9BABA51291@userPC> <49E62793.8080108@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16584.006 Cc: Guang Yao , 'SAVI Mailing List' , 'Suresh Krishnan' , 'Greg Daley' Subject: Re: [savi] =?gb2312?b?tPC4tDogIERBRCBhcyBhIGJpbmRpbmcgZGlzdHJpYnV0?= =?gb2312?b?aW9uIHByb3RvY29sOiB3aHkgbm90?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 10:28:02 -0000 Jun Bi escribió: > 1 the packet loss rate in a local link scope might be very low. Depends on what type of environment you are i guess. and the problem, is that the consequences of loosing this first packet, are very serious, i.e. the host gets disconnected from the network. > 2 if a SAVI swtich is deployed, the operator could ask the user of > host to configure a little. I am not sure what you mean by that, but we are supposed to define a solution that doesn't require to touch the hosts. If host configuration is required, i think the deployability of the solution would be greatly reduced > 3 by experiements, we did see no problem when link is up and down. Consider the following scenario: +-------+ |HOST | +-------+ | +------------------+ |LEGACY SWITCH | +------------------+ | +------------------+ |SAVI CPS DEVICE | +------------------+ | +----------------+ |REST of WORLD | +----------------+ I understand this can be a very common configuration, for instance when the SAVI fucntion i located in the router rahter than in the switch(this seems to be the topology the broadband forum is looking into), or when you are having an incremental deployment of SAVI and you have upgraded some switches and not others suppose that the HOST boots and perform DAD. The savi cps device creates state everything is working fine SAVI CPS device is rebooted (happens all the time at home for instance) Now the SAVI CPS Data base is deleted and SAVI CPS starts dropping packets from HOST, since HOST will not perform the DAD again Regards, marcelo > > thanks, > Jun > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "Jun Bi" > Cc: "Guang Yao" ; "'SAVI Mailing > List'" ; "'Suresh Krishnan'" > ; "'Greg Daley'" > > Sent: Thursday, April 16, 2009 2:29 AM > Subject: Re: [savi] 答复: DAD as a binding distribution protocol: why not > > >> Jun Bi escribió: >>>> >>>> - what happens if the switch is rebooted? I mean, suppose that you >>>> have >>>> a bunch or computers connected to a savi switch. They all have >>>> performed >>>> the DAD and the SAVI data base is populated. Now the switch is >>>> rebooted >>>> and the data base information is lost. what happens? AFAIU, the SAVI >>>> device will start dropping all the packets, right? >>> >>> We did some test and showed a demo to Chrtion today, we the link is >>> down and up, >>> (you plug the calbe out and intert it again. The switch rebooting is >>> samilar) >>> the host will try to get new address. >> >> according to rfc4862 >> >> 5.3. Creation of Link-Local Addresses >> >> A node forms a link-local address whenever an interface becomes >> enabled. An interface may become enabled after any of the following >> events: >> >> - The interface is initialized at system startup time. >> >> - The interface is reinitialized after a temporary interface failure >> or after being temporarily disabled by system management. >> >> - The interface attaches to a link for the first time. This >> includes the case where the attached link is dynamically changed >> due to a change of the access point of wireless networks. >> >> - The interface becomes enabled by system management after having >> been administratively disabled. >> >> So it is not obvious to me that you can rely on all the implementations >> performing the DAD procedure when the switch is rebooted >> >> besides, there are several failure modes in a switch, that may result in >> different behaviour, i guess >> >>> It's also good for the changing port case. >>> We are writting a SAV experimental draft based on Christian's >>> suggestin. >>> You resonable question are always welcome, because that would be the >>> inputs >>> of our experimental draft. We will do more test to answer those >>> questions and make a report. >>> So you could ask more. If will helpful to make the solution more >>> perfect. >>> >>> >>>> - what happens if the DAD packet is lost? DAD is by definition an >>>> unreliable procedure, so it may happen. Moreover, since the DAD is the >>>> first packet an interface sends, whenever technology takes some >>>> time to >>>> move to up state, the first packet is the one with most >>>> probabilities to >>>> get lost. >>> >>> Actually, we discussed with Christian during this afternoon's meeting. >>> The Operating systems should send redundancy detection packets. We >>> could make use of the RFCs. >>> IPv4: 3 detection packets.[RFC5227] >>> IPv6: Not specified but it's configurable.[RFC4862] >> >> yes, but the default value is 1 >> >> from rfc4862: >> >> DupAddrDetectTransmits The number of consecutive Neighbor >> Solicitation messages sent while performing Duplicate Address >> Detection on a tentative address. A value of zero indicates that >> Duplicate Address Detection is not performed on tentative >> addresses. A value of one indicates a single transmission with no >> follow-up retransmissions. >> >> Default: 1, but may be overridden by a link-type specific value in >> the document that covers issues related to the transmission of IP >> over a particular link type (e.g., [RFC2464]). >> >> so loosing that packet would make the host to be disconnected from the >> network >> >>> >>>> - are you planning to do some garbage collection? I mean, as Fred has >>>> been saying, we need to keep the tables small. So, at some point the >>>> SAVI device will need to perform some form of garbage collection, what >>>> happens when the entry of a host is deleted by the garbage collection >>>> process? the hsot will not perform the DAD process again, so what >>>> happens? >>> >>> Before clean the entry, the SAVI switch could send out some prob >>> packets to see if the host is still alive. >>> >> makes sense to me >> >>> >>>> (and i am not even considering the case where an attacker is >>>> creating savi entries in a bulk manner) >>> >>> If the attack is under SAVI switch, if a host is trying to get too >>> many addresses, the SAVI switch has the ability to contol the >>> suspicious host. >>> >> >> but that is far from obvious how to do it, especially when you have a >> legacy switch connected to the savi device. I mean, if you have a host, >> maybe, you need to consider the impact of privacy addresses and his type >> of things, but still, but when you have a switch connected, i am not >> sure what number should be reaosnable to have that is compatible with >> having small tables >> >> regards, marcelo >> >>> >>> >>>> >>>> >>>> So, imho, having a default behaviour of dropping packets seems like >>>> the >>>> wrong approach. >>>> >>>> The savi device must learn and be able to recover state when it is >>>> lost >>>> while still being able to tell if this is an attacker or not >>> >>> Please give more explaination on your points, we will answer (if we >>> could answer by analysis, then we will answer it soon, >>> otherwise, we will do the experients). Again, you inputs are welcome. >>> >>> >>> >>> >>>> >>>>> >>>>> Considering the incrementatl depolyment, the operator could configure >>>>> three types of ports for the SAVI swtich: SAVI-HOST (savi switch to >>>>> savi host), SAVI-SAVI (savi switch to savi switch), SAVI-Legacy (savi >>>>> switch to legacy switch). SAVI switch will trust packets from >>>>> SAVI-SAVI port. SAVI switch will snoop control packets of SAVI-HOST >>>>> port and setup the intial binding. >>>>> >>>> sure, this sounds the reasonable thing to secure any SAVI protocol >>>> >>>> >>>> Regards, marcelo >>>> >>>>> thanks, >>>>> Jun Bi >>>>> >>>>> ----- Original Message ----- From: "marcelo bagnulo braun" >>>>> >>>>> To: "Guang Yao" >>>>> Cc: "'SAVI Mailing List'" ; "'Suresh Krishnan'" >>>>> ; "'Greg Daley'" >>>>> >>>>> Sent: Wednesday, April 15, 2009 9:58 PM >>>>> Subject: Re: [savi] 答复: DAD as a binding distribution protocol: >>>>> why not >>>>> >>>>> >>>>>> the point being made is that SWITCHB in the figure below, will not >>>>>> receive the NSOL msg, so it won't be able to learn the binding >>>>>> between >>>>>> the src address and the L2 anchor, so if we want SWITCHB to actually >>>>>> defend that binding, we will need to make SWITCHB learn it though >>>>>> another mean >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>> Guang Yao escribió: >>>>>>> I think you have forgotten a very important thing: >>>>>>> if there is no collision, there is no need to deliver the NSOL to >>>>>>> all the >>>>>>> nodes. >>>>>>> >>>>>>> In another word, the NSOL must be delivered to the collision node, >>>>>>> no matter >>>>>>> other nodes receive it or not. >>>>>>> >>>>>>> In your scenario, no node pair has collision address, why should >>>>>>> the >>>>>>> NSOL be >>>>>>> delivered to all of them? >>>>>>> >>>>>>> -----邮件原件----- >>>>>>> 发件人: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] 代表 >>>>>>> marcelo >>>>>>> bagnulo braun >>>>>>> 发送时间: 2009年4月15日 21:04 >>>>>>> 收件人: SAVI Mailing List; Suresh Krishnan; Greg Daley >>>>>>> 主题: [savi] DAD as a binding distribution protocol: why not >>>>>>> >>>>>>> About why DAD does not work as a SAVI binding distribution >>>>>>> protocol. >>>>>>> >>>>>>> Several people (including myself) have considered using the DAD >>>>>>> procedure to distribute SAVI binding information across all the >>>>>>> SAVI >>>>>>> devices within a link (or broadcast domain). >>>>>>> >>>>>>> In the last meeting, a couple of people (Greg and Suresh to be >>>>>>> precise) >>>>>>> explained why this was not possible. I include their argument >>>>>>> below, >>>>>>> as they explained it to me, since it is relevant for our >>>>>>> discussions. >>>>>>> >>>>>>> Consider the following scenario: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> +--+ +--+ +--+ +--+ +--+ >>>>>>> |HA| |HB| |HC| |HD| |HE| >>>>>>> +--+ +--+ +--+ +--+ +--+ >>>>>>> | | | | | >>>>>>> | +-------------+ +------------+ >>>>>>> +----| SWITCHA |---| SWITCHB | >>>>>>> +-------------+ +------------+ >>>>>>> >>>>>>> Suppose Host HX has configured address IPX (i.e. HA has IPA, HB >>>>>>> has IPB >>>>>>> and so on) >>>>>>> >>>>>>> Suppose for this example that the lower 24 bits of all the hosts >>>>>>> are >>>>>>> different (what is actually required is that there is no pair of >>>>>>> nodes >>>>>>> H1 and H2 located in different switches that have the same lower 24 >>>>>>> bits, but anyway) >>>>>>> >>>>>>> Let's see how does this simple system works in IPv6. >>>>>>> >>>>>>> Suppose all hosts are using stateless autconfiguration. >>>>>>> >>>>>>> So, whenever a host HX gets configures its address, it performs the >>>>>>> procedure described in RFC4862. This procedure, essentially >>>>>>> implies to >>>>>>> generate the tentative link local address, join the solicited-node >>>>>>> multicast address for that address, send a NSOL for that address >>>>>>> to the >>>>>>> solicted-node multicast group for that address and wait and see. If >>>>>>> nobody replies, it configures the link local address. Using the >>>>>>> prefix >>>>>>> information available in the RADV, it can then generate the global >>>>>>> addresses. >>>>>>> >>>>>>> So, note that according to RFC2462, stateless address >>>>>>> Autoconfiguration >>>>>>> is performed only on multicast-capable links. >>>>>>> So, suppose that all nodes have configured theu address except for >>>>>>> node >>>>>>> HA. >>>>>>> Node HA performs the DAD procedure to configure its address, the >>>>>>> question is who will receive the NSOL that it is issuing? >>>>>>> >>>>>>> By the assumption we made before, that all the hosts had different >>>>>>> lower >>>>>>> 24 bits in their addresses, there is no other node that has joined >>>>>>> the >>>>>>> solicited node multicast group for the candidate address of HA. In >>>>>>> particular, no hosts connected to SWITCHB has joined the group. >>>>>>> >>>>>>> This means that SWITCHA will _not_ forward the NSOL message of >>>>>>> HA's DAD >>>>>>> procedure to SWITCHB. >>>>>>> >>>>>>> The implication for SAVI is that the DAD procedure cannot be >>>>>>> trusted as >>>>>>> a way to distribute binding information accross the SAVI devices >>>>>>> connected to the same broadcast domain. >>>>>>> >>>>>>> Now, this is a problem since we cannot rely on this to >>>>>>> distribute the >>>>>>> SAVI information. However, it is actually a good thing, in the >>>>>>> sense >>>>>>> that we can control much more the size of the binding tables in the >>>>>>> SAVI >>>>>>> devices since we can design much more efficient SAVI verification >>>>>>> protocols (pull type of protocols). >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> savi mailing list >>>>>>> savi@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>> >>> >>> >> >> > > > From marcelo@it.uc3m.es Thu Apr 16 03:38:44 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D2E93A6DF7 for ; Thu, 16 Apr 2009 03:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.079 X-Spam-Level: X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVH4f90rUpEY for ; Thu, 16 Apr 2009 03:38:43 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 33F2A3A6D1A for ; Thu, 16 Apr 2009 03:38:43 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (wlap005.it.uc3m.es [163.117.139.108]) by smtp02.uc3m.es (Postfix) with ESMTP id 74D536BA988; Thu, 16 Apr 2009 12:39:54 +0200 (CEST) Message-ID: <49E70AF9.3080800@it.uc3m.es> Date: Thu, 16 Apr 2009 12:39:53 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jun Bi References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> <8439113D7A9F46799815AB8AD2480869@userPC> <49E6278F.3010603@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16584.006 Cc: 'Greg Daley' , Guang Yao , 'SAVI Mailing List' , 'Suresh Krishnan' Subject: Re: [savi] =?utf-8?b?562U5aSNOiAgREFEIGFzIGEgYmluZGluZyBkaXN0cmlidXRp?= =?utf-8?q?on_protocol=3A_why_not?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 10:38:44 -0000 Jun Bi escribi贸: > > ----- Original Message ----- From: "Fred Baker" > To: "marcelo bagnulo braun" > Cc: "Jun Bi" ; "Guang Yao" > ; "'SAVI Mailing List'" > ; "'Suresh Krishnan'" ; > "'Greg Daley'" > Sent: Thursday, April 16, 2009 2:47 AM > Subject: Re: [savi] 绛斿: DAD as a binding distribution protocol: why not > > >> >> On Apr 15, 2009, at 2:29 PM, marcelo bagnulo braun wrote: >> >>> So my concern is that a failure mode of SAVI CPS can have a very >>> serious >>> impact in the network. >> >> May I balance that statement a little? >> >> Yes, failure modes create issues. I can think of some interesting, >> and related, failure modes in FCFS as well - if a datagram that was >> in fact the first user of an address is lost, someone else might >> accidentally concoct the same address and try to use it. > > I agree. Currently at least there 2 RFCs to support redundent > duplicate address detections. as i said earlier, the default value of rfc4862 is 1 NSOL for DAD > (it's reasonable). If we let the hosts to send the same data packets > several times, SAVI FCFS don't need to send the msae4 packet multiple times If a packet is lost, it will create the state using the next packet, doesn't have to be the same one > the operating system vednors may feel strange. And how you define the > "first" packet? it is the first packet the savi device sees > So you may also need a state for data packets, otherwise, the host has > to send deplicate packets > for all data packets many times. Is the state of SAVI switch of the > "first" packet always equal to > the host's state? no, hosts don't change anything if the first apcket is lost, savi creates state witht he next packet > In control protocol, it is easy to define the state with clear > concepts, it conforms to RFCs. > But the FCFS may affect the nature of data packets. So I think > SAVI-CPS is in a better situation. > no, SAVI FCFS doens't change the nature of data packets > Certainly, the major problem of SAVI-FCFS is not only the first packet > lost. Even the first packet is not lost, > FCFS still need a BDP, and it might be complex when we have multiple > SAVI-swtiches i agree that needing a BDP is painful, no questions about that OTOH, switches already run protocols, such as STP, or trill the question is whether we can avoid that complexity and still have a reasonably safe solution I don't think this is the case > (the real-time sync requirements), we even didn't see a prototype of > BDP yet. > But SAVI-CPS doesn't need the BDP, just need some enhancement. > check the other email i sent you with a different failure mode affecting one of main SAVI targetted scenario, regards, marcelo > thanks, > Jun Bi > > From lint@h3c.com Sat Apr 18 09:04:31 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96CEC3A6DD1 for ; Sat, 18 Apr 2009 09:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.756 X-Spam-Level: ** X-Spam-Status: No, score=2.756 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MISSING_SUBJECT=1.762, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKkeEyhn8Wju for ; Sat, 18 Apr 2009 09:04:31 -0700 (PDT) Received: from huawei-3com.com (unknown [60.191.123.50]) by core3.amsl.com (Postfix) with ESMTP id AB3533A6B53 for ; Sat, 18 Apr 2009 09:04:29 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KIB000NK0PHNL@h3cml01-in.huawei-3com.com> for savi@ietf.org; Sun, 19 Apr 2009 00:05:41 +0800 (CST) Received: from huawei-3com.com ([172.25.15.135]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KIB00L1I0PHND@h3cml01-in.huawei-3com.com> for savi@ietf.org; Sun, 19 Apr 2009 00:05:41 +0800 (CST) Received: from [172.25.15.126] (Forwarded-For: [125.96.99.87]) by h3cmc02-in.huawei-3com.com (mshttpd); Sun, 19 Apr 2009 00:25:48 +0800 Date: Sun, 19 Apr 2009 00:25:48 +0800 From: lintao 00450 To: SAVI Mailing List Message-id: <1a37331a288b.1a288b1a3733@huawei-3com.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal Subject: [savi] (no subject) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2009 16:04:31 -0000 Hi, all I'm puzzled by one ip address on multiple interface in the charter. I wish someone to clear it, thank you very much. If one host have multiple interface with on ip address, and they connect to one switch, how should the switch forward the back packet to the host? Which port is the right back port? +------------------------+ + SWITCH + + + +----+---+---+---+-------+ | | +----+---+--------+ + HOST + + + +-----------------+ Anycast shouldn't be the source address of the parcket from the host, and I haven't seen the usage of anycast in this condition. If it's used in load balancing in server farm, there haven't savi requirement. I think this isn't the important factor is savi. How does anyone think about it? From fred@cisco.com Sat Apr 18 21:15:02 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4303A6DAE for ; Sat, 18 Apr 2009 21:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.482 X-Spam-Level: X-Spam-Status: No, score=-106.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbkAYz0qUMSV for ; Sat, 18 Apr 2009 21:15:01 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 373983A63C9 for ; Sat, 18 Apr 2009 21:15:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,212,1238976000"; d="scan'208";a="173581681" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 19 Apr 2009 04:16:16 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3J4GGfM024879; Sat, 18 Apr 2009 21:16:16 -0700 Received: from [172.16.1.3] ([10.21.72.87]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3J4GD8e001153; Sun, 19 Apr 2009 04:16:14 GMT Message-Id: From: Fred Baker To: lintao 00450 In-Reply-To: <1a37331a288b.1a288b1a3733@huawei-3com.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 19 Apr 2009 00:16:13 -0400 References: <1a37331a288b.1a288b1a3733@huawei-3com.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1915; t=1240114576; x=1240978576; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20(no=20subject) |Sender:=20; bh=HfN0MKUn3K9zHkWwkmbF61zBkqqw2CQjXSKLxOeDvLU=; b=qcIqrA9PZlT4cuOJOR2TuTnAk6iVXH1O1WB32OvAIQzrWlyWB1svD9cKUP AsMpLJllKtk65ZvHr2gmicq2FNeLawlprLM7J5lv2Nm/R6ugCdRtFalwIv+M XrAab3Dqpc; Authentication-Results: sj-dkim-4; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] (no subject) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2009 04:15:02 -0000 I general, different interfaces get different addresses, since an IP address (IPv4 or IPv6) is the address of an interface. I can think of two scenarios in which a system might use the same IP address on two interfaces. One is, properly, a misconfiguration, but probably would in fact work for most purposes. In that, the two interfaces on on the same LAN and therefore use identical prefixes, and one could imagine them being configured with the same address. SLAAC should not result in a common address, though, due to DAD. The other is a case in which an address is assigned to a virtual interface such as a loopback interface, and routing is told that both of the interfaces are appropriate router-router paths to get to that "remote" address. In that case, the rules of multipath routing apply. On Apr 18, 2009, at 12:25 PM, lintao 00450 wrote: > Hi, all > > I'm puzzled by one ip address on multiple interface in the charter. > I wish someone to clear it, thank you very much. > > If one host have multiple interface with on ip address, and they > connect to one switch, how should the switch forward the > > back packet to the host? Which port is the right back port? > > +------------------------+ > + SWITCH + > + + > +----+---+---+---+-------+ > | | > +----+---+--------+ > + HOST + > + + > +-----------------+ > > Anycast shouldn't be the source address of the parcket from the > host, and I haven't seen the usage of anycast in this > > condition. If it's used in load balancing in server farm, there > haven't savi requirement. > > I think this isn't the important factor is savi. How does anyone > think about it? > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From zhangdong_rh@huaweisymantec.com Tue Apr 21 02:38:22 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052A93A6B11 for ; Tue, 21 Apr 2009 02:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.624 X-Spam-Level: **** X-Spam-Status: No, score=4.624 tagged_above=-999 required=5 tests=[AWL=3.260, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Byakd9q3p+fj for ; Tue, 21 Apr 2009 02:38:21 -0700 (PDT) Received: from mta1.huaweisymantec.com (unknown [218.17.155.14]) by core3.amsl.com (Postfix) with ESMTP id 110543A6AE2 for ; Tue, 21 Apr 2009 02:38:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KIF00BXKZSMBP40@hstga01-in.huaweisymantec.com> for savi@ietf.org; Tue, 21 Apr 2009 16:34:00 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KIF002U1ZSKIM00@hstml02-in.huaweisymantec.com> for savi@ietf.org; Tue, 21 Apr 2009 16:33:58 +0800 (CST) Received: from [10.27.154.174] by hstml02-in.huaweisymantec.com (mshttpd); Tue, 21 Apr 2009 16:33:56 +0800 From: ZhangDong To: Jun Bi Message-id: Date: Tue, 21 Apr 2009 16:33:56 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Cc: savi@ietf.org Subject: [savi] some comments on savi-cps X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 09:38:22 -0000 Hi Jun, It seems that some language problems appear in the document. IMHO, the document need to be revised better in language. I guess that it is useful for the readers to understand the cps solution clearly. I have seen some grammar and expression mistakes. I only list two examples below. >6. Definition of Anchor >... >This document doesn't specify which entities can be used as anchor, >and how secure these anchors. This sentence is vague and it has grammar mistake. "How secure these anchors are" or "how to secure these anchors", which one is the right meaning? >Whenever a DHCPv4 request is received from attaching host, and the >requested IP address does not exist in the binding table, the device >will generate an entry in the Binding State Table (BST), set the >state field to be DHCPv4_START. The lifetime of this entry is set to >be MAX_DHCP_RESPONSE_TIME. I think the word "be" here is surplus. "The lifetime of this entry is set to MAX_DHCP_RESPONSE_TIME. " Am i right? >8.3.1. Process of ND Snooping > >This process is designed for stateless auto-configuration assigned >IPv6 address and manually configured IPv6 address. I guess that ND snooping also might be used for CGA generation. Because CGA generation uses DAD in the same way. >1. Divide the address space of SAVI nodes and non-SAVI nodes; >2. Partition SAVI nodes and non-SAVI nodes to different VLANs. What are definitions of the savi nodes and the non-savi nodes? Do you mean that a savi-node already has the binding entry in the savi device? I think that in the case of VLAN, the DAD may be disabled. I mean the duplicate address message cannot go through from one vlan to another. So it still has the possibility of address collision. Right? Thanks a lot. Dong Zhang From junbi@cernet.edu.cn Tue Apr 21 11:47:13 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77813A6E84 for ; Tue, 21 Apr 2009 11:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.022 X-Spam-Level: *** X-Spam-Status: No, score=3.022 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_50=0.001, FH_HAS_XAIMC=2.696, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WEjj4R1dyjP for ; Tue, 21 Apr 2009 11:47:13 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.3.66]) by core3.amsl.com (Postfix) with SMTP id 842EB3A6E6E for ; Tue, 21 Apr 2009 11:47:11 -0700 (PDT) Received: from userPC([59.66.24.146]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm2549ee1a96; Wed, 22 Apr 2009 02:48:27 +0800 Message-ID: <58649AA447844D598C044D640EFE5054@userPC> From: "Jun Bi" To: "ZhangDong" References: In-Reply-To: Date: Wed, 22 Apr 2009 02:48:22 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: JuJBVwVB Cc: savi@ietf.org Subject: Re: [savi] some comments on savi-cps X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 18:47:13 -0000 Hi Dong, Thank you, we will take a look your comments and revise. thanks, Jun ----- Original Message ----- From: "ZhangDong" To: "Jun Bi" Cc: Sent: Tuesday, April 21, 2009 4:33 PM Subject: some comments on savi-cps > Hi Jun, > > It seems that some language problems appear in the document. IMHO, the > document need to be revised better in language. I guess that it is useful > for the readers to understand the cps solution clearly. > I have seen some grammar and expression mistakes. I only list two examples > below. >>6. Definition of Anchor >>... >>This document doesn't specify which entities can be used as anchor, >>and how secure these anchors. > This sentence is vague and it has grammar mistake. "How secure these > anchors are" or "how to secure these anchors", which one is the right > meaning? > >>Whenever a DHCPv4 request is received from attaching host, and the >>requested IP address does not exist in the binding table, the device >>will generate an entry in the Binding State Table (BST), set the >>state field to be DHCPv4_START. The lifetime of this entry is set to >>be MAX_DHCP_RESPONSE_TIME. > I think the word "be" here is surplus. "The lifetime of this entry is set > to MAX_DHCP_RESPONSE_TIME. " Am i right? > > > >>8.3.1. Process of ND Snooping >> >>This process is designed for stateless auto-configuration assigned >>IPv6 address and manually configured IPv6 address. > I guess that ND snooping also might be used for CGA generation. Because > CGA generation uses DAD in the same way. > >>1. Divide the address space of SAVI nodes and non-SAVI nodes; >>2. Partition SAVI nodes and non-SAVI nodes to different VLANs. > What are definitions of the savi nodes and the non-savi nodes? Do you mean > that a savi-node already has the binding entry in the savi device? > I think that in the case of VLAN, the DAD may be disabled. I mean the > duplicate address message cannot go through from one vlan to another. So > it still has the possibility of address collision. Right? > > > Thanks a lot. > > Dong Zhang > > From lint@h3c.com Wed Apr 22 03:08:30 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACCE63A6D0B for ; Wed, 22 Apr 2009 03:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.908 X-Spam-Level: *** X-Spam-Status: No, score=3.908 tagged_above=-999 required=5 tests=[AWL=2.181, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0wTFxqCDGCX for ; Wed, 22 Apr 2009 03:08:29 -0700 (PDT) Received: from huawei-3com.com (unknown [221.12.31.13]) by core3.amsl.com (Postfix) with ESMTP id BD41C28C467 for ; Wed, 22 Apr 2009 03:08:28 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KIH006U5YZ8GE@h3cml02-in.huawei-3com.com> for savi@ietf.org; Wed, 22 Apr 2009 18:11:32 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.126]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KIH0079EYZ8CN@h3cml02-in.huawei-3com.com> for savi@ietf.org; Wed, 22 Apr 2009 18:11:32 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.19]) by smtp2.h3c.com with ESMTP; Wed, 22 Apr 2009 18:05:07 +0800 Date: Wed, 22 Apr 2009 18:09:42 +0800 From: Lin Tao To: Fred Baker Message-id: <003701c9c332$74e11920$1311990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1a37331a288b.1a288b1a3733@huawei-3com.com> Cc: SAVI Mailing List Subject: Re: [savi] (no subject) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 10:08:30 -0000 Thank you very much! I'm sorry so late. It's misconfiguration in the frist scenario, so that is not permitted in savi, isn't that? In the second scenario, the device connect the host must have multipath function. I think this is not in switch now, isn't that? So I think the same IP address on twon interfaces needn't be considered in savi. How do you think? Thanks. ----- Original Message ----- From: "Fred Baker" To: "lintao 00450" Cc: "SAVI Mailing List" Sent: Sunday, April 19, 2009 12:16 PM Subject: Re: [savi] (no subject) >I general, different interfaces get different addresses, since an IP > address (IPv4 or IPv6) is the address of an interface. > > I can think of two scenarios in which a system might use the same IP > address on two interfaces. One is, properly, a misconfiguration, but > probably would in fact work for most purposes. In that, the two > interfaces on on the same LAN and therefore use identical prefixes, > and one could imagine them being configured with the same address. > SLAAC should not result in a common address, though, due to DAD. The > other is a case in which an address is assigned to a virtual interface > such as a loopback interface, and routing is told that both of the > interfaces are appropriate router-router paths to get to that "remote" > address. In that case, the rules of multipath routing apply. > > On Apr 18, 2009, at 12:25 PM, lintao 00450 wrote: > >> Hi, all >> >> I'm puzzled by one ip address on multiple interface in the charter. >> I wish someone to clear it, thank you very much. >> >> If one host have multiple interface with on ip address, and they >> connect to one switch, how should the switch forward the >> >> back packet to the host? Which port is the right back port? >> >> +------------------------+ >> + SWITCH + >> + + >> +----+---+---+---+-------+ >> | | >> +----+---+--------+ >> + HOST + >> + + >> +-----------------+ >> >> Anycast shouldn't be the source address of the parcket from the >> host, and I haven't seen the usage of anycast in this >> >> condition. If it's used in load balancing in server farm, there >> haven't savi requirement. >> >> I think this isn't the important factor is savi. How does anyone >> think about it? >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From fred@cisco.com Wed Apr 22 04:29:13 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87AB53A6C4C for ; Wed, 22 Apr 2009 04:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.451 X-Spam-Level: X-Spam-Status: No, score=-106.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYKipYCf0YVX for ; Wed, 22 Apr 2009 04:29:12 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 64A003A6BAF for ; Wed, 22 Apr 2009 04:29:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,230,1238976000"; d="scan'208";a="42464752" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 22 Apr 2009 11:30:26 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3MBUQ3n028394; Wed, 22 Apr 2009 07:30:26 -0400 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3MBUQg8016124; Wed, 22 Apr 2009 11:30:26 GMT From: Fred Baker To: Lin Tao In-Reply-To: <003701c9c332$74e11920$1311990a@h3c.huawei3com.com> X-Priority: 3 References: <1a37331a288b.1a288b1a3733@huawei-3com.com> <003701c9c332$74e11920$1311990a@h3c.huawei3com.com> Message-Id: <0671D0A5-0BF8-491D-A2C6-91EB4D7BF93B@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 04:30:19 -0700 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2980; t=1240399826; x=1241263826; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[savi]=20(no=20subject) |Sender:=20 |To:=20Lin=20Tao=20; bh=eSeb2AS5RRxAKHjUMTf/awUBbCgWK3uzQY7kV/FNw7c=; b=mHFxq9oI8bRW5bq0AACX753kQlxWvrBI50+G1BJRJLIm/f95B3QfznUPji vgvHExY4+SX+lE82udHklsGulJL+Yv//OWiI+OKVu4pBXDMSQIpm1RrXzhVx NwrovII5b5; Authentication-Results: rtp-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SAVI Mailing List Subject: Re: [savi] (no subject) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 11:29:13 -0000 I would find using the same IP address on two interfaces highly unusual in the IP architecture. SO, we needn't address it. On Apr 22, 2009, at 3:09 AM, Lin Tao wrote: > Thank you very much! I'm sorry so late. It's misconfiguration in the > frist > scenario, so that is not permitted in savi, isn't that? > > In the second scenario, the device connect the host must have > multipath > function. I think this is not in switch now, isn't that? > > So I think the same IP address on twon interfaces needn't be > considered > in savi. How do you think? > > Thanks. > > ----- Original Message ----- > From: "Fred Baker" > To: "lintao 00450" > Cc: "SAVI Mailing List" > Sent: Sunday, April 19, 2009 12:16 PM > Subject: Re: [savi] (no subject) > > >> I general, different interfaces get different addresses, since an IP >> address (IPv4 or IPv6) is the address of an interface. >> >> I can think of two scenarios in which a system might use the same IP >> address on two interfaces. One is, properly, a misconfiguration, but >> probably would in fact work for most purposes. In that, the two >> interfaces on on the same LAN and therefore use identical prefixes, >> and one could imagine them being configured with the same address. >> SLAAC should not result in a common address, though, due to DAD. The >> other is a case in which an address is assigned to a virtual >> interface >> such as a loopback interface, and routing is told that both of the >> interfaces are appropriate router-router paths to get to that >> "remote" >> address. In that case, the rules of multipath routing apply. >> >> On Apr 18, 2009, at 12:25 PM, lintao 00450 wrote: >> >>> Hi, all >>> >>> I'm puzzled by one ip address on multiple interface in the charter. >>> I wish someone to clear it, thank you very much. >>> >>> If one host have multiple interface with on ip address, and they >>> connect to one switch, how should the switch forward the >>> >>> back packet to the host? Which port is the right back port? >>> >>> +------------------------+ >>> + SWITCH + >>> + + >>> +----+---+---+---+-------+ >>> | | >>> +----+---+--------+ >>> + HOST + >>> + + >>> +-----------------+ >>> >>> Anycast shouldn't be the source address of the parcket from the >>> host, and I haven't seen the usage of anycast in this >>> >>> condition. If it's used in load balancing in server farm, there >>> haven't savi requirement. >>> >>> I think this isn't the important factor is savi. How does anyone >>> think about it? >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> From gdaley@netstarnetworks.com Wed Apr 22 15:59:25 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802BB3A6E8F for ; Wed, 22 Apr 2009 15:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMHSRT1xDma9 for ; Wed, 22 Apr 2009 15:59:24 -0700 (PDT) Received: from mail.syd.netstarnetworks.com (mail.syd.netstarnetworks.com [203.8.7.220]) by core3.amsl.com (Postfix) with ESMTP id F1B4F3A6ABF for ; Wed, 22 Apr 2009 15:59:23 -0700 (PDT) Received: from sydmail.netstarnetworks.com ([10.18.193.13]) by mail.syd.netstarnetworks.com (8.12.8/8.12.8) with ESMTP id n3MN0WRs015658; Thu, 23 Apr 2009 09:00:33 +1000 Received: from melmail.netstarnetworks.com ([10.20.193.13]) by sydmail.netstarnetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 09:00:28 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C39E.20D14654" Date: Thu, 23 Apr 2009 08:59:10 +1000 Message-ID: <6983BF97BFC24D4EA551F140712329181FA770@melmail.netstarnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Same IP, two interfaces (maybe not at same time) Thread-Index: AcnDPcE61ZehkGyOSMaDYe5EylETIAAYDEx5 References: <1a37331a288b.1a288b1a3733@huawei-3com.com><003701c9c332$74e11920$1311990a@h3c.huawei3com.com> <0671D0A5-0BF8-491D-A2C6-91EB4D7BF93B@cisco.com> From: "Greg Daley" To: "Fred Baker" , "Lin Tao" X-OriginalArrivalTime: 22 Apr 2009 23:00:28.0703 (UTC) FILETIME=[214292F0:01C9C39E] Cc: SAVI Mailing List Subject: [savi] Same IP, two interfaces (maybe not at same time) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 22:59:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C39E.20D14654 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fred,=20 Do we have a way of handling the HSRP/VRRP/Clustering of addresses? Greg -----Original Message----- From: savi-bounces@ietf.org on behalf of Fred Baker Sent: Wed 4/22/2009 9:30 PM To: Lin Tao Cc: SAVI Mailing List Subject: Re: [savi] (no subject) =20 I would find using the same IP address on two interfaces highly =20 unusual in the IP architecture. SO, we needn't address it. On Apr 22, 2009, at 3:09 AM, Lin Tao wrote: > Thank you very much! I'm sorry so late. It's misconfiguration in the =20 > frist > scenario, so that is not permitted in savi, isn't that? > > In the second scenario, the device connect the host must have =20 > multipath > function. I think this is not in switch now, isn't that? > > So I think the same IP address on twon interfaces needn't be =20 > considered > in savi. How do you think? > > Thanks. > > ----- Original Message ----- > From: "Fred Baker" > To: "lintao 00450" > Cc: "SAVI Mailing List" > Sent: Sunday, April 19, 2009 12:16 PM > Subject: Re: [savi] (no subject) > > >> I general, different interfaces get different addresses, since an IP >> address (IPv4 or IPv6) is the address of an interface. >> >> I can think of two scenarios in which a system might use the same IP >> address on two interfaces. One is, properly, a misconfiguration, but >> probably would in fact work for most purposes. In that, the two >> interfaces on on the same LAN and therefore use identical prefixes, >> and one could imagine them being configured with the same address. >> SLAAC should not result in a common address, though, due to DAD. The >> other is a case in which an address is assigned to a virtual =20 >> interface >> such as a loopback interface, and routing is told that both of the >> interfaces are appropriate router-router paths to get to that =20 >> "remote" >> address. In that case, the rules of multipath routing apply. >> >> On Apr 18, 2009, at 12:25 PM, lintao 00450 wrote: >> >>> Hi, all >>> >>> I'm puzzled by one ip address on multiple interface in the charter. >>> I wish someone to clear it, thank you very much. >>> >>> If one host have multiple interface with on ip address, and they >>> connect to one switch, how should the switch forward the >>> >>> back packet to the host? Which port is the right back port? >>> >>> +------------------------+ >>> + SWITCH + >>> + + >>> +----+---+---+---+-------+ >>> | | >>> +----+---+--------+ >>> + HOST + >>> + + >>> +-----------------+ >>> >>> Anycast shouldn't be the source address of the parcket from the >>> host, and I haven't seen the usage of anycast in this >>> >>> condition. If it's used in load balancing in server farm, there >>> haven't savi requirement. >>> >>> I think this isn't the important factor is savi. How does anyone >>> think about it? >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi ------_=_NextPart_001_01C9C39E.20D14654 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Same IP, two interfaces (maybe not at same time)

Hi Fred,

Do we have a way of handling the HSRP/VRRP/Clustering of addresses?

Greg

-----Original Message-----
From: savi-bounces@ietf.org on behalf of Fred Baker
Sent: Wed 4/22/2009 9:30 PM
To: Lin Tao
Cc: SAVI Mailing List
Subject: Re: [savi] (no subject)

I would find using the same IP address on two interfaces = highly 
unusual in the IP architecture. SO, we needn't address it.

On Apr 22, 2009, at 3:09 AM, Lin Tao wrote:

> Thank you very much! I'm sorry so late. It's misconfiguration in = the 
> frist
> scenario,  so that is not permitted in savi, isn't that?
>
> In the second scenario, the device connect the host must = have 
> multipath
> function. I think this is not in switch now, isn't that?
>
> So I think the same IP address on twon interfaces needn't = be 
> considered
> in savi. How do you think?
>
> Thanks.
>
> ----- Original Message -----
> From: "Fred Baker" <fred@cisco.com>
> To: "lintao 00450" <lint@h3c.com>
> Cc: "SAVI Mailing List" <savi@ietf.org>
> Sent: Sunday, April 19, 2009 12:16 PM
> Subject: Re: [savi] (no subject)
>
>
>> I general, different interfaces get different addresses, since = an IP
>> address (IPv4 or IPv6) is the address of an interface.
>>
>> I can think of two scenarios in which a system might use the = same IP
>> address on two interfaces. One is, properly, a = misconfiguration, but
>> probably would in fact work for most purposes. In that, the = two
>> interfaces on on the same LAN and therefore use identical = prefixes,
>> and one could imagine them being configured with the same = address.
>> SLAAC should not result in a common address, though, due to = DAD. The
>> other is a case in which an address is assigned to a = virtual 
>> interface
>> such as a loopback interface, and routing is told that both of = the
>> interfaces are appropriate router-router paths to get to = that 
>> "remote"
>> address. In that case, the rules of multipath routing = apply.
>>
>> On Apr 18, 2009, at 12:25 PM, lintao 00450 wrote:
>>
>>> Hi, all
>>>
>>> I'm puzzled by one ip address on multiple interface in the = charter.
>>> I wish someone to clear it, thank you very much.
>>>
>>> If one host have multiple interface with on ip address, and = they
>>> connect to one switch, how should the switch forward = the
>>>
>>> back packet to the host? Which port is the right back = port?
>>>
>>> +------------------------+
>>> +     = SWITCH           &= nbsp; +
>>> = +            =             +
>>> +----+---+---+---+-------+
>>>    |   |
>>> +----+---+--------+
>>> +     = HOST        +
>>> = +            =      +
>>> +-----------------+
>>>
>>> Anycast shouldn't be the source address of the parcket from = the
>>> host, and I haven't seen the usage of anycast in this
>>>
>>> condition. If it's used in load balancing in server farm, = there
>>> haven't savi requirement.
>>>
>>> I think this isn't the important factor is savi. How does = anyone
>>> think about it?
>>>
>>> _______________________________________________
>>> savi mailing list
>>> savi@ietf.org
>>> https://www.ietf.org/= mailman/listinfo/savi
>>
>> _______________________________________________
>> savi mailing list
>> savi@ietf.org
>> https://www.ietf.org/= mailman/listinfo/savi
>>

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

------_=_NextPart_001_01C9C39E.20D14654-- From lint@h3c.com Wed Apr 22 18:01:56 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B83B33A67AE for ; Wed, 22 Apr 2009 18:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-xTLJ9ozQSu for ; Wed, 22 Apr 2009 18:01:55 -0700 (PDT) Received: from huawei-3com.com (unknown [60.191.123.56]) by core3.amsl.com (Postfix) with ESMTP id A58933A6878 for ; Wed, 22 Apr 2009 18:01:53 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KIJ00E9V4CDYB@h3cml02-in.huawei-3com.com> for savi@ietf.org; Thu, 23 Apr 2009 09:05:01 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.126]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KIJ006DB4CCFR@h3cml02-in.huawei-3com.com> for savi@ietf.org; Thu, 23 Apr 2009 09:05:01 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.57]) by smtp2.h3c.com with ESMTP; Thu, 23 Apr 2009 08:58:33 +0800 Date: Thu, 23 Apr 2009 09:03:09 +0800 From: Lin Tao To: Fred Baker Message-id: <001001c9c3af$44b14090$3911990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1a37331a288b.1a288b1a3733@huawei-3com.com> <003701c9c332$74e11920$1311990a@h3c.huawei3com.com> <0671D0A5-0BF8-491D-A2C6-91EB4D7BF93B@cisco.com> Cc: SAVI Mailing List Subject: Re: [savi] (no subject) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 01:01:56 -0000 Thank you very much! ----- Original Message ----- From: "Fred Baker" To: "Lin Tao" Cc: "SAVI Mailing List" Sent: Wednesday, April 22, 2009 7:30 PM Subject: Re: [savi] (no subject) >I would find using the same IP address on two interfaces highly > unusual in the IP architecture. SO, we needn't address it. > > On Apr 22, 2009, at 3:09 AM, Lin Tao wrote: > >> Thank you very much! I'm sorry so late. It's misconfiguration in the >> frist >> scenario, so that is not permitted in savi, isn't that? >> >> In the second scenario, the device connect the host must have >> multipath >> function. I think this is not in switch now, isn't that? >> >> So I think the same IP address on twon interfaces needn't be >> considered >> in savi. How do you think? >> >> Thanks. >> >> ----- Original Message ----- >> From: "Fred Baker" >> To: "lintao 00450" >> Cc: "SAVI Mailing List" >> Sent: Sunday, April 19, 2009 12:16 PM >> Subject: Re: [savi] (no subject) >> >> >>> I general, different interfaces get different addresses, since an IP >>> address (IPv4 or IPv6) is the address of an interface. >>> >>> I can think of two scenarios in which a system might use the same IP >>> address on two interfaces. One is, properly, a misconfiguration, but >>> probably would in fact work for most purposes. In that, the two >>> interfaces on on the same LAN and therefore use identical prefixes, >>> and one could imagine them being configured with the same address. >>> SLAAC should not result in a common address, though, due to DAD. The >>> other is a case in which an address is assigned to a virtual >>> interface >>> such as a loopback interface, and routing is told that both of the >>> interfaces are appropriate router-router paths to get to that >>> "remote" >>> address. In that case, the rules of multipath routing apply. >>> >>> On Apr 18, 2009, at 12:25 PM, lintao 00450 wrote: >>> >>>> Hi, all >>>> >>>> I'm puzzled by one ip address on multiple interface in the charter. >>>> I wish someone to clear it, thank you very much. >>>> >>>> If one host have multiple interface with on ip address, and they >>>> connect to one switch, how should the switch forward the >>>> >>>> back packet to the host? Which port is the right back port? >>>> >>>> +------------------------+ >>>> + SWITCH + >>>> + + >>>> +----+---+---+---+-------+ >>>> | | >>>> +----+---+--------+ >>>> + HOST + >>>> + + >>>> +-----------------+ >>>> >>>> Anycast shouldn't be the source address of the parcket from the >>>> host, and I haven't seen the usage of anycast in this >>>> >>>> condition. If it's used in load balancing in server farm, there >>>> haven't savi requirement. >>>> >>>> I think this isn't the important factor is savi. How does anyone >>>> think about it? >>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From lint@h3c.com Wed Apr 22 18:14:29 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2733A6ABF for ; Wed, 22 Apr 2009 18:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.817 X-Spam-Level: ** X-Spam-Status: No, score=2.817 tagged_above=-999 required=5 tests=[AWL=1.091, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL0cx1khy3ve for ; Wed, 22 Apr 2009 18:14:28 -0700 (PDT) Received: from huawei-3com.com (unknown [221.12.31.13]) by core3.amsl.com (Postfix) with ESMTP id 8D8213A6810 for ; Wed, 22 Apr 2009 18:14:27 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KIJ00EG14XBYB@h3cml02-in.huawei-3com.com> for savi@ietf.org; Thu, 23 Apr 2009 09:17:35 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.126]) by h3cml02-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KIJ0073N4XBCN@h3cml02-in.huawei-3com.com> for savi@ietf.org; Thu, 23 Apr 2009 09:17:35 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.57]) by smtp2.h3c.com with ESMTP; Thu, 23 Apr 2009 09:11:07 +0800 Date: Thu, 23 Apr 2009 09:15:43 +0800 From: Lin Tao To: Greg Daley , Fred Baker Message-id: <001b01c9c3b1$064c2110$3911990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1a37331a288b.1a288b1a3733@huawei-3com.com> <003701c9c332$74e11920$1311990a@h3c.huawei3com.com> <0671D0A5-0BF8-491D-A2C6-91EB4D7BF93B@cisco.com> <6983BF97BFC24D4EA551F140712329181FA770@melmail.netstarnetworks.com> Cc: SAVI Mailing List Subject: Re: [savi] Same IP, two interfaces (maybe not at same time) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 01:14:29 -0000 I think the HSRP/VRRP/Clustering addresses wouldn't used in savi scenario. These addresses are public-known and serve the users, so they must configured specially. For example, they will be configured in special port on switch. Is this correct? ----- Original Message ----- From: "Greg Daley" To: "Fred Baker" ; "Lin Tao" Cc: "SAVI Mailing List" Sent: Thursday, April 23, 2009 6:59 AM Subject: Same IP, two interfaces (maybe not at same time) Hi Fred, Do we have a way of handling the HSRP/VRRP/Clustering of addresses? Greg -----Original Message----- From: savi-bounces@ietf.org on behalf of Fred Baker Sent: Wed 4/22/2009 9:30 PM To: Lin Tao Cc: SAVI Mailing List Subject: Re: [savi] (no subject) I would find using the same IP address on two interfaces highly unusual in the IP architecture. SO, we needn't address it. On Apr 22, 2009, at 3:09 AM, Lin Tao wrote: > Thank you very much! I'm sorry so late. It's misconfiguration in the > frist > scenario, so that is not permitted in savi, isn't that? > > In the second scenario, the device connect the host must have > multipath > function. I think this is not in switch now, isn't that? > > So I think the same IP address on twon interfaces needn't be > considered > in savi. How do you think? > > Thanks. > > ----- Original Message ----- > From: "Fred Baker" > To: "lintao 00450" > Cc: "SAVI Mailing List" > Sent: Sunday, April 19, 2009 12:16 PM > Subject: Re: [savi] (no subject) > > >> I general, different interfaces get different addresses, since an IP >> address (IPv4 or IPv6) is the address of an interface. >> >> I can think of two scenarios in which a system might use the same IP >> address on two interfaces. One is, properly, a misconfiguration, but >> probably would in fact work for most purposes. In that, the two >> interfaces on on the same LAN and therefore use identical prefixes, >> and one could imagine them being configured with the same address. >> SLAAC should not result in a common address, though, due to DAD. The >> other is a case in which an address is assigned to a virtual >> interface >> such as a loopback interface, and routing is told that both of the >> interfaces are appropriate router-router paths to get to that >> "remote" >> address. In that case, the rules of multipath routing apply. >> >> On Apr 18, 2009, at 12:25 PM, lintao 00450 wrote: >> >>> Hi, all >>> >>> I'm puzzled by one ip address on multiple interface in the charter. >>> I wish someone to clear it, thank you very much. >>> >>> If one host have multiple interface with on ip address, and they >>> connect to one switch, how should the switch forward the >>> >>> back packet to the host? Which port is the right back port? >>> >>> +------------------------+ >>> + SWITCH + >>> + + >>> +----+---+---+---+-------+ >>> | | >>> +----+---+--------+ >>> + HOST + >>> + + >>> +-----------------+ >>> >>> Anycast shouldn't be the source address of the parcket from the >>> host, and I haven't seen the usage of anycast in this >>> >>> condition. If it's used in load balancing in server farm, there >>> haven't savi requirement. >>> >>> I think this isn't the important factor is savi. How does anyone >>> think about it? >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From fred@cisco.com Wed Apr 22 18:46:08 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 138C83A69EA for ; Wed, 22 Apr 2009 18:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.48 X-Spam-Level: X-Spam-Status: No, score=-106.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG-2wWFMeano for ; Wed, 22 Apr 2009 18:46:07 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 86D5F3A67C0 for ; Wed, 22 Apr 2009 18:45:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,233,1238976000"; d="scan'208,217";a="155973137" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 23 Apr 2009 01:46:55 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3N1ktGW022122; Wed, 22 Apr 2009 18:46:55 -0700 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3N1ksrt023416; Thu, 23 Apr 2009 01:46:55 GMT Message-Id: From: Fred Baker To: "Greg Daley" In-Reply-To: <6983BF97BFC24D4EA551F140712329181FA770@melmail.netstarnetworks.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1-151009858 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 18:46:54 -0700 References: <1a37331a288b.1a288b1a3733@huawei-3com.com><003701c9c332$74e11920$1311990a@h3c.huawei3com.com> <0671D0A5-0BF8-491D-A2C6-91EB4D7BF93B@cisco.com> <6983BF97BFC24D4EA551F140712329181FA770@melmail.netstarnetworks.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1947; t=1240451215; x=1241315215; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Same=20IP,=20two=20interfaces=20(maybe= 20not=20at=20same=20time) |Sender:=20; bh=UJARPE1OLX0uLNGJbXMiTPkHdVILz5nRqmQ6qoqmjbI=; b=aqdHhaA4ZgybBJCWfUb1Yjygk1AQ5743L1GdV3cHGKgV4Bym95gx5Mx79Y TZ52BNyPZurARjtB/GTN+EsOY+hyvuTdH++XDneVgZkyMjHM8pfmwnm0IuM/ yY7A/9ErRpo4jnpS0PVcVaiOSuCpVtMZEgVRRyldqaGwk9oJ+Dpms=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: Lin Tao , SAVI Mailing List Subject: Re: [savi] Same IP, two interfaces (maybe not at same time) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 01:46:08 -0000 --Apple-Mail-1-151009858 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Apr 22, 2009, at 3:59 PM, Greg Daley wrote: > Do we have a way of handling the HSRP/VRRP/Clustering of addresses? Cisco IP Source Guard marks the interfaces as "unprotected", because they are router interfaces and therefore send datagrams (from a layer 2 perspective) that contain source addresses that are not theirs. I would suggest the same approach in SAVI. --Apple-Mail-1-151009858 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Apr 22, 2009, = at 3:59 PM, Greg Daley wrote:

Do we have a way of handling the = HSRP/VRRP/Clustering of = addresses?

Cisco IP Source = Guard marks the interfaces as "unprotected", because they are router = interfaces and therefore send datagrams (from a layer 2 perspective) = that contain source addresses that are not theirs.  I = would suggest the same approach in SAVI.
= --Apple-Mail-1-151009858-- From christian.vogt@ericsson.com Wed Apr 22 19:41:10 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C6823A70ED for ; Wed, 22 Apr 2009 19:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEfyPS1Wej50 for ; Wed, 22 Apr 2009 19:41:09 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 55E023A6CA7 for ; Wed, 22 Apr 2009 19:40:44 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n3N2pQVe021727; Wed, 22 Apr 2009 21:51:26 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 21:41:59 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 21:41:59 -0500 Message-Id: From: Christian Vogt To: Dave Thaler In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 19:41:59 -0700 References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> <4D15419B07B64EADAB02FDB506338123@userPC> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Apr 2009 02:41:59.0404 (UTC) FILETIME=[13229AC0:01C9C3BD] Cc: SAVI Mailing List Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 02:41:10 -0000 On Apr 13, 2009, Dave Thaler wrote: > If (1) had no disadvantages then why would anyone vote for (2)? There > must be something (e.g. complexity of solution). This is exactly right, Dave. Requiring SAVI devices to work correctly despite being mixed with legacy switches might make the solution more complex. Unfortunately, we don't know yet how much more complex it would get. But this voting was suggested during the SAVI session to get a better feeling of how important folks consider the ability to mix SAVI devices with legacy switches. - Christian From christian.vogt@ericsson.com Wed Apr 22 19:42:50 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDF73A6A5E for ; Wed, 22 Apr 2009 19:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uSFMefQklxz for ; Wed, 22 Apr 2009 19:42:49 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id D45E03A69AF for ; Wed, 22 Apr 2009 19:42:49 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n3N2i6rO007185; Wed, 22 Apr 2009 21:44:06 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 21:44:05 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 21:44:05 -0500 Message-Id: From: Christian Vogt To: Fred Baker In-Reply-To: <98FDC3D5-235C-4564-9E1E-99D4CA9B94F7@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 19:44:06 -0700 References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> <4D15419B07B64EADAB02FDB506338123@userPC> <98FDC3D5-235C-4564-9E1E-99D4CA9B94F7@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Apr 2009 02:44:05.0685 (UTC) FILETIME=[5E678E50:01C9C3BD] Cc: SAVI Mailing List Subject: Re: [savi] Your Vote: Incremental SAVI Deployment X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 02:42:50 -0000 On Apr 13, 2009, Fred Baker wrote: > The real question here relates to the address distribution protocol > that > Christian is pushing. For the record: I am not pushing for a binding distribution protocol. There was significant agreement during the SAVI meeting in San Francisco that we should first analyze the need for such a protocol before we consider designing one. And this is the approach we should follow. - Christian From christian.vogt@ericsson.com Wed Apr 22 21:38:31 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C873A6CAF for ; Wed, 22 Apr 2009 21:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SlpDQp-ANH8 for ; Wed, 22 Apr 2009 21:38:30 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id CE3A23A6C97 for ; Wed, 22 Apr 2009 21:38:30 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n3N4n0lN008280; Wed, 22 Apr 2009 23:49:07 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 23:39:33 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 23:39:32 -0500 From: Christian Vogt To: Jun Bi In-Reply-To: X-Priority: 3 References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> <8439113D7A9F46799815AB8AD2480869@userPC> <49E6278F.3010603@it.uc3m.es> Message-Id: <2AB6E4C9-DEED-4D07-A7B0-B029D626D4FE@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 21:39:33 -0700 X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 23 Apr 2009 04:39:32.0818 (UTC) FILETIME=[7F4C2B20:01C9C3CD] Cc: Guang Yao , 'SAVI Mailing List' , 'Greg Daley' , 'Suresh Krishnan' Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 04:38:32 -0000 On Apr 15, 2009, Jun Bi wrote: > Certainly, the major problem of SAVI-FCFS is not only the first packet > lost. Even the first packet is not lost, FCFS still need a BDP, and it > might be complex when we have multiple SAVI-swtiches (the real-time > sync > requirements), we even didn't see a prototype of BDP yet. But SAVI-CPS > doesn't need the BDP, just need some enhancement. Jun and all - When comparing FCFS and SAVI-CPS, we should be careful not to mix DHCP-based and SLAAC-based address configuration. It is true that SAVI-CPS, or control-packet-only snooping in general, may not need a BDP in the case of DHCP-assigned addresses. Thanks to the acknowledged address assignment exchange, the lack of an address binding in a SAVI device then implies with high reliability that packets locally originating from this address should be dropped. But in the case of addresses auto-configured via SLAAC, snooping only control packets doesn't have the same effect. Since there is no acknowledged address assignment exchange, the lack of an address binding in a SAVI device does NOT imply that packets locally originating from this address should be dropped. I.e., the best a SAVI device can do in this case is let such packets through. And the scenario that Marcelo had illustrated earlier shows that this may lead to a vulnerability. Hence, control-packet-only snooping in SLAAC could in some cases benefit from a BDP, independent of whether you use FCFS or SAVI-CPS. So the issue with SLAAC-based address configuration is the same whether we use FCFS or SAVI-CPS -- independent of whether we believe that this issue justifies the development of a BDP. - Christian From marcelo@it.uc3m.es Thu Apr 23 00:43:53 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8D1D28C6AD for ; Thu, 23 Apr 2009 00:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.079 X-Spam-Level: X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3wAHwuShBZ9 for ; Thu, 23 Apr 2009 00:43:52 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 96CB93A6A1D for ; Thu, 23 Apr 2009 00:43:52 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (115.pool85-53-139.dynamic.orange.es [85.53.139.115]) by smtp02.uc3m.es (Postfix) with ESMTP id BB1F06BA947; Thu, 23 Apr 2009 09:45:07 +0200 (CEST) Message-ID: <49F01C83.3010209@it.uc3m.es> Date: Thu, 23 Apr 2009 09:45:07 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Christian Vogt References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> <8439113D7A9F46799815AB8AD2480869@userPC> <49E6278F.3010603@it.uc3m.es> <2AB6E4C9-DEED-4D07-A7B0-B029D626D4FE@ericsson.com> In-Reply-To: <2AB6E4C9-DEED-4D07-A7B0-B029D626D4FE@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16598.005 Cc: 'SAVI Mailing List' Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 07:43:53 -0000 Christian Vogt escribi: > On Apr 15, 2009, Jun Bi wrote: > >> Certainly, the major problem of SAVI-FCFS is not only the first packet >> lost. Even the first packet is not lost, FCFS still need a BDP, and it >> might be complex when we have multiple SAVI-swtiches (the real-time sync >> requirements), we even didn't see a prototype of BDP yet. But SAVI-CPS >> doesn't need the BDP, just need some enhancement. > > > Jun and all - > > When comparing FCFS and SAVI-CPS, we should be careful not to mix > DHCP-based and SLAAC-based address configuration. > > It is true that SAVI-CPS, or control-packet-only snooping in general, > may not need a BDP in the case of DHCP-assigned addresses. Thanks to > the acknowledged address assignment exchange, the lack of an address > binding in a SAVI device then implies with high reliability that packets > locally originating from this address should be dropped. Right > > But in the case of addresses auto-configured via SLAAC, snooping only > control packets doesn't have the same effect. Since there is no > acknowledged address assignment exchange, the lack of an address binding > in a SAVI device does NOT imply that packets locally originating from > this address should be dropped. I.e., the best a SAVI device can do in > this case is let such packets through. And the scenario that Marcelo > had illustrated earlier shows that this may lead to a vulnerability. > Hence, control-packet-only snooping in SLAAC could in some cases > benefit from a BDP, independent of whether you use FCFS or SAVI-CPS. > In addition to that, there is the impact of failures. Consider the following scenario that i have presented in a previous email: +-------+ | HOST | +-------+ | +------------------+ | LEGACY SWITCH | +------------------+ | +------------------+ | SAVI CPS DEVICE | +------------------+ | +----------------+ | REST of WORLD | +----------------+ I understand this can be a very common configuration, for instance when the SAVI function is located in the router rahter than in the switch(this seems to be the topology the broadband forum is looking into), or when you are having an incremental deployment of SAVI and you have upgraded some switches and not others Suppose that the HOST boots and perform DAD. The savi cps device creates state everything is working fine SAVI CPS device is rebooted (happens all the time at home for instance) Now the SAVI CPS Data base is deleted and SAVI CPS starts dropping packets from HOST, since HOST will not perform the DAD again > So the issue with SLAAC-based address configuration is the same whether > we use FCFS or SAVI-CPS -- independent of whether we believe that this > issue justifies the development of a BDP. > > - Christian > > > > From marcelo@it.uc3m.es Thu Apr 23 00:47:10 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C9883A6A78 for ; Thu, 23 Apr 2009 00:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=-3.597, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9K2M4VxKvbt for ; Thu, 23 Apr 2009 00:47:09 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 77D4E3A71D1 for ; Thu, 23 Apr 2009 00:46:47 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (115.pool85-53-139.dynamic.orange.es [85.53.139.115]) by smtp02.uc3m.es (Postfix) with ESMTP id 4B6806BADAB; Thu, 23 Apr 2009 09:48:03 +0200 (CEST) Message-ID: <49F01D33.8020304@it.uc3m.es> Date: Thu, 23 Apr 2009 09:48:03 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: ZhangDong References: <93B60BBA-CF5C-49EB-BFF1-B87A3879F78C@ericsson.com> <4D15419B07B64EADAB02FDB506338123@userPC> <98FDC3D5-235C-4564-9E1E-99D4CA9B94F7@cisco.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16598.005 Cc: SAVI Mailing List , Christian Vogt Subject: Re: [savi] =?gb2312?b?KioqU1BBTSoqKiA1LjAxNSAoNSkgu9i4tDogUmU6ICBZ?= =?gb2312?b?b3VyIFZvdGU6IEluY3JlbWVudGFsIFNBVkkgRGVwbG95bWVudA==?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 07:47:10 -0000 ZhangDong escribió: >> that we should first analyze the need for such a protocol before we >> consider designing one. And this is the approach we should follow. >> > > IMHO, an analysis is the premise before we make any decision. I mean the exact analysis decides the direction of the work. > > According to the discussion in the ml before, I summarize a scenario. I gusess the it cover the common cases. > The legend of the figure is: > REST--rest part of network > S--savi switch > L--legacy switch > H--host > The savi device may need to handle with three kinds of relationship: > a. between S1 and S2 > b. between S3 and L2 (problem of incremental savi deployment) > c. between S4 and S5 (problem of the multi-savi-device Links) > > -------------- > | REST | > -------------- > / \ > ----- ----- > | S1 | | L1 | > ----- ----- > / | \ / | \ > ---- ---- ---- ---- ---- ---- > |S2 | |S3 | | L2 | |S4 | |S5 | | L3 | > ---- ---- ---- ---- ---- ---- > / \ / \ / \ / \ / \ / \ > Ha Hb Hc Hd He Hf Hg Hh Hi Hj Hk Hl > > Am i missing something? > i think what we need to define here, is what protection is expected for each source address involved regards, marcelo > Thanks > > Dong Zhang > > > ----- 原始邮件 ----- > 发件人: Christian Vogt > 日期: 2009年 4月 23日, 星期四, 上午10:44 > 主题: Re: [savi] Your Vote: Incremental SAVI Deployment > 收件人: Fred Baker > 抄送: SAVI Mailing List > > > >> On Apr 13, 2009, Fred Baker wrote: >> >> > The real question here relates to the address distribution protocol >> >> > that >> > Christian is pushing. >> >> For the record: I am not pushing for a binding distribution protocol. >> There was significant agreement during the SAVI meeting in San Francisco >> that we should first analyze the need for such a protocol before we >> consider designing one. And this is the approach we should follow. >> >> - Christian >> >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From dthaler@windows.microsoft.com Thu Apr 23 07:58:42 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821A13A6DC2 for ; Thu, 23 Apr 2009 07:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.507 X-Spam-Level: X-Spam-Status: No, score=-110.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47OYqttho2-9 for ; Thu, 23 Apr 2009 07:58:41 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 8615B28C292 for ; Thu, 23 Apr 2009 07:57:10 -0700 (PDT) Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.99.4; Thu, 23 Apr 2009 07:58:28 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) with Microsoft SMTP Server id 8.2.99.4; Thu, 23 Apr 2009 07:58:27 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Thu, 23 Apr 2009 08:00:30 -0700 From: Dave Thaler To: Lin Tao , Fred Baker Date: Thu, 23 Apr 2009 08:00:29 -0700 Thread-Topic: [savi] (no subject) Thread-Index: AcnDr6mq52VDwDY8SIasIvamj2AK0wAcloTg Message-ID: References: <1a37331a288b.1a288b1a3733@huawei-3com.com> <003701c9c332$74e11920$1311990a@h3c.huawei3com.com> <0671D0A5-0BF8-491D-A2C6-91EB4D7BF93B@cisco.com> <001001c9c3af$44b14090$3911990a@h3c.huawei3com.com> In-Reply-To: <001001c9c3af$44b14090$3911990a@h3c.huawei3com.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SAVI Mailing List Subject: Re: [savi] (no subject) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 14:58:42 -0000 >From RFC 4291: > 2. IPv6 Addressing > > IPv6 addresses are 128-bit identifiers for interfaces and sets of > interfaces (where "interface" is as defined in Section 2 of [IPV6]). > There are three types of addresses: > > Unicast: An identifier for a single interface. A packet sent to a ^^^^^^ > unicast address is delivered to the interface identified > by that address. > > Anycast: An identifier for a set of interfaces (typically ^^^^^^^^ ^^^^^^^^^ > belonging to different nodes). A packet sent to an > anycast address is delivered to one of the interfaces > identified by that address (the "nearest" one, according > to the routing protocols' measure of distance). > > Multicast: An identifier for a set of interfaces (typically > belonging to different nodes). A packet sent to a > multicast address is delivered to all interfaces > identified by that address. So in the IP architecture, the same IP address on two interface is possibly (only) for an anycast address (for which you don't do DAD), but not for a unicast address. And of course if you're using a single virtual interface in the second case, a unicast address is fine. -Dave > ----- Original Message ----- > From: "Fred Baker" > To: "Lin Tao" > Cc: "SAVI Mailing List" > Sent: Wednesday, April 22, 2009 7:30 PM > Subject: Re: [savi] (no subject) > > > >I would find using the same IP address on two interfaces highly > > unusual in the IP architecture. SO, we needn't address it. > > > > On Apr 22, 2009, at 3:09 AM, Lin Tao wrote: > > > >> Thank you very much! I'm sorry so late. It's misconfiguration in the > >> frist > >> scenario, so that is not permitted in savi, isn't that? > >> > >> In the second scenario, the device connect the host must have > >> multipath > >> function. I think this is not in switch now, isn't that? > >> > >> So I think the same IP address on twon interfaces needn't be > >> considered > >> in savi. How do you think? > >> > >> Thanks. > >> > >> ----- Original Message ----- > >> From: "Fred Baker" > >> To: "lintao 00450" > >> Cc: "SAVI Mailing List" > >> Sent: Sunday, April 19, 2009 12:16 PM > >> Subject: Re: [savi] (no subject) > >> > >> > >>> I general, different interfaces get different addresses, since an > IP > >>> address (IPv4 or IPv6) is the address of an interface. > >>> > >>> I can think of two scenarios in which a system might use the same > IP > >>> address on two interfaces. One is, properly, a misconfiguration, > but > >>> probably would in fact work for most purposes. In that, the two > >>> interfaces on on the same LAN and therefore use identical prefixes, > >>> and one could imagine them being configured with the same address. > >>> SLAAC should not result in a common address, though, due to DAD. > The > >>> other is a case in which an address is assigned to a virtual > >>> interface > >>> such as a loopback interface, and routing is told that both of the > >>> interfaces are appropriate router-router paths to get to that > >>> "remote" > >>> address. In that case, the rules of multipath routing apply. > >>> > >>> On Apr 18, 2009, at 12:25 PM, lintao 00450 wrote: > >>> > >>>> Hi, all > >>>> > >>>> I'm puzzled by one ip address on multiple interface in the > charter. > >>>> I wish someone to clear it, thank you very much. > >>>> > >>>> If one host have multiple interface with on ip address, and they > >>>> connect to one switch, how should the switch forward the > >>>> > >>>> back packet to the host? Which port is the right back port? > >>>> > >>>> +------------------------+ > >>>> + SWITCH + > >>>> + + > >>>> +----+---+---+---+-------+ > >>>> | | > >>>> +----+---+--------+ > >>>> + HOST + > >>>> + + > >>>> +-----------------+ > >>>> > >>>> Anycast shouldn't be the source address of the parcket from the > >>>> host, and I haven't seen the usage of anycast in this > >>>> > >>>> condition. If it's used in load balancing in server farm, there > >>>> haven't savi requirement. > >>>> > >>>> I think this isn't the important factor is savi. How does anyone > >>>> think about it? > >>>> > >>>> _______________________________________________ > >>>> savi mailing list > >>>> savi@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/savi > >>> > >>> _______________________________________________ > >>> savi mailing list > >>> savi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/savi > >>> > > > > _______________________________________________ > > savi mailing list > > savi@ietf.org > > https://www.ietf.org/mailman/listinfo/savi > > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From christian.vogt@ericsson.com Thu Apr 23 09:22:11 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F663A72B7 for ; Thu, 23 Apr 2009 09:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVX0rGnsnNLh for ; Thu, 23 Apr 2009 09:22:10 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by core3.amsl.com (Postfix) with ESMTP id AAE0B3A7242 for ; Thu, 23 Apr 2009 09:22:10 -0700 (PDT) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 3B8EE31FEC5; Thu, 23 Apr 2009 12:23:28 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 23 Apr 2009 12:23:28 -0400 X-Sasl-enc: FmKaJ0BWYe3Ws84AyxMUpEeMJLOMd/tKyrO3NHkB/Thi 1240503807 Received: from [10.193.10.121] (71-6-86-42.static-ip.telepacific.net [71.6.86.42]) by mail.messagingengine.com (Postfix) with ESMTPSA id 9CB003E99E; Thu, 23 Apr 2009 12:23:27 -0400 (EDT) Message-Id: <5961A549-1F55-4911-A99D-3A96C09E6850@ericsson.com> From: Christian Vogt To: marcelo bagnulo braun In-Reply-To: <49F01C83.3010209@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 23 Apr 2009 09:23:25 -0700 References: <49E5DB3C.5020806@it.uc3m.es><004d01c9bdce$83ae4a40$8b0adec0$@tsinghua.edu.cn><49E5E813.30204@it.uc3m.es><942B2D1A792F43DAAB3662B5E59FD727@userPC> <49E61BCC.70806@it.uc3m.es> <8439113D7A9F46799815AB8AD2480869@userPC> <49E6278F.3010603@it.uc3m.es> <2AB6E4C9-DEED-4D07-A7B0-B029D626D4FE@ericsson.com> <49F01C83.3010209@it.uc3m.es> X-Mailer: Apple Mail (2.930.3) Cc: 'SAVI Mailing List' Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 16:22:11 -0000 On Apr 23, 2009, marcelo bagnulo braun wrote: > Suppose that the HOST boots and perform DAD. The savi cps device > creates > state everything is working fine SAVI CPS device is rebooted (happens > all the time at home for instance) > > Now the SAVI CPS Data base is deleted and SAVI CPS starts dropping > packets from HOST, since HOST will not perform the DAD again Yes, this is an issue. It might be worthwhile to check if the Multicast Listener Discovery protocol can be used by a rebooting SAVI device to rebuild its previous state. We might find MLD General Queries useful for this purpose. - Christian From lint@h3c.com Thu Apr 23 18:10:00 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A66833A7299 for ; Thu, 23 Apr 2009 18:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.454 X-Spam-Level: ** X-Spam-Status: No, score=2.454 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, RELAY_IS_221=2.222] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMD7D7BNqvmA for ; Thu, 23 Apr 2009 18:09:59 -0700 (PDT) Received: from huawei-3com.com (unknown [221.12.31.56]) by core3.amsl.com (Postfix) with ESMTP id 5A0403A6EED for ; Thu, 23 Apr 2009 18:09:57 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KIK00MWYYWI8L@h3cml01-in.huawei-3com.com> for savi@ietf.org; Fri, 24 Apr 2009 09:02:42 +0800 (CST) Received: from mailsecurity.h3c.com ([172.25.12.126]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KIK0073UYWITL@h3cml01-in.huawei-3com.com> for savi@ietf.org; Fri, 24 Apr 2009 09:02:42 +0800 (CST) Received: from unknown (HELO l00450a) ([10.153.17.19]) by smtp2.h3c.com with ESMTP; Fri, 24 Apr 2009 08:58:05 +0800 Date: Fri, 24 Apr 2009 09:02:41 +0800 From: Lin Tao To: Dave Thaler , Fred Baker Message-id: <007e01c9c478$5ebb42a0$1311990a@h3c.huawei3com.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <1a37331a288b.1a288b1a3733@huawei-3com.com> <003701c9c332$74e11920$1311990a@h3c.huawei3com.com> <0671D0A5-0BF8-491D-A2C6-91EB4D7BF93B@cisco.com> <001001c9c3af$44b14090$3911990a@h3c.huawei3com.com> Cc: SAVI Mailing List Subject: Re: [savi] (no subject) X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 01:10:00 -0000 Thank you very much! ----- Original Message ----- From: "Dave Thaler" To: "Lin Tao" ; "Fred Baker" Cc: "SAVI Mailing List" Sent: Thursday, April 23, 2009 11:00 PM Subject: Re: [savi] (no subject) > From RFC 4291: > >> 2. IPv6 Addressing >> >> IPv6 addresses are 128-bit identifiers for interfaces and sets of >> interfaces (where "interface" is as defined in Section 2 of [IPV6]). >> There are three types of addresses: >> >> Unicast: An identifier for a single interface. A packet sent to a > ^^^^^^ >> unicast address is delivered to the interface identified >> by that address. >> >> Anycast: An identifier for a set of interfaces (typically > ^^^^^^^^ ^^^^^^^^^ >> belonging to different nodes). A packet sent to an >> anycast address is delivered to one of the interfaces >> identified by that address (the "nearest" one, according >> to the routing protocols' measure of distance). >> >> Multicast: An identifier for a set of interfaces (typically >> belonging to different nodes). A packet sent to a >> multicast address is delivered to all interfaces >> identified by that address. > > So in the IP architecture, the same IP address on two interface > is possibly (only) for an anycast address (for which you don't do DAD), > but not for a unicast address. > > And of course if you're using a single virtual interface in the > second case, a unicast address is fine. > > -Dave > >> ----- Original Message ----- >> From: "Fred Baker" >> To: "Lin Tao" >> Cc: "SAVI Mailing List" >> Sent: Wednesday, April 22, 2009 7:30 PM >> Subject: Re: [savi] (no subject) >> >> >> >I would find using the same IP address on two interfaces highly >> > unusual in the IP architecture. SO, we needn't address it. >> > >> > On Apr 22, 2009, at 3:09 AM, Lin Tao wrote: >> > >> >> Thank you very much! I'm sorry so late. It's misconfiguration in the >> >> frist >> >> scenario, so that is not permitted in savi, isn't that? >> >> >> >> In the second scenario, the device connect the host must have >> >> multipath >> >> function. I think this is not in switch now, isn't that? >> >> >> >> So I think the same IP address on twon interfaces needn't be >> >> considered >> >> in savi. How do you think? >> >> >> >> Thanks. >> >> >> >> ----- Original Message ----- >> >> From: "Fred Baker" >> >> To: "lintao 00450" >> >> Cc: "SAVI Mailing List" >> >> Sent: Sunday, April 19, 2009 12:16 PM >> >> Subject: Re: [savi] (no subject) >> >> >> >> >> >>> I general, different interfaces get different addresses, since an >> IP >> >>> address (IPv4 or IPv6) is the address of an interface. >> >>> >> >>> I can think of two scenarios in which a system might use the same >> IP >> >>> address on two interfaces. One is, properly, a misconfiguration, >> but >> >>> probably would in fact work for most purposes. In that, the two >> >>> interfaces on on the same LAN and therefore use identical prefixes, >> >>> and one could imagine them being configured with the same address. >> >>> SLAAC should not result in a common address, though, due to DAD. >> The >> >>> other is a case in which an address is assigned to a virtual >> >>> interface >> >>> such as a loopback interface, and routing is told that both of the >> >>> interfaces are appropriate router-router paths to get to that >> >>> "remote" >> >>> address. In that case, the rules of multipath routing apply. >> >>> >> >>> On Apr 18, 2009, at 12:25 PM, lintao 00450 wrote: >> >>> >> >>>> Hi, all >> >>>> >> >>>> I'm puzzled by one ip address on multiple interface in the >> charter. >> >>>> I wish someone to clear it, thank you very much. >> >>>> >> >>>> If one host have multiple interface with on ip address, and they >> >>>> connect to one switch, how should the switch forward the >> >>>> >> >>>> back packet to the host? Which port is the right back port? >> >>>> >> >>>> +------------------------+ >> >>>> + SWITCH + >> >>>> + + >> >>>> +----+---+---+---+-------+ >> >>>> | | >> >>>> +----+---+--------+ >> >>>> + HOST + >> >>>> + + >> >>>> +-----------------+ >> >>>> >> >>>> Anycast shouldn't be the source address of the parcket from the >> >>>> host, and I haven't seen the usage of anycast in this >> >>>> >> >>>> condition. If it's used in load balancing in server farm, there >> >>>> haven't savi requirement. >> >>>> >> >>>> I think this isn't the important factor is savi. How does anyone >> >>>> think about it? >> >>>> >> >>>> _______________________________________________ >> >>>> savi mailing list >> >>>> savi@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/savi >> >>> >> >>> _______________________________________________ >> >>> savi mailing list >> >>> savi@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/savi >> >>> >> > >> > _______________________________________________ >> > savi mailing list >> > savi@ietf.org >> > https://www.ietf.org/mailman/listinfo/savi >> > >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From christian.vogt@ericsson.com Thu Apr 23 20:37:51 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA173A69C4 for ; Thu, 23 Apr 2009 20:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y99KTONdrWf3 for ; Thu, 23 Apr 2009 20:37:50 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 698EA3A67F6 for ; Thu, 23 Apr 2009 20:37:50 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n3O3d1fr027764; Thu, 23 Apr 2009 22:39:02 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 22:38:50 -0500 Received: from [155.53.229.43] ([155.53.229.43]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Apr 2009 22:38:49 -0500 Message-Id: From: Christian Vogt To: Eric Levy-Abegnoli In-Reply-To: <49E5FE3B.9080607@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 23 Apr 2009 20:38:47 -0700 References: <49E5DB3C.5020806@it.uc3m.es> <49E5FE3B.9080607@cisco.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 24 Apr 2009 03:38:49.0799 (UTC) FILETIME=[2E4D5570:01C9C48E] Cc: SAVI Mailing List , Suresh Krishnan , Gregory Daley Subject: Re: [savi] DAD as a binding distribution protocol: why not X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 03:37:51 -0000 Eric - You have a very good point. Since we are changing switches anyway, changing also the way they forward Neighbor Solicitation messages for DAD should be feasible. This said, a disadvantage of a DAD-based binding distribution or verification protocol, if you use the Neighbor Solicitation messages, is that it becomes a push protocol. This has the issue that it may require a lot of state in SAVI devices. Fred explained several good reasons why this is problematic. - Christian On Apr 15, 2009, Eric Levy-Abegnoli wrote: > Marcelo, The function that would prevent SWITCHA to forward DAD > packets > to SWITCHB in this scenario is_not_dictated by RFC4862 or even RFC3810 > (MLD). The switches are L2 devices and not expected to limit the > multicast forwarding to L3-devices who have joined the group. In > theory, > DAD multicast should be forwarded to trunks, regardless of who joined. > If switches perm MLD snooping, there could be a problem, however > RFC4541 > is very cautious with regard to switch deciding not_to copy traffic > to a > port where no join was seen. It looks to me that in this scenario, for > switches doing mld snooping, it would not be un-reasonnable to have a > configuration option on SWITCHA to enable copy of multicast traffic on > its trunks regardless of snooped groups. SWITCHB could still decide > not > to deliver the traffic to any device if nobody joined the group. That > would enable DAD to be usable as a binding distribution protocol. Eric From yaoa02@mails.tsinghua.edu.cn Tue Apr 28 18:35:28 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65BB83A6CBF for ; Tue, 28 Apr 2009 18:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.384 X-Spam-Level: *** X-Spam-Status: No, score=3.384 tagged_above=-999 required=5 tests=[AWL=2.782, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ff0pq6+e+nXL for ; Tue, 28 Apr 2009 18:35:20 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.80]) by core3.amsl.com (Postfix) with ESMTP id DF9833A67EF for ; Tue, 28 Apr 2009 18:35:19 -0700 (PDT) Received: from tu132214.ip.tsinghua.edu.cn ([166.111.132.214] helo=netarchld5f663) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1Lyyio-0006Ww-2P; Wed, 29 Apr 2009 09:36:26 +0800 From: "Guang Yao" To: "'Christian Vogt'" , "'marcelo bagnulo braun'" , "'Jun Bi'" Date: Wed, 29 Apr 2009 09:36:20 +0800 Message-ID: <000001c9c86a$e5d993e0$b18cbba0$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C9C8AD.F3FCD3E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnIauTm7fiUY6AITayVEVXFMmaAUg== Content-Language: zh-cn Cc: 'SAVI Mailing List' Subject: [savi] About the failure situation mentioned by Marcelo X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 01:35:28 -0000 这是一封 MIME 格式的多部分邮件。 ------=_NextPart_000_0001_01C9C8AD.F3FCD3E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Christian and Marcelo, Sorry for my long absence from the discussion. I will try to present my opinions on recent topics: 1 The situation mentioned by Marcelo /* content from Marcelo's mail In addition to that, there is the impact of failures. Consider the following scenario that i have presented in a previous email: +-------+ | HOST | +-------+ | +------------------+ | LEGACY SWITCH | +------------------+ | +------------------+ | SAVI CPS DEVICE | +------------------+ | +----------------+ | REST of WORLD | +----------------+ I understand this can be a very common configuration, for instance when the SAVI function is located in the router rather than in the switch(this seems to be the topology the broadband forum is looking into), or when you are having an incremental deployment of SAVI and you have upgraded some switches and not others Suppose that the HOST boots and perform DAD. The savi cps device creates state everything is working fine SAVI CPS device is rebooted (happens all the time at home for instance) Now the SAVI CPS Data base is deleted and SAVI CPS starts dropping packets from HOST, since HOST will not perform the DAD again */ The point of Marcelo is that the SAVI device may reboot and the binding states are lost, which makes the SAVI device drops packets incorrectly. This is good start point to discuss which hosts are to be administrated by SAVI device. As I mentioned in some previous mails, the only unspoofable anchors are 1 exclusive switch port, 2 secure MAC address in 802.1ae/af and 802.11i. Unfortunately, they are only valid for directly attached hosts. This means, if a host is not directly attached to SAVI device, its anchor is spoofable and doesn't necessarily represent the host itself. If we can find other anchors that can work on a device not directly connected, things will be different. However, there isn't another "strict secure" anchor satisfying this requirement currently. Thus we have two directions here: 1 bindings are only set up for directly attached hosts, and the binding entries are used to "deny" the traffic from the legacy-SAVI port.(class A) Then the situation mentioned by Marcelo can be handled. The SAVI device doesn't have to set up bindings based on the traffic from legacy switch and the traffic from legacy switch will not be filtered incorrectly. This solution has an advantage that the directly attached host can be bound tightly with strong anchor. The disadvantage of this solution is that the SAVI device must distinguish SAVI-Legacy port and SAVI-Host port. Currently manual configuration is the most proper mechanism, which bring administration cost. 2 bindings are also set up for remote hosts without differences with directly attached hosts.(class B) Because of the situation mentioned by Marcelo above, SAVI device cannot rely on control packets only, and must use auxiliary protocols, e.g., BDP or MLD. In this direction, the SAVI device doesn't have to distinguish SAVI-Legacy port and SAVI-Host port. And the packets from the SAVI-Legacy port are filtered based on "allow" rules. However, I will try to make out two points here: (a) Set up bindings for remote hosts will not provide stronger security than using bindings from adjacent hosts to "deny" packets from remote hosts For a class B device, there are only two kinds of addresses: bound addresses and unbound addresses. Whenever an address appears from a SAVI-Legacy port, and it has been bound on other ports, this packet will be dropped by both class A and class B device. Whenever a new address appears from a SAVI-Legacy port, the class B SAVI cannot drop the packet but set up a new binding for the address, typically based on the principle "FCFS". However, FCFS actually means using existing bindings to "deny" packets from SAVI-Legacy port, which is used by class A. And neither class A nor class B devices can distinguish spoofing from unspoofing at the SAVI-Legacy port, for they share the same anchor. Thus, class A and class B actually have the same filtering ability, which means setting up bindings for remote hosts will not achieve better filtering ability. (b) Class A controls spoofing from adjacent hosts better. Whenever spoofing happens from adjacent hosts, class A device knows exactly who is spoofing. This is a good feature for management. However, class B device only knows spoofing happens, but it doesn't know whether the spoofing happens locally or remotely. And setting up bindings for remote hosts costs a lot of memory. Actually, the memory cost will be a big problem in a big network. Class B also needs additional protocol. Another point is, the feature of the traffic from SAVI-Legacy port is much different from that from SAVI-host port. Thus it is reasonable to distinguish different kinds of ports. The summary of above argument is, class A is better than class B, which means " bindings are only set up for directly attached hosts, and the binding entries are used to "deny" the traffic from the legacy-SAVI port." Best regards, Guang -- Guang Yao Network Research Center Tsinghua University Beijing, China ------=_NextPart_000_0001_01C9C8AD.F3FCD3E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Christian and = Marcelo,

 

Sorry for my long absence from = the discussion.

 

I will try to present my = opinions on recent topics:

 

1 The situation mentioned by = Marcelo

 

/* content from Marcelo’s = mail

 

In addition to that, there is = the impact of failures.

 

Consider the following = scenario that i have presented in a previous email:

 

+-------+

|  HOST = |

+-------+

    = |

+------------------+

|    LEGACY = SWITCH |

+------------------+

    = |

+------------------+

|  SAVI CPS DEVICE = |

+------------------+

    = |

+----------------+

|  REST of WORLD = |

+----------------+

 

I understand this can be a = very common configuration, for instance when the SAVI function is located in the = router rather than in the switch(this seems to be the topology the broadband forum is = looking into), or when you are having an incremental deployment of SAVI and you = have upgraded some switches and not others

 

Suppose that the HOST boots = and perform DAD.

The savi cps device creates = state

everything is working = fine

SAVI CPS device is rebooted = (happens all the time at home for instance)

 

Now the SAVI CPS Data base is = deleted and SAVI CPS starts dropping packets from HOST, since HOST will not perform = the DAD again

 

*/

 

The point of Marcelo is that the = SAVI device may reboot and the binding states are lost, which makes the SAVI = device drops packets incorrectly.

 

This is good start point to = discuss which hosts are to be administrated by SAVI device.

 

As I mentioned in some previous = mails, the only unspoofable anchors are 1 exclusive switch port, 2 secure MAC = address in 802.1ae/af and 802.11i. Unfortunately, they are only valid for directly attached hosts. This means, if a host is not directly attached to SAVI = device, its anchor is spoofable and doesn’t necessarily represent the host itself.

If we can find other anchors = that can work on a device not directly connected, things will be different. However, = there isn’t another “strict secure” anchor satisfying this requirement currently.

Thus we have two directions = here:

 

1 = bindings are only set up for directly attached hosts, and the binding entries are = used to “deny” the traffic from the legacy-SAVI port.(class A)

         =

          =          Then the situation mentioned by Marcelo can be handled. The SAVI device doesn’t have to set up bindings based on the traffic from legacy = switch and the traffic from legacy switch will not be filtered = incorrectly.

          =          This solution has an advantage that the directly attached host can be bound = tightly with strong anchor.

          =          The disadvantage of this solution is that the SAVI device must distinguish SAVI-Legacy port and SAVI-Host port. Currently manual configuration is = the most proper mechanism, which bring administration cost.

         =

         2 bindings are also set up for remote hosts without differences with = directly attached hosts.(class B)

 

          =          Because of the situation mentioned by Marcelo above, SAVI device cannot rely on = control packets only, and must use auxiliary protocols, e.g., BDP or = MLD.

          =          In this direction, the SAVI device doesn’t have to distinguish = SAVI-Legacy port and SAVI-Host port. And the packets from the SAVI-Legacy port are = filtered based on “allow” rules.

 

          =          However, I will try to make out two points here:

(a)     Set up bindings for = remote hosts will not provide stronger security than using bindings from = adjacent hosts to “deny” packets from remote = hosts

 

For = a class B device, there are only two kinds of addresses: bound addresses and = unbound addresses.

Whenever an address appears from a SAVI-Legacy port, and it has been bound on other = ports, this packet will be dropped by both class A and class B = device.

 

Whenever a new address appears from a SAVI-Legacy port, the class B SAVI cannot drop = the packet but set up a new binding for the address, typically based on the principle “FCFS”.

However, FCFS actually means using existing bindings to = “deny” packets from SAVI-Legacy port, which is used by class = A.

 

And neither class A nor class B devices can distinguish = spoofing from unspoofing at the SAVI-Legacy port, for they share the same = anchor.

 

Thus, class A and class B actually have the same filtering = ability, which means setting up bindings for remote hosts will not achieve better filtering ability.

 

(b)     Class A controls = spoofing from adjacent hosts better.

Whenever spoofing happens from adjacent hosts, class A device knows exactly who = is spoofing. This is a good feature for management.

However, class B device only knows spoofing happens, but it doesn’t know whether = the spoofing happens locally or remotely.

 

And = setting up bindings for remote hosts costs a lot of memory. Actually, the memory = cost will be a big problem in a big network. Class B also needs additional = protocol.

 

Another point is, the feature of = the traffic from SAVI-Legacy port is much different from that from SAVI-host = port. Thus it is reasonable to distinguish different kinds of = ports.

 

The summary of above argument = is, class A is better than class B, which means “ bindings are only set up for directly attached hosts, and the binding entries are used to = “deny” the traffic from the legacy-SAVI port.”

 

Best = regards,

Guang

--

Guang Yao

Network Research = Center

Tsinghua = University

Beijing, = China

 

 

 

 

------=_NextPart_000_0001_01C9C8AD.F3FCD3E0-- From marcelo@it.uc3m.es Thu Apr 30 06:12:59 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C073A6B3D for ; Thu, 30 Apr 2009 06:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-3.879, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_83=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3tKZHS4wysA for ; Thu, 30 Apr 2009 06:12:55 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id F22053A6CEE for ; Thu, 30 Apr 2009 06:12:54 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (41.pool85-53-134.dynamic.orange.es [85.53.134.41]) by smtp01.uc3m.es (Postfix) with ESMTP id E5E7CBA4A7D; Thu, 30 Apr 2009 15:14:09 +0200 (CEST) Message-ID: <49F9A421.4080400@it.uc3m.es> Date: Thu, 30 Apr 2009 15:14:09 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <001101c9c874$23988750$6ac995f0$@tsinghua.edu.cn> In-Reply-To: <001101c9c874$23988750$6ac995f0$@tsinghua.edu.cn> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16612.005 Cc: 'SAVI Mailing List' Subject: Re: [savi] =?gb2312?b?KioqU1BBTSoqKiA2LjE4MSAoNSkg16q3ojogIERBRCBh?= =?gb2312?b?cyBhIGJpbmRpbmcgZGlzdHJpYnV0aW9uIHByb3RvY29sOiB3aHkgbm90?= X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:12:59 -0000 Guang, The problem is that the DAD procedure is inherently unreliable, so the NASOL msg can be lost and never get the SAVI device, These reasons include from simply errors in the packets, DAD being lost (for instance in dial on demand technologies, which are likely to discard the first packet, which is as you say the DAD packet) So, i fully agree with you that when there is a DAD packet, the SAVI device should use to create a binding. the problem is what if the DAD packet gets lost. By default disconnecting the host from the network, seems an overkill to me. Regards, marcelo Guang Yao escribió: > > Christian, > > I want to argue that, control packet snooping(DAD snooping) is both > sufficient and necessary to set up binding for SLAAC address. > > ->: > > Obviously. > > <-: > > RFC 4862 > > /* > > 5.4. Duplicate Address Detection > > Duplicate Address Detection _/MUST/_ be performed on all unicast > > addresses prior to assigning them to an interface, regardless of > > whether they are obtained through stateless autoconfiguration, > > DHCPv6, or manual configuration, with the following exceptions: > > - An interface whose DupAddrDetectTransmits variable is set to zero > > does not perform Duplicate Address Detection. > > - Duplicate Address Detection MUST NOT be performed on anycast > > addresses (note that anycast addresses cannot syntactically be > > distinguished from unicast addresses). > > - Each individual unicast address SHOULD be tested for uniqueness. > > Note that there are implementations deployed that only perform > > Duplicate Address Detection for the link-local address and skip > > the test for the global address that uses the same interface > > identifier as that of the link-local address. Whereas this > > document does not invalidate such implementations, this kind of > > "optimization" is NOT RECOMMENDED, and new implementations MUST > > NOT do that optimization. This optimization came from the > > assumption that all of an interface's addresses are generated from > > the same identifier. However, the assumption does actually not > > stand; new types of addresses have been introduced where the > > interface identifiers are not necessarily the same for all unicast > > addresses on a single interface [RFC4941] [RFC3972]. Requiring > > that Duplicate Address Detection be performed for all unicast > > addresses will make the algorithm robust for the current and > > future special interface identifiers. > > */ > > Note that this is a MUST. > > Although a host may not conform to this specification, DAD is still > needed. Before DAD, an address is suspicious to be used, in another > word, it may be spoofing. > > Even there is a BDP to sync all the devices, there may be addresses > not known by BDP, for example, hosts attached to legacy device, and > their packets go through no SAVI device. > > Thus, without DAD, the SAVI device cannot get known whether this > address has been used by other nodes. Only after a successful DAD, the > SAVI device has confident to set up a binding for that address; or > else, it may cause fallacious binding. > > And we can think that, when will a host send packets before DAD? > > It seems a DoS attacking scenario. > > Even it is not attacking, why does it have to act like this? > > Regards, > > Guang > > -----邮件原件----- > 发件人: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] 代表 > Christian Vogt > 发送时间: 2009年4月23日 12:40 > 收件人: Jun Bi > 抄送: Guang Yao; 'SAVI Mailing List'; 'Greg Daley'; 'Suresh Krishnan' > 主题: Re: [savi] DAD as a binding distribution protocol: why not > > On Apr 15, 2009, Jun Bi wrote: > > > Certainly, the major problem of SAVI-FCFS is not only the first packet > > > lost. Even the first packet is not lost, FCFS still need a BDP, and it > > > might be complex when we have multiple SAVI-swtiches (the real-time > > > sync > > > requirements), we even didn't see a prototype of BDP yet. But SAVI-CPS > > > doesn't need the BDP, just need some enhancement. > > Jun and all - > > When comparing FCFS and SAVI-CPS, we should be careful not to mix > > DHCP-based and SLAAC-based address configuration. > > It is true that SAVI-CPS, or control-packet-only snooping in general, > > may not need a BDP in the case of DHCP-assigned addresses. Thanks to > > the acknowledged address assignment exchange, the lack of an address > > binding in a SAVI device then implies with high reliability that packets > > locally originating from this address should be dropped. > > But in the case of addresses auto-configured via SLAAC, snooping only > > control packets doesn't have the same effect. Since there is no > > acknowledged address assignment exchange, the lack of an address binding > > in a SAVI device does NOT imply that packets locally originating from > > this address should be dropped. I.e., the best a SAVI device can do in > > this case is let such packets through. And the scenario that Marcelo > > had illustrated earlier shows that this may lead to a vulnerability. > > Hence, control-packet-only snooping in SLAAC could in some cases > > benefit from a BDP, independent of whether you use FCFS or SAVI-CPS. > > So the issue with SLAAC-based address configuration is the same whether > > we use FCFS or SAVI-CPS -- independent of whether we believe that this > > issue justifies the development of a BDP. > > - Christian > > _______________________________________________ > > savi mailing list > > savi@ietf.org > > https://www.ietf.org/mailman/listinfo/savi > > ------------------------------------------------------------------------ > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From marcelo@it.uc3m.es Thu Apr 30 06:37:35 2009 Return-Path: X-Original-To: savi@core3.amsl.com Delivered-To: savi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15BF28C34C for ; Thu, 30 Apr 2009 06:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.037 X-Spam-Level: X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6eIGzJquTVa for ; Thu, 30 Apr 2009 06:37:34 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 3E04428C341 for ; Thu, 30 Apr 2009 06:37:33 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (41.pool85-53-134.dynamic.orange.es [85.53.134.41]) by smtp03.uc3m.es (Postfix) with ESMTP id D2BE172D404; Thu, 30 Apr 2009 15:38:44 +0200 (CEST) Message-ID: <49F9A9E4.6080204@it.uc3m.es> Date: Thu, 30 Apr 2009 15:38:44 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Guang Yao References: <000001c9c86a$e5d993e0$b18cbba0$@tsinghua.edu.cn> In-Reply-To: <000001c9c86a$e5d993e0$b18cbba0$@tsinghua.edu.cn> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16612.005 Cc: 'SAVI Mailing List' , 'Christian Vogt' Subject: Re: [savi] About the failure situation mentioned by Marcelo X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the SAVI WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 13:37:35 -0000 Guang Yao escribi: > > Christian and Marcelo, > > Sorry for my long absence from the discussion. > > I will try to present my opinions on recent topics: > > 1 The situation mentioned by Marcelo > > /* content from Marcelo抯 mail > > In addition to that, there is the impact of failures. > > Consider the following scenario that i have presented in a previous email: > > +-------+ > > | HOST | > > +-------+ > > | > > +------------------+ > > | LEGACY SWITCH | > > +------------------+ > > | > > +------------------+ > > | SAVI CPS DEVICE | > > +------------------+ > > | > > +----------------+ > > | REST of WORLD | > > +----------------+ > > I understand this can be a very common configuration, for instance > when the SAVI function is located in the router rather than in the > switch(this seems to be the topology the broadband forum is looking > into), or when you are having an incremental deployment of SAVI and > you have upgraded some switches and not others > > Suppose that the HOST boots and perform DAD. > > The savi cps device creates state > > everything is working fine > > SAVI CPS device is rebooted (happens all the time at home for instance) > > Now the SAVI CPS Data base is deleted and SAVI CPS starts dropping > packets from HOST, since HOST will not perform the DAD again > > */ > > The point of Marcelo is that the SAVI device may reboot and the > binding states are lost, which makes the SAVI device drops packets > incorrectly. > > This is good start point to discuss which hosts are to be > administrated by SAVI device. > > As I mentioned in some previous mails, the only unspoofable anchors > are 1 exclusive switch port, 2 secure MAC address in 802.1ae/af and > 802.11i. Unfortunately, they are only valid for directly attached > hosts. This means, if a host is not directly attached to SAVI device, > its anchor is spoofable and doesn抰 necessarily represent the host itself. > > If we can find other anchors that can work on a device not directly > connected, things will be different. > well, we have SEND SAVI, but it has other limitiations i.e. requre send deplyment, so we can leave out of this particular disucssion > However, there isn抰 another 搒trict secure anchor satisfying this > requirement currently. > > Thus we have two directions here: > > 1 bindings are only set up for directly attached hosts, and the > binding entries are used to 揹eny the traffic from the legacy-SAVI > port.(class A) > > Then the situation mentioned by Marcelo can be handled. The SAVI > device doesn抰 have to set up bindings based on the traffic from > legacy switch and the traffic from legacy switch will not be filtered > incorrectly. > > This solution has an advantage that the directly attached host can be > bound tightly with strong anchor. > > The disadvantage of this solution is that the SAVI device must > distinguish SAVI-Legacy port and SAVI-Host port. Currently manual > configuration is the most proper mechanism, which bring administration > cost. > i am not sure if a follow, what happens to the packets arriving through the SAV legacy port? No filtering whatsoever is ever made, or a binding is created using DAD packets or else? > > 2 bindings are also set up for remote hosts without differences with > directly attached hosts.(class B) > > Because of the situation mentioned by Marcelo above, SAVI device > cannot rely on control packets only, and must use auxiliary protocols, > i am not sure why you bring the BDP or MLD protocol here. I mean, this situation occurs when there is a single SAVI device so a BDP will not help here. What can be done is to learn using data packets (instead of discarding them) > e.g., BDP or MLD. > > In this direction, the SAVI device doesn抰 have to distinguish > SAVI-Legacy port and SAVI-Host port. And the packets from the > SAVI-Legacy port are filtered based on 揳llow rules. > > However, I will try to make out two points here: > > (a) Set up bindings for remote hosts will not provide stronger > security than using bindings from adjacent hosts to 揹eny packets > from remote hosts > i don't understand what you mean here > For a class B device, there are only two kinds of addresses: bound > addresses and unbound addresses. > > Whenever an address appears from a SAVI-Legacy port, and it has been > bound on other ports, this packet will be dropped by both class A and > class B device. > that is not obvious to me from the description you made of the class a above > Whenever a new address appears from a SAVI-Legacy port, the class B > SAVI cannot drop the packet but set up a new binding for the address, > typically based on the principle 揊CFS. > right > However, FCFS actually means using existing bindings to 揹eny packets > from SAVI-Legacy port, which is used by class A. > i don't understand what you mean here > And neither class A nor class B devices can distinguish spoofing from > unspoofing at the SAVI-Legacy port, for they share the same anchor. > Would a class A solution you describe above coud be able to distinguish when an address used in port 1 connected to a legacy siwthc is next used to port 2 which is also connected to a legacy switch? > Thus, class A and class B actually have the same filtering ability, > which means setting up bindings for remote hosts will not achieve > better filtering ability. > I don't understnad this conclusion, I don't thionk the filtering capability is the same > (b) Class A controls spoofing from adjacent hosts better. > > Whenever spoofing happens from adjacent hosts, class A device knows > exactly who is spoofing.This is a good feature for management. > > However, class B device only knows spoofing happens, but it doesn抰 > know whether the spoofing happens locally or remotely. > i don't understnad what do you mean by this. Using the state in the savi binding, a class b can track down the address to a port where either a host or a legacy switch is directly connected. > And setting up bindings for remote hosts costs a lot of memory. > Actually, the memory cost will be a big problem in a big network. > Class B also needs additional protocol. > > Another point is, the feature of the traffic from SAVI-Legacy port is > much different from that from SAVI-host port. Thus it is reasonable to > distinguish different kinds of ports. > mmm, i don't see why is this reasonable, > The summary of above argument is, class A is better than class B, > which means bindings are only set up for directly attached hosts, > and the binding entries are used to 揹eny the traffic from the > legacy-SAVI port. > i still don't very clear about how the class A solution work, so i am nt sure i agree with the statement Regards, marcelo > > Best regards, > > Guang > > -- > > Guang Yao > > Network Research Center > > Tsinghua University > > Beijing, China >