Subject: [SAVA] Review of draft-baker-sava-implementation-00

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Fri, 23 Nov 2007 21:07:09 +0200

Fred,

thanks for writing this document.  It is very good to have an overview
of this IP source address verification solution.  Still, to help a
reader understand the feasibility, requirements, and implications of the
solution, the document needs to be a bit more detailed and concise IMO.

Below are suggestions on restructuring the document to this extent.  It
would be great if you could give the document a revision based on those,
possibly even before the SAVI BoF in Vancouver.  The structure below
should also be helpful for a presentation of your solution at the BoF.

(1) Begin with a brief summary of the main idea:

- Address filter located on the path of to-be verified packets, capable
   of dropping packets

- monitors address configuration signaling in order to build up a list
   of legitimate bindings between IP addresses and link layer addresses

- can additionally be manually configured with static bindings

- drops packets of which IP and link layer addresses do not match an
   entry in the list

(2) Then start adding details:

- Location of filter:  Must be on same link as packet sender since
   original link layer addresses are otherwise not visible.  Can be on a
   switch, on an access router, on a neighbor.

- Means for address configuration we need to consider:  DHCP,
   autonomous configuration

- Link layer addresses to which IP addresses may be bound:  Add your
   first list in section 2.1.

- Reactive verification of address binding (double-checking):  If no
   binding exists for a packet, double check addresses prior to dropping
   the packet, e.g., based on Neighbor Unreachability Detection.

- Hard-state for manually configured bindings, soft-state otherwise.

(3) A discussion of things to be worked out:

- What happens if a filter misses part of the address configuration
   signaling before it boots up or appears on a link?  (E.g., what about
   filters on mobile hosts?)

- Packet caching or not during double-checking?

- How long should refresh triggers and timeout values for soft-state
   bindings be?

(4) Security considerations:

- DoS threat:  Legitimate host prevented by attacker from using its
   own IP address.  This is already possible with NDP.

- Flooding threat:  Attacker floods packet cache in filter. Mitigation
   possible through limiting number of IP addresses per link layer
   address.  Align soft-state timeouts with change interval for privacy
   addresses so that limit does not get reached.

Best regards,
- Christian