[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [savi] Binding establishment based on data or control packets?



Hi Chrstian,

Christian Vogt escribió:
Marcelo -

A late comment on our previous discussion on whether SAVI devices should
initiate an NS/NA exchange upon reception of a data packet with a new
source address.  In this discussion, you had identified the following
attack vulnerability that would appear if SAVI devices did initiate an
NS/NA exchange in such a case*:

Triggering an NSOL upon the reception of a data packet for which there

is no binding in the SAVI device could have two potential advantages:

- first, that can be used to synchronize multiple SAVI devices. this is
  indeed a benefit

- second that could allow a victim to know if an attacker is trying to
  set up a savi state for the victim's address. Now this seems like an
  advanatage, but after some thought, i don't think it is.

Let's suppose that the savi device sends a RSOL packet upon the
reception of a data packet with an unknown source address. Suppose the
SAVI device receives two replies. What can the SAVI device do with this?

Actually what happens when we design SAVI such that it sends RSOL
packets, is that the RSOL packet acts as a synchronization point, that
can be used by attacker to claim the address ownership and confuse the
SAVI device. In other words, the whole point of a FCFS appraoch, is that
requests arrive in the natural. If we introduce the RSOL
synchronization, the order is broken and we can hardly tell who is the
first one to request.

(* Replace "RSOL" with "NSOL" in the quotation; this was a typo.)

What if SAVI devices blocked NA packets that do not correspond to any of
their cached bindings?  (I believe this is what Guang was alluding to in
one of his earlier messages.)

Then, if a SAVI device receives a data packet with a new source address,
and if this SAVI device sends a "proxy" NS on behalf of the host sending
the packet, an attacker won't be able to interfere by sending an NA for
said source address.

Blocking illegitimate NA packets would therefore prevent the attack that
you have identified, which would exist if SAVI devices let the
attacker's NA packet pass.  So it would be a way to retain the natural
FCFS order of address requests -- where an "address request" comes in
form of a data packet with a new source address.  Also, blocking
illegitimate NA packets should make it impossible that a SAVI device
receives two NA packets for its proxy NS.

In other words, SAVI devices should use the following rules:

- Let NS packets pass.  If no corresponding binding exists, create such
  binding if no responding NA packet received during next X seconds.

- Let NA packets pass if and only if a binding exists for the NA's
  target address.  Otherwise, drop the NA packet.

- Let data packets pass if a corresponding binding exists.

- Send a proxy DAD NS packet if a data packet does not correspond to an
  existing binding.  Create a corresponding binding if no responding
  NA packet is received during next X seconds.  (We would need to
  discuss whether the SAVI device should drop, or let pass, any data
  packets received throughout the X seconds during which it waits for
  NA packets.)


What about legitimate NA for source addresses _not_ corresponding to an existing SAVI binding? I mean, SAVI bindings are soft state, hence it can and will be discarded at some point. So, it seem perfectly possible to me that a node sends a legitimate NA and that the binding if once existed, has been discarded.
Dropping legitimate NA packets seems to be problematic, i think

Regards, marcelo


Does this make sense?

- Christian





Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.