Subject: [savi] IETF SAVI SLAAC

From: "Bi Jun" <[email-masked]>
Date: Fri, 30 Oct 2009 18:27:46 +0800

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.

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.)

(2) A rate limit of sending probes can be set to avoid DoS. (This limit cannot be set on other types of ports, either.)

(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).

1.4   Add a section to specify the procedure to remove a binding(Section 11 in slaac-cps can contribute).

1.5   Add a section to clearly specify the details on special situations(Section 13,14,15 in slaac-cps can contribute).

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.