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

From: christian.vogt at nomadiclab.com (Christian Vogt)
Date: Tue, 08 Jan 2008 22:17:25 +0200

Hi Fred,

getting back to our discussion on draft-baker-sava-implementation-00...

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

Right, the proposed solution should be introduced at such a high level
first, IMO.  However, I do not agree with the last sentence in the above
paragraph.  The specification should be much more detailed than it
currently is.  The current version leaves implementors too much freedom.
We should provide a clear algorithm for each address configuration mode.

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

I think what is relevant here is that the existing message that says
"Hey, everybody, I have chosen to use this address" -- namely the NS of
the statelessly configuring entity -- is insufficient as a trigger to
create a trust binding.  This is so regardless of whether a host, a
router, or a switch is validating an address, because a potential
defending NA would be sent by unicast and thus may not be received by a
snooping entity that sits behind a switch.  This is why another NS/NA
exchange between the validating and validated entities is needed.

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

If a router drops a packet in case it has no binding, wouldn't this be
problematic if that router is behind a switch (see my previous comment)?

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

My comment addressed the situation where the SAVI filter is implemented
on a router or switch, and a host configures its address at a time or at
a place where the SAVI filter cannot snoop the address configuration
traffic.  This may happen if the filter becomes enabled on a link where
hosts already have their addresses, or when a mobile host takes an
address from one switch to another switch on the same link.  If we
require routers and switches to pursue an NS/NA exchange with the
validated host before dropping a packet, as suggested in my previous
comment, then this issue is solved as well.

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

Dimensioning the trust binding lifetime in accordance with Neighbor
Unreachability Detection timeouts is a good idea.

Neighbor Unreachability Detection uses two ways to refresh state (see
RFC 4861, section 7.3.1), of which only one is applicable without
restrictions to our SAVI solution:

- "Forward progress" of an application can only be determined by a host
   engaged in active communications with a peer, hence it is not
   applicable when the SAVI filter is not on a host.

- Periodic exchanges of NS/NA messages happen by default every 35 s
   (REACHABLE_TIME + DELAY_FIRST_PROBE_TIME).  Such exchanges could be
   applied by any kind of SAVI filter.

I would recommend making the timeout interval in SAVI configurable with
a default of 30 s (REACHABLE_TIME).

- Christian