I agree the CPS must be the first mechanism. Because SAVI device is the closest device to host, there have not STP protocol, so the DAD NS will hardly lose. On the other hand, monitor the data packet of a flow is heavy burden. When a host start sending data packet, it will send many data packet before it check the reception is normal. But it will check the control packet's reception immediately, then send data packet. If the SAVI device bind entry from data packet of a flow, how to deal with the data packet of this flow before the entry take effect? If cache these packet, it will burden SAVI device. BTW, I'm afraid of the numerous state of both SAVI SLAAC and SAVI DHCP. As the access device, SAVI must simpler and simpler, the numerous will complex it. Should we have a simple solution? ----- Original Message ----- From: "Jun Bi" <junbi at tsinghua.edu.cn> To: "Eric Levy-Abegnoli" <elevyabe at cisco.com> Cc: "'SAVI Mailing List'" <savi at ietf.org> Sent: Wednesday, November 04, 2009 11:20 PM Subject: Re: [savi] IETF SAVI SLAAC > Dear Eric, > > Thank you very much for review comments. > > Before answering your question, I'd like to clearly our proposal in short: > 1 Have the port type definition. From the requirement, I believe the SAVI-host port (A host is directly attached to a switch port, no port sharing) > is very necessary (for example an operator like CERNET), because > 1) the security (using physical port as the anchor is the most secure we can achieve in lightweight), > 2) management (host granular tracing back), > 3) and billing reasons (to precisely billing to the single source address. > Certainly, to define such a port type could be in either the solution document or framework document. > > 2 For the SAVI-host port, the mechanism (actually mixed CPS and FCFS) is the best choice I believe. > 1) For "normal case", the data packet is expected to come to the switch port later than control packets (as we observed > in our experiments). The switch could run CPS mode by just listening the DAD procedure completion, then setting up the binding. > It's more light weight and secure. Because the number of control packets are smaller than data packets (might in line rate of 1G, even 10Gbps), > then the burden brought to the switch is lower than FCFS (the DAD-NS probe, a CPU action, is triggered by any source address-unbound > data packets, which is a normal case when the host using multiple addresses). Can we store the packets with source address being verified in > the switch when the switch sending out DAD-NS probe? If yes, there is another burden. If no but forwarding, then the single-packet attack can not be traced back. If no but dropping, the switch may drop lots of legitimate user packets during the DAD-NS probe procedure. > Moreover, the result of FCFS is unknown yet, but the first hop CPS is already proved working with the prosody and experiments in Tsinghua/CERNET. > (2) For "special case", where the DAD-NS is lost in the link between SAVI port and the host (which is very low possibility > as Fred Baker analyzed), FCFS mode is a way to recover the state (sending probe for source address-unbound packets). > Because this is a low possibility case, then the cost and security threaten is not eliminated. > > 3 For a port type that SAVI switch connected to a nonSAVI switch (hub) (the port is shared by multiple hosts, we call it > SAVI-ploy port), FCFS mode is OK, If an operator wants it (without strictly host-granularity requirement). > So it's better to keep two modes for different port types. What we proposed is that some section addressed some > problems, but still need some details, where we can contribute to those sections with the text in our draft. > > My other replies are in line below. > > Thank you once again! > > Best Regards, > Jun Bi > > > > > > From: Eric Levy-Abegnoli > Sent: Wednesday, November 04, 2009 9:28 PM > To: Bi Jun > Cc: 'SAVI Mailing List' > Subject: Re: [savi] IETF SAVI SLAAC > > > Jun bi, > "some" comments inline ... > Eric > > Bi Jun a écrit : > Dear Erik，Marcelo, and Eric, > > Below is our revision suggestion towards final draft-ietf-slaac-00. > Thanks, > Jun Bi > > > A merge proposal based on FCFS-02 and slaac-cps-00(as attachments): > > > > Basic frame: FCFS-02. > > > > 1. Sections to Add > > > > 1.1 Add a section for IPv4(Section 10.1.2 in slaac-cps may contribute) > > > > Add a section to handle IPv4 address using the similar mechanism. This section specifies the procedure to set up binding for manually configured(but not static) IPv4 address, as described in [RFC5227]. > > This mechanism can handle the situation in which users can configure their address manually so long as the address belongs to an allowed prefix. > > This situation is different from that any interface can only configure a fixed address, and manually configuration on the SAVI device wouldn’t handle it. > > > > 1.2 Add a port type: host port, as a complement of port-validation > > > > For a port directly attached to a single host, mechanism mainly based on control packet snooping(Section 10.1.1 in slaac-cps may contribute) would be more lightweight and secure. > > > > As described in RFC4862, DAD must be performed before assigning any address. It’s the reasonability basis of control packet snooping only. For a savi-host port, it is rarely necessary for the savi device to trigger a detection on behavior of the attached host, unless in the case that detection packets are got lost(with an extremely little possibility). > > In slaac-cps00, the savi device should snoop a wide scope of control packet, to avoid dropping valid packet as much as possible. Will a host send data packet directly without performing any resolution? > > Even in an extreme bad situation, the savi device can send probes whenever a new address appears(but this function is turned off by default.). Although this seems the same as FCFS, there is a benefit the savi device can control the rate to prevent DoS attack. > > I thought we already had this discussion. There are clearly cases where the switch is going to miss DAD packets. **As an example** when the spanning tree is being calculated (learning state), packets an't bridged but drop. So unless you configure your switch otherwise, it is fairly common that the first minute of forwarding is lost. And that includes DAD packets. > So it is a must to handle that situation, and the proposal we discussed in Stockholm was to poll the source of a data packet (DAD NS) to learn the binding **from a control message**. > It's not worse than an address resolution performed on a router in the other direction. Except that in the savi case, the switch would not be required to keep the original packet. > Maybe I am missing your point. Are you proposing to make that behavior optional? Then you would surely break those cases on missed DAD messages, wouldn't you? > > > > BJ: if the DAD is not lost in the link between SAVI switch-host port and the host, then the switch already receives the DAD-NS. Then based on CPS-SLAAC, no mater the DAD-NS is forwarded or not, the binding is set up, right? > > > > > The security aspect: > > (1) A clear entry number limit can be set for each host and avoid binding entry exhaustion.(This limit can never be set on a port accessed by a number of hosts.) > > The limit should be per-anchor. I have no issue with that. Actually, I remember I brought that up to the list some time ago. As long as it is not the "primary" security mechanism. Because, as such, it is very poor. Any limit per anchor (mac, port, etc). protect the device, but weaken same-anchor-users. For instance, if you put a limit per mac, then an attacker could get you to this limit, and prevent other legitimate users to install an entry for this mac. > > > > > BJ: what we proposed above is the mechanism for strict security case only -- for the SAVI-host port. The port is only bound with ONE host. > There is not anchor sharing in this case. So it's reasonable to limit the host if it performs bad. > > > > > > > > (2) A rate limit of sending probes can be set to avoid DoS. (This limit cannot be set on other types of ports, either.) > > I think that is briefly mentionned in the current draft in section 4.2.2 > > > (3) A more strict filtering policy(e.g., default dropping) can be set on such port, to stop one packet attack and DoS against the savi device itself. (Default dropping policy cannot be set on other kinds of ports.) > > (4) A host level granularity trace ability can be enabled. > > > > 1.3 Add a section to specify the procedure of check a packet(Section 12 in slaac-cps can contribute). > > Similar considerations can be found in section 2.4 of the current document. > > > 1.4 Add a section to specify the procedure to remove a binding(Section 11 in slaac-cps can contribute). > > > The move scenario is described in section 2.3. > The delete scenario is not described (and is probably worse discussing here) but the consensus was "on-demand garbage collection at the time the SAVI device runs out of memory". > > > > 1.5 Add a section to clearly specify the details on special situations(Section 13,14,15 in slaac-cps can contribute). > > I think there is generally good stuff there. With a lot of question marks. Certainly worth discussing on the list. > > > 1.6 Add a section to specify the related constants, especially the time related constants, e.g, TENT_LT. > > > > 2. Sections to be moved to framework > > > > 2.1, 2.2, 2.4, 2.5 > > These sections are great analysis work on SAVI solutions in common. They should be moved to savi-framework or another informational draft for clarity. > > > > 3. Open issues: > > > > 3.1 Whether to build a perimeter based on SAVI functions? > > Benefits: > > 1. An attacker cannot spoof any address in SAVI area; > > 2. Spoofing packets will be dropped on reaching the perimeter; > > 3. Spoofing packets from non-SAVI area will be filtered at a “anchor” level. > > Cost: > > 1. Control plane cost: A SAVI device will potentially keep a record of all the addresses on the link. It is unconvinced that the storage distribution mechanism will work indeed. More details of this mechanism should be specified. > > 2. Additional communication cost: using NDP as a BDP to distribute bindings; > > 3. Data plane cost: whenever check a packet, the SAVI device must go through an extremely huge deny list. > > Possible error: > > 1. Whether is it reasonable to set up bindings for hosts out of SAVI area based on FCFS? > > -The owner of an address is never necessary to send a packet first to the SAVI area. Then another host can set up a binding before it and make the perimeter to drop the traffic of the address owner. > > > > Alterative: > > Make it an optional function, or use mature techniques: > > -Separate the prefix scope of SAVI area and non-SAVI area. Using ingress filter the perform prefix level check. > > This is sure to work. > > ------------------------------------------------------------------------------ > _______________________________________________ > savi mailing list > savi at ietf.org > https://www.ietf.org/mailman/listinfo/savi > > > > > -------------------------------------------------------------------------------- > > > _______________________________________________ > savi mailing list > savi at ietf.org > https://www.ietf.org/mailman/listinfo/savi > -------------------------------------------------------------------------------- > _______________________________________________ > savi mailing list > savi at ietf.org > https://www.ietf.org/mailman/listinfo/savi >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.