Subject: Re: [savi] Your opinion on a different tradeoff for SAVI

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Jul 2009 10:24:35 +0200

catching up...

Christian Vogt escribió:
> On Jun 15, 2009, Guang and Marcelo wrote:
>
>>> Local bindings always are part of all the bindings in the network,
>>> because bindings are set up through DAD snooping, and DAD NS is a group
>>> cast message, not broad cast. Thus, attackers can still spoof the
>>> address of another host as long as it is not bound on the savi device
>>> along the packet path.
>>
>> right, but we can change that. I mean, we could simply require that SAVI
>> devices snoop all MLD messages and that DAD packets are forwarded to all
>> SAVI devices irrespectively whether there any host subscribed tot he
>> particular solicited node mcast group on that particular SAVI device.
>> That would essentially imply that all SAVI devices receive all DAD msgs.
>> Would that solve the problem?
>
>
> Do we really have to forward all DAD solicitations to solve the problem?
> Is there a problem to begin with?  I don't see why lack of a binding in
> a SAVI device would help an attacker hijacking an address.
>
> After all, a SAVI binding can only be created with a DAD solicitation
> that receives no response.  So even if a SAVI device did not see the DAD
> solicitation of the legitimate address owner, it will see the DAD
> response of the legitimate address owner in case an attacker is trying to
> hijack that owner's address.
>

but, the problem is that if the DAD is not seen by all SAVI devices and 
we are only filtering those addresses that do have a binding, then the 
solution is more weak.

I mean, suppose that we have a host A connected to SAVI device SA. host 
A performs DAD and the DAD NSOL only reaches SAVI device SA and does not 
reach SB.
this implies that any node connected to savi device SB can send packets 
with the source address of host A and this is really not so great

So, i think that in order for a solution that only drops packets where a 
binding exists, then we need to make sure that the binding exists in 
most of the cases. I would be ok to let pass packets in case the DAD msg 
was lost, but if by design the DAD will not reach all SAVI devices, i 
think the solution is not providing much protection

So bottom line.
In order for me, a solution that may be acceptable is one that:
- creates binding based on DAD
- distributes the DAD msg to all SAVI devices
- in case there is binding and the source address of the packet does not 
match the L2 anchor, drops the pakcet
- in case there is no binding for a data packet, it lets the packet through

Of course, the crux of the problem is how to make sure that the DAD msg 
is delivered to all SAVI devices and this is far from granted.

Regards, marcelo

> - Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Jul 2009 10:33:51 +0200

catching up...

Fred Baker escribió:
> I remain of the opinion that a switch is able to prevent its own 
> clients from using addresses they have not been assigned,

the problem here is how to define that the address has been assigned to 
a host.
It is clear in the case of DHCP, but it is far from obvious in the case 
of stateless address autoconf.

Basically, i don't think you can assume that if the SAVI has not seen 
the DAD packet, then the source address has not been legitimate assigned 
to the host.
DAD is inherently not reliable and if the DAD packet is lost, the DAD 
procedure is succesful from the host perspective (As opposed to the dhcp 
case, where, the protocol is reliable and if the packet is lost, the 
assignment is not succesful from the host perspective)

So, i don't think it is acceptable for SAVI to block a host that is 
using a source address for which the DAD msg was lost.

> and that this is sufficient for a network of SAVI devices. The costs 
> of a switch escalate if it has to have memory for devices that are not 
> its clients, meaning that SAVI is unlikely to get market traction in 
> this very cost-sensitive market if we force the switches to have large 
> memories.
so, what do you think is a reasonable size of the memory?

>
> the primary argument for a binding protocol is that there might be 
> some non-savi devices in the network.

there are several reasons why you may end up needed one.
I think one reason is that this one way of  dealing with packets that 
contain a legitmate source address and the DAD packet was lost. There 
maybe other ways of dealing with this

> I think the simpler solution is to tell people that they don't get the 
> benefits of SAVI in that environment.
so, what type of topology constraints do you suggest?

regards, marcelo

>
> On Jun 23, 2009, at 4:44 PM, Christian Vogt wrote:
>
>> _______________________________________________
>> savi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/savi
>
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Jul 2009 10:39:47 +0200

Fred Baker escribió:
>
> On Jun 23, 2009, at 4:41 PM, Christian Vogt wrote:
>
>> It is true that Marcelo's proposed FCFS variant does not protect unused
>> addresses.  It only protects addresses being used by a link neighbor.
>> But don't you think this alone is attractive?
>
> no, not at all.
>
> On a given /64 LAN, there are O(2^64) potential addresses that are not 
> being used. The 5 or 8 or 24 or maybe 4096 that are being used are nil 
> by comparison. The objective is not only to prevent hosts from 
> spoofing each other, but to provide a BCP 38 solution that forces them 
> to in fact use addresses they are supposed to be using.
>
> SAVI without protecting unused addresses is pointless.
So basically, what you are suggesting is to hardcode that if the SAVI 
device has not seen a DAD NSOL, then the address is not being used and 
then no packets with that soruce address can be forwarded, correct?

I think there are two problems with that:
- First, that the DAD packet can be lost, so the host has actually 
legimtate use of the address, but the SAVI device has not seen the DAD 
packet. So, such approach would block legitmate users
- Second, i am not sure how much guarantee this DAD procedure provides. 
I mean, if an attakcer wants to use an address that nobody else is 
using, it just sends the DAD apcket and then sends the data packet. The 
DAD procedure only protects from not using duplicate address i.e. not 
for protecting unused address, but for protecting from using addresses 
that are already in use by a neighbour.

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 02 Jul 2009 11:57:14 +0200

Christian Vogt escribió:
> On Jun 23, 2009, Fred Baker wrote:
>
>> I remain of the opinion that a switch is able to prevent its own clients
>> from using addresses they have not been assigned, and that this is
>> sufficient for a network of SAVI devices. The costs of a switch escalate
>> if it has to have memory for devices that are not its clients, meaning
>> that SAVI is unlikely to get market traction in this very cost-sensitive
>> market if we force the switches to have large memories.
>
> Fred -
>
> The FCFS variant we are considering exactly addresses your concern:
> Since lack of a binding cannot lead to false packet drops, bindings do
> not have to be explicitly copied across SAVI devices.

mmm, but this would imply that the protection is very low, right?
I mean, in this case, a given source addressmay have a binding in one 
savi device and not in other, so the source address is not protected in 
that SAVI device....

So, i think it is ok not to protect unused addresses (i fail to see how 
we could do this without reading much more into DAD that what it was 
originally designed for), so, i am ok to not protect a source address 
for which the original DAD was lost, since i see this as a rare event.
However, if the solution does not protect addresses for which the DAD 
apcket have not been lost, i am not sure we are providing a reasonable 
level of protection.

So, what i am trying to say, is that if we go this way, we must make 
sure that the DAD is distributed as much as possible including all SAVI 
devices and this will imply that all SAVI devices will contain all the 
source addresses in the link

> This reduces
> memory requirements.  In particular, bindings for a given address are
> only created in SAVI devices on the path of the corresponding DAD
> solicitation or DHCP address assignment.  The number of bindings for a
> given address can be reduced further by manually disabling SAVI
> protection on large port trunks.
>
>> the primary argument for a binding protocol is that there might be some
>> non-savi devices in the network. I think the simpler solution is to tell
>> people that they don't get the benefits of SAVI in that environment.
>
> FWIW:  The main argument is actually the prevention of false packet
> drops.
right

>   This affects SAVI solutions that drop packets in the absence of
> a binding.  A dedicated binding protocol can then ensure that the
> necessary bindings are in place, hence avoiding false packet drops.
>
right
Regards, marcelo

> Since Marcelo's proposed FCFS variant does NOT drop packets in the
> absence of a binding, I don't see the need for a dedicated binding
> protocol.  This is what I am explaining in my message below.
>
> - Christian
>
>
>
> On Jun 23, 2009, Christian Vogt wrote:
>
>>> response of the legitimate address owner in case an attacker is trying
>>> to hijack that owner's address.
>>>
>>> - Christian
>
>
>
>

---

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

> we are only filtering those addresses that do have a binding, then the

Ah, ok.  You want to increase the probability that SAVI devices have a
binding.  And the motivation for this is to enable SAVI protection for a
larger set of addresses -- not to avoid dropping legitimate packets.
This makes sense.

Of course, distributing bindings increases memory requirements for SAVI
devices, and consequently production costs.  This is clearly a
disadvantage.  On the other hand, I don't think we can avoid binding
distribution in any case, because it is required either:

- to avoid dropping legitimate packets, or

- to increase the set of addresses being protected.

The first applies if SAVI devices were to drop packets for which no
binding exists.  The second applies if SAVI devices were to forward
those packets.

Importantly, binding distribution is crucial in the first case, whereas
one may argue that it could be best-effort in the second case.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 04 Jul 2009 10:07:25 +0200

> larger set of addresses -- not to avoid dropping legitimate packets.
mmm, i would say to increase the scope of protection of the addresses 
that have a binding in a SAVI device
I mean, if the DAD is not received by some SAVI devices, then the 
address will not be protected in these devices.

> one may argue that it could be best-effort in the second case.
well, i agree it depends on the topology, but we don't want to end up 
with a very weak solution, since nobody will care about it.

Regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Sun, 5 Jul 2009 15:26:36 -0700

On Jul 4, 2009, marcelo bagnulo braun wrote:

> mmm, i would say to increase the scope of protection of the  
> addresses that
> have a binding in a SAVI device I mean, if the DAD is not received  
> by some
> SAVI devices, then the address will not be protected in these devices.

Yes.

> well, i agree it depends on the topology, but we don't want to end  
> up with
> a very weak solution, since nobody will care about it.

Absolutely.  But my point here is this:  Occasionally not having a
binding is OK if this leads to lower protection of a particular address.
It is not OK if this prevents a host from communicating.

Do you and the working group agree with this?

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 06 Jul 2009 09:58:57 +0200

Christian Vogt escribió:
>> that
>> have a binding in a SAVI device I mean, if the DAD is not received by 
>> some
>> with

i agree
of course the tricky part of this statement is how to determine what 
lower protection is still acceptable

---

From: Dong Zhang <[email-masked]>
Date: Thu, 09 Jul 2009 09:02:10 +0800

>It is not OK if this prevents a host from communicating.

I am not quit clear that when and how the occasional case happens. 
Could you please explain that?

Thx

------------------				 
Dong Zhang
2009-07-09

-------------------------------------------------------------
发件人：Christian Vogt
发送日期：2009-07-06 06:26:48
收件人：marcelo bagnulo braun
抄送：SAVI Mailing List; Guang Yao
主题：Re: [savi] Your opinion on a different tradeoff for SAVI

Yes.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Wed, 8 Jul 2009 18:26:45 -0700

> Could you please explain that?

Hi Dong Zhang -

The situation referred to here occurs when a SAVI device does not see a
successful DAD procedure or DHCP assignment for a particular address.

If said address is legitimate, then a drop-by-default behavior of SAVI
devices would cause loss of legitimate packets.  A forward-by-default
behavior would avoid such packet loss, albeit it would not protect said
address from hijacking either.

- Christian

---

From: Dong Zhang <[email-masked]>
Date: Thu, 09 Jul 2009 13:07:32 +0800

Hi Christian,
>address from hijacking either.
I know the problem. However, I want to make sure is how often can be called "occasionally".
I have not a concept about that. Is there a cirterion or a ratio? I mean how many times these
occasional cases happened can be tolerant, how many times can not be tolerant. Perhaps I miss
something previously.

Thank you

---

From: Alberto García <[email-masked]>
Date: Thu, 9 Jul 2009 10:39:06 +0200

Hi,
Dropping packets when a binding does not exist can lead to some occasional
but very problematic situations.
I add one case that I think it has not been commented before: when many
switches connect using a spanning tree protocol, the unavailability of a
switch, or a link belonging to the spanning tree triggers the propagation of
a Topology Change Notification (in RSTP jargon) frame, which is flooded
either to a subset of the tree or to the whole spanning tree (depending on
the location of the change, and the identity of the switches involved in the
change -i.e. root or not). If a port of a switch is affected by the topology
change, it must flush the addresses learned through that port (IEEE Std
802.1w-2001 also accepts to flush the address/port binding for all ports).
This must result in flushing also SAVI bindings. 
Therefore, hosts may be connected to a switch that has been always
available, so they won't send DADs again, but the SAVI binding for its
address in other switches be flushed and its packets dropped. 
Although switches or links may fail occasionally, they certainly do, and I
don't think it is acceptable to prevent communication in this case. RSTP is
built to recover reasonably fast on this situation, so adding a SAVI
solution with this approach defeats part of its purpose.

Other occasional situations that make DAD signaling unreliable are layer-2
networks that are connected, networks that power up at the same time and
RSTP takes more time to make the network functional than hosts to detect the
switches and send DAD.

Too many "occasionals", from my point of view, affecting to basic
functionality.

Regards,
Alberto

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
Dong
|  Zhang
|  Enviado el: jueves, 09 de julio de 2009 7:08
|  Para: Christian Vogt
|  CC: SAVI Mailing List; Guang Yao
|  Asunto: Re: [savi] Your opinion on a different tradeoff for SAVI
|  
|   Hi Christian,
|  >>> Absolutely.  But my point here is this:  Occasionally not having a
|  >>> binding is OK if this leads to lower protection of a particular
|  >>> address.
|  >>> It is not OK if this prevents a host from communicating.
|  >>
|  >> I am not quit clear that when and how the occasional case happens.
|  >> Could you please explain that?
|  >
|  >Hi Dong Zhang -
|  >
|  >The situation referred to here occurs when a SAVI device does not see a
|  >successful DAD procedure or DHCP assignment for a particular address.
|  >
|  >If said address is legitimate, then a drop-by-default behavior of SAVI
|  >devices would cause loss of legitimate packets.  A forward-by-default
|  >behavior would avoid such packet loss, albeit it would not protect said
|  >address from hijacking either.
|  >
|  I know the problem. However, I want to make sure is how often can be
called
|  "occasionally".
|  I have not a concept about that. Is there a cirterion or a ratio? I mean
how many
|  times these
|  occasional cases happened can be tolerant, how many times can not be
tolerant.
|  Perhaps I miss
|  something previously.
|  
|  Thank you
|  
|  
|  
|  _______________________________________________
|  savi mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi

---

From: Christian Vogt <[email-masked]>
Date: Thu, 9 Jul 2009 12:12:30 -0700

Thank you, Alberto, for these comments.  In addition, I would like to
re-emphasize the following:

A drop-by-default behavior, in which SAVI devices drop packets for which
they have no binding, doesn't have a benefit in the first place if used
in networks that permit SLAAC.  The reason is that, in those networks, a
malicious host can create a binding by itself, by sending a DAD Neighbor
Solicitation message.

Therefore, rather than pondering whether occasional loss of legitimate
packets is a show-stopper or not for using the drop-by-default behavior
in networks that permit SLAAC, I suggest we rather agree that the drop-
by-default behavior just doesn't make sense in those networks.

- Christian

On Jul 9, 2009, Alberto García wrote:

> Hi, Dropping packets when a binding does not exist can lead to some
> occasional but very problematic situations. I add one case that I  
> think
> it has not been commented before: when many switches connect using a
> spanning tree protocol, the unavailability of a switch, or a link
> belonging to the spanning tree triggers the propagation of a Topology
> Change Notification (in RSTP jargon) frame, which is flooded either  
> to a
> subset of the tree or to the whole spanning tree (depending on the
> location of the change, and the identity of the switches involved in  
> the
> change -i.e. root or not). If a port of a switch is affected by the
> topology change, it must flush the addresses learned through that port
> (IEEE Std 802.1w-2001 also accepts to flush the address/port binding  
> for
> all ports). This must result in flushing also SAVI bindings.  
> Therefore,
> hosts may be connected to a switch that has been always available, so
> they won't send DADs again, but the SAVI binding for its address in
> other switches be flushed and its packets dropped. Although switches  
> or
> links may fail occasionally, they certainly do, and I don't think it  
> is
> acceptable to prevent communication in this case. RSTP is built to
> recover reasonably fast on this situation, so adding a SAVI solution
> with this approach defeats part of its purpose.
>
> Other occasional situations that make DAD signaling unreliable are
> layer-2 networks that are connected, networks that power up at the  
> same
> time and RSTP takes more time to make the network functional than  
> hosts
> to detect the switches and send DAD.
>

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Fri, 10 Jul 2009 11:56:49 +0200

Christian,
> by-default behavior just doesn't make sense in those networks.
Let me play devil advocate here. Forcing the attacker to "register" (it 
is really what it would be if we were dropping packets without a 
binding) his binding prior to sending traffic would have some benefits. 
It would make a lot easier for the switch to control/limit the number of 
bindings allowed (from a given mac or from a given port).
Some attacks rely on using diferent L3 addresses for each packets. On 
such attack could actually target  the logging mechanism which has been 
proposed here. One way to mitigate it is to keep a state per L3 address, 
and limit the number of
such state till we start dropping. The binding table seems to be the 
right place for these state.
So I am not sure it make no sense as what you claim.
Eric
 
>> occasional but very problematic situations. I add one case that I think
>> Change Notification (in RSTP jargon) frame, which is flooded either to a
>> location of the change, and the identity of the switches involved in the
>> (IEEE Std 802.1w-2001 also accepts to flush the address/port binding for
>> all ports). This must result in flushing also SAVI bindings. Therefore,
>> other switches be flushed and its packets dropped. Although switches or
>> links may fail occasionally, they certainly do, and I don't think it is
>> layer-2 networks that are connected, networks that power up at the same
>> time and RSTP takes more time to make the network functional than hosts

---

From: Alberto García <[email-masked]>
Date: Fri, 10 Jul 2009 12:39:44 +0200

Hi

|  -----Mensaje original-----
|  De: Eric Levy-Abegnoli [mailto:[email-masked]]
|  Enviado el: viernes, 10 de julio de 2009 11:57
|  Para: Christian Vogt
|  CC: Dong Zhang; Alberto García; SAVI Mailing List; Guang Yao
|  Asunto: Re: [savi] Your opinion on a different tradeoff for SAVI
|  
|  Christian,
|  Christian Vogt a écrit :
|  > Thank you, Alberto, for these comments.  In addition, I would like to
|  > re-emphasize the following:
|  >
|  > A drop-by-default behavior, in which SAVI devices drop packets for
which
|  > they have no binding, doesn't have a benefit in the first place if used
|  > in networks that permit SLAAC.  The reason is that, in those networks,
a
|  > malicious host can create a binding by itself, by sending a DAD
Neighbor
|  > Solicitation message.
|  >
|  > Therefore, rather than pondering whether occasional loss of legitimate
|  > packets is a show-stopper or not for using the drop-by-default behavior
|  > in networks that permit SLAAC, I suggest we rather agree that the drop-
|  > by-default behavior just doesn't make sense in those networks.
|  >
|  Let me play devil advocate here. Forcing the attacker to "register" (it
|  is really what it would be if we were dropping packets without a
|  binding) his binding prior to sending traffic would have some benefits.
|  It would make a lot easier for the switch to control/limit the number of
|  bindings allowed (from a given mac or from a given port).

Why? It seems that what you need for the control you want is to have an
"unbounded address" table in which you register the addresses being
forwarded for which there is no binding. Then, apply for this unbounded
address table any kind of limitation you want, as you suggest. This
unbounded address table would have for an attacker exactly the same
addresses as the binding table in the case you suggest.

>From my point of view, the nice thing of DAD is that you give the
opportunity to other hosts in the network to stop address configuration in a
host, and this could make a SAVI switch aware that it is not a good idea to
create a binding for the attacker. Yes, this is nice. The problem is that if
you want to obtain this (increased security), you have to scarify the
communication of legitimate users that may suffer from its binding state not
being created, or lost during its communication, due to many reasons being
stated in the mailing list. 
I don't think that this basic functionality could be compromised. 

If the kind of situation that you mentioned is to be further protected, by
checking if a different binding for this address exists in other switches, a
SAVI protocol should be the option. 

Regards,
Alberto

|  Some attacks rely on using diferent L3 addresses for each packets. On
|  such attack could actually target  the logging mechanism which has been
|  proposed here. One way to mitigate it is to keep a state per L3 address,
|  and limit the number of
|  such state till we start dropping. The binding table seems to be the
|  right place for these state.
|  So I am not sure it make no sense as what you claim.
|  Eric
|  
|  > - Christian
|  >
|  >
|  >
|  > On Jul 9, 2009, Alberto García wrote:
|  >
|  >> Hi, Dropping packets when a binding does not exist can lead to some
|  >> occasional but very problematic situations. I add one case that I
think
|  >> it has not been commented before: when many switches connect using a
|  >> spanning tree protocol, the unavailability of a switch, or a link
|  >> belonging to the spanning tree triggers the propagation of a Topology
|  >> Change Notification (in RSTP jargon) frame, which is flooded either to
a
|  >> subset of the tree or to the whole spanning tree (depending on the
|  >> location of the change, and the identity of the switches involved in
the
|  >> change -i.e. root or not). If a port of a switch is affected by the
|  >> topology change, it must flush the addresses learned through that port
|  >> (IEEE Std 802.1w-2001 also accepts to flush the address/port binding
for
|  >> all ports). This must result in flushing also SAVI bindings.
Therefore,
|  >> hosts may be connected to a switch that has been always available, so
|  >> they won't send DADs again, but the SAVI binding for its address in
|  >> other switches be flushed and its packets dropped. Although switches
or
|  >> links may fail occasionally, they certainly do, and I don't think it
is
|  >> acceptable to prevent communication in this case. RSTP is built to
|  >> recover reasonably fast on this situation, so adding a SAVI solution
|  >> with this approach defeats part of its purpose.
|  >>
|  >> Other occasional situations that make DAD signaling unreliable are
|  >> layer-2 networks that are connected, networks that power up at the
same
|  >> time and RSTP takes more time to make the network functional than
hosts
|  >> to detect the switches and send DAD.
|  >>
|  >> Too many "occasionals", from my point of view, affecting to basic
|  >> functionality.
|  >>
|  >> Regards,
|  >> Alberto
|  >
|  >
|  >
|  > _______________________________________________
|  > savi mailing list
|  > [email-masked]
|  > https://www.ietf.org/mailman/listinfo/savi
|  >

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Fri, 10 Jul 2009 14:10:32 +0200

Alberto ,
> addresses as the binding table in the case you suggest.
I am sure one can invent many ways of doing the same thing. Your way has 
issues by using data traffic as control traffic. These are often kept 
separated, for good reasons.
My point was to suggest that the question might be more complex than no 
binding-drop/binding no-drop..
The policy could be drop-if-no-binding and drop-if-limit-reached. It 
does not address the concerns raised about dropping improperly, but I 
think it does address -to some extend-  the point of attackers creating 
bindings prior to launch an attack.
Eric

---

From: Christian Vogt <[email-masked]>
Date: Sat, 11 Jul 2009 16:52:38 -0700

Eric -

> bindings allowed (from a given mac or from a given port).

You are proposing to limit the number of IP addresses a host can use.
That's interesting.  Have you made some analysis on potential drawbacks
this could have?  One drawback would, of course, be a risk of dropping
legitimate packets after loss of DAD packets; we discussed this before.
Are there other drawbacks?  Perhaps a need to manually configure switch
ports according to whether they attach to a host directly, or to a port
trunk?  Port trunks clearly would need higher limits on the number of
permitted IP addresses than ports that attach to hosts directly.

- Christian

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Thu, 16 Jul 2009 15:01:06 +0200

Christian,
> You are proposing to limit the number of IP addresses a host can use.
that would have a couple a benefits: protection against an attacker 
trying to fill the switch binding table, as well as preventing an 
attacker from (dad-)registering one distinct address per packet sent, 
just for the sake of not being catched.
It has also the potential of controling number of addresses per 
node/mac/port, but this goal  is different, and is not what I had in mind).
> permitted IP addresses than ports that attach to hosts directly
Yes if the limit is per-port. No if the limit is per mac.
Eric
> .

---

From: Christian Vogt <[email-masked]>
Date: Thu, 16 Jul 2009 10:05:43 -0700

Forked from thread "Your opinion on a different tradeoff for SAVI".

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

> just for the sake of not being catched. It has also the potential of
> controling number of addresses per node/mac/port, but this goal  is
> different, and is not what I had in mind).

Yes, but let's be careful.  Benefit #2 is certainly an advantage, i.e.,
preventing an attacker from registering a arbitrary amount of IP
addresses.  It basically provides you a means to protect unregistered IP
addresses.  But for benefits #1 and #3, things are a bit different:
Benefit #1, preventing an attacker from filling the binding table, is
something that you also get when unregistered IP addresses are not
protected.  And benefit #3, controlling the number of addresses per
binding anchor, is not a goal of SAVI.

So let's focus on benefit #2.

> Yes if the limit is per-port. No if the limit is per mac.

Right.  But let's focus on ports as binding anchors for now.  That's our
working assumption, because MAC addresses as binding anchors are
spoofable without link-layer protection, and hence significantly reduce
the benefit of SAVI in the first place.  This includes any extra
benefits you may get from limiting the number of IP addresses per
binding anchor.

My conclusion is that a limit on the number of IP addresses per binding
anchor can provide a means for protecting unregistered IP addresses in
networks where SLAAC is permitted.  The cost of this is careful manual
configuration in the case where binding anchors are switch ports.
Careful, because misconfiguration can have the consequence of preventing
legitimate communications.  Agree?

- Christian

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Fri, 17 Jul 2009 18:08:20 +0200

> legitimate communications.  Agree?
Yes, absolutely.
Eric