Subject: Re: [savi] A different trade off for SAVI

From: Eric Levy-Abegnoli <[email-masked]>
Date: Wed, 01 Jul 2009 17:58:42 +0200

Christian,
Christian Vogt a écrit :
>
> Eric -
>
> Thanks for clarifying.  Yet what I think you need to clarify even
> further is why the benefits of snooping ND packets, which you identify
> in your email below, cannot already be obtained with the current SAVI
> solution, which snoops all packets.  Could you do this?
>
A few reasons:
1) The most obvious reason was mentionned previously: DAD packets can 
get lost (low probability), not being sent (higher probability), or 
simply not seen in multiple switch scenario. The latter may have not 
been discussed, but a very common situation is a switch (make it savi) 
connected to a  bunch of Access Points (you can see them as dumb L2 
switches). APs comes up, end-nodes comes up, then the savi-switch comes 
up. All DAD are missed.
Snooping at other NDP packets will increase the chances to discover 
end-nodes. It's not guaranteed, but it is better.
2) Another  benefit of looking at other packets would be  the capability 
to keep a "reachabilty" state of end-nodes.  In fcfs, it is proposed to 
"ND ping" the binding owner  to verify wether it is still there (or 
rather, that is is gone) when receiving a binding from a different port. 
I see some issues with that, including a potential attack. If we can 
have a more accurate state of the binding entry, based on information 
snooped in other ND packets (DAD only happens once, at the beginning), 
we can save or at least reduce the need for these ping messages.
3) Last but not least, other NDP messages carry LLA options. I like to 
think that the mac used in binding records should come from there, 
rather than from the L2, and that is is an option to verify that the two 
match. I feel like we might be in trouble otherwise, in scenarios where 
someone announces a binding on behalf of someone else. I know pieces of 
software that do that. If we consider this possibility, then the DAD NS 
is pretty much the only packet that will not carry the LLA, hence the 
benefit at looking at other packets.
Eric

> - Christian
>
>
>
> On Jun 30, 2009, Eric Levy-Abegnoli wrote:
>
>> Christian,
>>
>> there are several alleys where I am proposing something "different",
>> hence the confusion that I may have created in the thread. Apologies to
>> the wg for that. "Unfortunately", these differences  are tight up
>> together to some extend, and it's hard for me to extract one piece and
>> describe the benefit as if it was standalone (hopefully, if I get a
>> chance to present the proposal at ietf75, maybe it become clearer).
>>
>> To this sepcific point, the reasons why I was proposing to look at other
>> ND packets are of two folds:
>>
>> - use them to maintain most accurate/up-to-date "state" of the binding
>> entries, to make more accurate decisions (in case DAD was not seen, for
>> movement, to poll entry owners, etc.)
>>
>> - to exploit the content of the binding information provided in these ND
>> packets, in particular the LLA.
>>
>> From a switch standpoint, I don't see much extra difficulty or burden to
>> look at all NDP packets rather than "just" the DAD.
>>
>> Eric
>
>
>
>

---

From: Christian Vogt <[email-masked]>
Date: Wed, 1 Jul 2009 17:28:40 -0700

Hi Eric -

Thank you for the detailed response.  And yet, I am still unconvinced of
the usefulness of snooping all ND packets, but no data packets, compared
to snooping all packets, including data packets.  In particular, I don't
see why the extra information in the payload of ND packets may be of use
for SAVI.

> up. All DAD are missed. Snooping at other NDP packets will increase  
> the
> chances to discover end-nodes. It's not guaranteed, but it is better.

Sure, but snooping all packets, including data packets, achieves the
same, doesn't it?

> we can save or at least reduce the need for these ping messages.

You are saying that snooping all ND packets would indicate binding
liveness in a manner (a) more frequent and (b) more secure than just
snooping DAD packets.  I agree with (a).  But (a) is also achieved by
snooping all packets, including data packets.  (b), in turn, requires
further explanation.  I don't see why snooping ND packets would, in the
general case, be more secure than snooping all packets.  Or are you
perhaps referring to the specific case where SAVI is used in
SEND-enabled networks?

> benefit at looking at other packets.

I see only one advantage of the Link Layer Address option in ND packets,
and this advantage does not apply to SAVI.  The Link Layer Address
option was introduced to ND as a link-layer-independent means to
communicate addresses of different link layers.  However, in the case of
SAVI, link layer independence is of limited usefulness.  After all, SAVI
will be implemented in link layer devices, for use with only a single
type of link layer.  Do you agree?

- Christian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 01 Jul 2009 21:16:24 -0400

It depends upon what one assumes, I think.
For example, I have tended to pick on SEND.
If one assumes SEND, DAD packets may still be lost.  But secured 
Neighbor Solicitation  Request / Responses must occur.  So snooping 
those would give you a reliable method of establishing appropriate 
bindings.  If the switches enforced that the MAC / IP address pair 
appeared only on the correct port, based on this observation, we would 
have achieved a goal that some people consider important.
In some sense, this is very similar to snooping the DHCP packets, which 
is another mechanisms for getting these things.

Of course, whether this is useful by itself depends upon what threat we 
are interested in.  If we are only interested in preventing imposture, 
that may be sufficient.

On the other hand, some folks have asked for accountability, so that any 
packet stream on the Internet can be correctly associated with the 
machine that sourced it.  That probably requires additional mechanisms, 
such as syslog recording or DHCP logs.  Some folks find those mechanisms 
to be onnerous, while others consider them reasonable and necessary. 
Whether we need them depends upon what threat we want to counter.

Yours,
Joel M. Halpern

Christian Vogt wrote:
>> up. All DAD are missed. Snooping at other NDP packets will increase the
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: Christian Vogt <[email-masked]>
Date: Wed, 1 Jul 2009 19:22:29 -0700

Joel -

> It depends upon what one assumes, I think. For example, I have  
> tended to
> pick on SEND. If one assumes SEND, DAD packets may still be lost.  But
> secured Neighbor Solicitation  Request / Responses must occur.  So
> snooping those would give you a reliable method of establishing
> appropriate bindings.  If the switches enforced that the MAC/IP  
> address
> pair appeared only on the correct port, based on this observation, we
> would have achieved a goal that some people consider important.

Yes, in networks that use SEND, monitoring or using ND packets other
than DAD packets may be useful.  Hence my question to Eric whether he
considers his ideas to be specific to SEND-capable networks.  In that
case, though, one would have to evaluate how much room for improvement
there is for our existing SEND-based SAVI solution.  Our existing
SEND-based SAVI solution already makes extended use of ND packets.

> Whether we need them depends upon what threat we want to counter.

Our current discussion on the protection of unused addresses is based on
the underlying question of whether we want to, and can with reasonable
complexity, prevent attackers from hiding their identity or location.
Hiding one's identity or location is a common motivation for attackers
to spoof their IP source address, by hijacking an address that may be
unused.  Would you say that logging potential attempts to hijack an
unused address would be useful in combatting those attackers?

If we could agree to log, but not discard, packets with unknown source
addresses in scenarios where (non-SEND) SLAAC is in use, and to discard
those packets in SEND-capable or DHCP-only networks, then we would be a
big step further: Such an agreement would be in line with the previous
observation [1] that the benefit/cost ratio for discarding those packets
is significantly lower in networks that use SLAAC than it is in
SEND-capable or DHCP-only networks.

- Christian

[1] http://www.ietf.org/mail-archive/web/savi/current/msg00715.html

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 01 Jul 2009 22:42:28 -0400

Comments on the unused address issue below.
I will take it as given for this discussion that we are trying to 
investigate the possibility of protecting unused addresses without SEND 
and without DHCP.  (If you have either one, you permit only packets with 
assigned addresses, and some system logs the bindings.)

I will also assume that the goal is to correctly attribute Internet 
problems to the machine which sent caused them.

Christian Vogt wrote:
...
> SEND-capable or DHCP-only networks.

Whether such "logging" is sufficient probably depends upon both what 
threat we want to deal with, in what topology, and what degree of 
logging we are prepared to require.

First, we have to assume no wireless, since otherwise we have no idea 
what machine is actually using the SLAAC.

Then, while I have no trouble with the notion of DHCP servers or routers 
generating syslog entries to syslog servers to record binding creations, 
it seems that this would require more extensive logging.  The immediate 
port which is connected to the single machine would need to create log 
entries every time that machine used a new IP address.  (This is why I 
assumed no wireless.)
If we are willing to require a topology where there are Savi-sensitive 
switches at every leaf, and that they have that kind of logging, then we 
would have a proposal to evaluate.
(Thus, the question of "logging" depends very heavily upon the questions 
of "who" and "where", coupled to "in what sort of network?")

(Rant about other threats removed, as this was a specific question.)

Yours,
Joel

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Jul 2009 12:03:05 +0200

Frank Xia escribió:
> Hi Christian
>
> Yes.
>
> My another observation is that people only talk about
> DAD defined in RFC4862  while ignoring Optimistic DAD defined in 
> RFC4429 which
> let go data traffic preceding control message

mmm, maybe i am confused, but in optimistc DAD what changes is that the 
node does not wait for 1 sec before sending data apcket with the soruce 
address, but it is still sending the DAD NSOL prior sending data 
packets, right?
So, i mean, the SAVI device would still first see the DAD NSOL and then 
right away a data packet. So, in that case, we could create the 
optimistic binding and keep track if there is any DAD NADV as a reply to 
the original DAD NSOL.

Regards, marcelo

>
> BR
> Frank
>
> ----- Original Message ----- From: "Christian Vogt" 
> <[email-masked]>
> To: "Frank Xia" <[email-masked]>
> Cc: "SAVI Mailing List" <[email-masked]>
> Sent: Tuesday, June 23, 2009 9:05 PM
> Subject: Re: [savi] A different trade off for SAVI
>
>
>>
>> On Jun 15, 2009, Frank Xia wrote:
>>
>>> DAD is NOT a MUST for stateless address configuration. RFC 4862 reads
>>>
>>>    "By default, all addresses should be tested for uniqueness prior to
>>>    their assignment to an interface for safety.  The test should
>>>    individually be performed on all addresses obtained manually, via
>>>    stateless address autoconfiguration, or via DHCPv6.  To accommodate
>>>    sites that believe the overhead of performing Duplicate Address
>>>    Detection outweighs its benefits, the use of Duplicate Address
>>>    Detection can be disabled through the administrative setting of a
>>>    per-interface configuration flag."
>>
>> Isn't this just another reason to forward packets in the absence of a
>> binding, rather than discarding them?  I see this in support of the
>> proposed FCFS variant.
>>
>> - Christian
>>
>>
>>

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Thu, 02 Jul 2009 16:03:54 +0200

Christian,
Christian Vogt a écrit :
> Joel -
>
>> It depends upon what one assumes, I think. For example, I have tended to
>> appropriate bindings.  If the switches enforced that the MAC/IP address

A very realistic deployment scenario for SeND is going to be the one of 
a mix of SeND and and non-SeND capable devices attached to the same 
link/switch. In that case, non-SeND capable device are not taking any 
benefit of SeND, and can be led to trust SeND node bogus bindings.
If bindings with SeND credential can be preferred over the one without 
(in case of collision) - overriding the fist-come algorithm -, then the 
switch will increase the security for everybody, not just the subset or 
SeND-capable nodes.
So it's not only SEND-capable networks, it's any network with a few 
(even just one) SeND-capable device.
Eric

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Thu, 02 Jul 2009 16:56:03 +0200

Eric Levy-Abegnoli a écrit :
> A very realistic deployment scenario for SeND is going to be the one 
> of a mix of SeND and and non-SeND capable devices attached to the same 
 I just realized that sentence was very confusing. What I meant is that 
the non-SeND capable device have no way to prefer the SeND binding over 
the non-SeND one. So it has some value if the switch does that on its 
behalf.
Eric. 
> (in case of collision) - overriding the fist-come algorithm -, then 
> the switch will increase the security for everybody, not just the 
> subset or SeND-capable nodes.

---

From: Frank Xia <[email-masked]>
Date: Thu, 02 Jul 2009 14:12:56 -0500

Hi Marcelo

Please check..

BR
Frank
----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "Christian Vogt" <[email-masked]>; "SAVI Mailing List" 
<[email-masked]>
Sent: Thursday, July 02, 2009 5:03 AM
Subject: Re: [savi] A different trade off for SAVI

>> DAD defined in RFC4862  while ignoring Optimistic DAD defined in RFC4429 
>> which
> address, but it is still sending the DAD NSOL prior sending data packets, 
> right?
Frank=>No.   It is possible to sending data packets before any ND messages.

> right away a data packet. So, in that case, we could create the optimistic 
> binding and keep track if there is any DAD NADV as a reply to the original 
> DAD NSOL.
>
> Regards, marcelo
>
>
>>
>> BR
>> Frank
>>

---

From: Christian Vogt <[email-masked]>
Date: Fri, 3 Jul 2009 13:11:28 -0700

On Jul 1, 2009, Joel M. Halpern wrote:

> IP address.  (This is why I assumed no wireless.) If we are willing to
> require a topology where there are Savi-sensitive switches at every
> leaf, and that they have that kind of logging, then we would have a
> proposal to evaluate.

Joel -

Would it be a reasonable conclusion from your statement that logging
should be deactivate-able on a per-port basis?  This would help avoiding
excessive logging in SAVI devices with large port trunks -- logging,
which would be redundant if there are more SAVI devices further
downstream the port trunk.  It would also be in line with an earlier
conclusion that SAVI protection itself should be deactivate-able on a
per-port basis, to prevent excessive memory requirements in SAVI devices
with large port trunks.

- Christian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 03 Jul 2009 16:22:56 -0400

If one has sufficiently good leaf protection, it does seem sensibel to 
allow the sie adminsitrator to disable that on ports which are not leaf. 
  Whether that is a good idea depends upon what the rest of the plan 
looks like.  To me that looks like an incidental issue.

Yours,
Joel

---

From: Christian Vogt <[email-masked]>
Date: Fri, 3 Jul 2009 13:41:23 -0700

> Frank=>No.  It is possible to sending data packets before any ND

Right.

FWIW, draft-vogt-dna-relocation-01 explains the motivation for this
behavior of Optimistic DAD:  The DAD Neighbor Solicitation must wait for
MLD subscriptions to complete, which may take up to 1 second.  Waiting
for the DAD Neighbor Solicitation before sending regular data would
hence defeat the purpose of Optimistic DAD.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 3 Jul 2009 14:21:28 -0700

On Jul 2, 2009, Eric Levy-Abegnoli wrote:

> of
> benefit of SeND, and can be led to trust SeND node bogus bindings. If
> bindings with SeND credential can be preferred over the one without  
> (in
> case of collision) - overriding the fist-come algorithm -, then the
> SeND-capable nodes. So it's not only SEND-capable networks, it's any
> network with a few (even just one) SeND-capable device.

Right.

- Christian