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?

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.

(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