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

From: fred at cisco.com (Fred Baker)
Date: Tue, 11 Dec 2007 14:18:16 -0800

So I'm thinking about your comments. It comes down to - you want the  
document completely rewritten in a different order and in a different  
style. How badly do you want that? I might be of the opinion that you  
should write it.

If we can find a way to meet somewhere in the middle, with an edited  
version of this document, I have some questions interspersed. I'd  
also like to know whether there are any sections you want added or  
deleted in the current IPv6 document.

On Nov 23, 2007, at 11:07 AM, Christian Vogt wrote:

> 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

Would adding this paragraph meet your needs, given that what you say  
above is repeated in the next section?

The key point is the association of an IPv6 source address with a  
lower layer identifier, which might be purely local in significance  
like a port identifier on a switch, might be visible in the LAN like  
a MAC address, and might be a combination of lower layer identifiers  
like "the system on one of two ports using a stated MAC address". The  
association is called a "trust binding", and is fundamental to the  
solution. The implementation details are left to the implementor.

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

how, precisely, does one snoop SAA, given that it sends no "Hey,  
everybody, I have chosen to use this address" message? The reason I  
went to what you call "double checking" is that it is the first time  
we see the device assert that it is in fact using a given address in  
SAA. The DAD check asserts that it *might* start using it and gives  
an opportunity for someone else to say "please don't".

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

there are a lot more than addresses...

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

A host might check the address before dropping it. A router will  
simply drop the packet if it has no neighbor binding.

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

I'm not sure I follow. When a host decides to use a new address and  
sends a datagram using it to a neighboring host, RFC 4862 has the  
neighboring host send the Neighbor Solicit sometime between receiving  
the datagram and sending a response. As a "security consideration"  
recommendation, I assert that instead of sending the NS when it has  
operated on the datagram and is about to reply, it should send the NS  
on receipt and then either force the neighbor to retransmit or queue  
the packet pending the NA response. WHat part of that would the host  
miss and still be able to continue?

If you're talking about DHCP, I guarantee that a neighboring host in  
a switched network will miss it, and by the way it will always miss  
the part of SAA where the host autonomously decides that DAD has  
failed to produce a competitor, so the host will go ahead and use a  
given address. For this to work in IPv6, I really think it has to key  
off NS/SeND, not DHCP or SAA. If it does as I suggest, I don't think  
this is a question.

> - Packet caching or not during double-checking?

already covered.

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

what is the refresh timeout for ND?

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