Subject: [savi] forwarding datagrams without bindings

From: Fred Baker <[email-masked]>
Date: Mon, 1 Jun 2009 09:11:38 -0700

Marcelo will, when he gets a few minutes (he is traveling this week),  
flesh out the idea that he discussed on the call this morning. While  
I'm thinking about it, I would like to summarize the thought and the  
question that was running through my head.

The discussion related to whether we should set up SAVI bindings using  
FCFS only on control datagrams or also on data exchanges. He suggested  
that we only set up binding state on control packets but that we  
permit data packets that correspond to no binding (eg, from is an  
address that nobody in the LAN is known to be using) to pass.

My question goes to the heart of what we are trying to do here. It  
seems to me that SAVI is trying, ultimately, to guarantee that if one  
system sends a datagram to another system, the second system's reply  
will make it back to the first system barring system or network  
failure. Address spoofing is the obvious attack that we have been  
trying to prevent - the use of a source address such that A sends to B  
and B's reply is delivered to some third party. But it seems to me  
that address anonymization is also an attack that the technology is  
trying to prevent - if A sends to B, B might reply but the network be  
systemically unable to deliver it and the original source of the  
datagram is not determinable. In short, I think SAVI is trying to do  
more than "prevent spoofing", it is trying to ensure that datagrams in  
the wild are valid and useful as opposed to being attack traffic. To  
do that, the point is not the negative statement that "it doesn't  
spoof someone else's address", the point is the positive statement  
that "it uses its own address".

To make that positive statement, whether we set up bindings on control  
or data packets, we can only allow datagrams to pass that originate  
from addresses that are associated with the putative sender, apart  
from systems that routinely originate datagrams at L2 from other L3  
addresses, such as routers do.

In case what I just said is not clear, let me put together an attack  
example. We often see DDOS attacks in which some large number of  
systems simultaneously send a datagram to some targeted address using  
a random source address. To track these back, what operations folks  
try to do is track the trajectory of those attacking datagrams. The  
effectiveness of the attack is limited by BCP 38 filters (uRPF or  
whatever), which only allow packets through for which the random  
number in fact selected the right source prefix. But in IPv6,  
selecting the right /64 still means one has 2^64 interface identifiers  
to choose from, and that the probability of randomly selecting that of  
a neighbor is pretty low. So while preventing address spoofing is an  
obvious goal, simply doing that doesn't prevent attacks in which the  
source address is incorrect; one also has to prevent address  
anonymization.

Which brings us back to the question of address binding. If what we  
are doing is preventing systems from sending from addresses that are  
not their own, then there is no real question of interoperating with  
non-SAVI switches in other parts of the network. SAVI switches somehow  
know which ports connect to hosts (as opposed to routers, switch/ 
switch trunks, and some kinds of servers), and drop datagrams they  
send that are not from addresses bound to them. If one wants to have a  
SAVI network, one doesn't try to be backward compatible with non-SAVI  
equipment, one replaces non-SAVI equipment with SAVI equipment,  
hopefully by an upgrade for large switches, but for consumer grade  
equipment by replacing it. The one case where that does not follow is  
a desktop switch, in which the larger switch may not be able to  
distinguish between a virtual host and a set of hosts connected by a 5  
port potentially-non-SAVI switch and that to the wall; there, the big  
switch might associate IPv6 addresses with MAC Addresses and those in  
turn with a port.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 07 Jun 2009 21:12:10 +0200

FWIW, i think it is very important to understand the security 
implications of this alternative approach. I am not sure i understnad 
the implications myself, so, this dicussion is useful for that purpose.

Fred Baker escribió:
> and B's reply is delivered to some third party.
I am not sure how this could happen with the proposed approach, since 
the attacker cannot use the address of a real host, since the real host 
would normally had perform DAD, so a binding would exist in the SAVI 
device, so packets coming from the attacker with that address would be drop.
> But it seems to me that address anonymization is also an attack that 
> the technology is trying to prevent - if A sends to B, B might reply 
> but the network be systemically unable to deliver it and the original 
> source of the datagram is not determinable.
not dropping the packet doesn't mean that the SAVI device cannot log the 
occurrence of such data packet,s which would allow to trace back to the 
lower anchor of those packets.

> In short, I think SAVI is trying to do more than "prevent spoofing", 
> it is trying to ensure that datagrams in the wild are valid and useful 
> as opposed to being attack traffic. To do that, the point is not the 
> negative statement that "it doesn't spoof someone else's address", the 
> point is the positive statement that "it uses its own address".
>
I fail to see why these attacking hosts would simply do the DAD for the 
addresses they want to use and get access to the savi filters by doing so.
I mean, if you have a solution that drops packets if there is no 
binding, then the attacker simply needs to perform the DAD , create the 
binding and then send the packets (which would be the easier thing to 
do, cause that is what OS do by default)

> not their own,

So, there are 2 types of addresses in a link. the addresses that already 
belong to a host and the addresses that don't belong to anyone.
The proposed approach of forwarding packets wihtout bindings prevents 
the attacker to use the address of other hosts.
What the proposed approach doens't do is to prevent an attacker to use 
addresses that do not belong to any host. But, if they do not belong to 
nay host, the attacker can simply perform DAD and create the binding and 
own the address. So, what is that we are missing form the security 
perspective in this appraoch?

Regards, marcelo

> then there is no real question of interoperating with non-SAVI 
> switches in other parts of the network. SAVI switches somehow know 
> which ports connect to hosts (as opposed to routers, switch/switch 
> trunks, and some kinds of servers), and drop datagrams they send that 
> are not from addresses bound to them. If one wants to have a SAVI 
> network, one doesn't try to be backward compatible with non-SAVI 
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: Christian Vogt <[email-masked]>
Date: Tue, 9 Jun 2009 20:49:46 -0700

Forked from thread:  "Forwarding datagrams without bindings."

Fred and all -

A few personal comments, which I would like to state outside of my role
as a working group chair:  Fred, you are calling for a SAVI solution
that prevents attackers from hijacking unused addresses.  I think you
are too ambitious.

The only solution proposal on the table that satisfies your requirement
is CPS, and we have seen that CPS suffers from the problem of occasional
false packet drops.  While I would love to see a solution that satisfies
your requirement without the risk of false packet drops, I believe that
such a solution does not exist.  Let me explain why:

To prevent attackers from hijacking unused addresses, you need a method
to distinguish between used and unused addresses.  This, in turn, means
that you need a method by which hosts can announce ownership of an
address.  Such a method must be reliable, since failure to successfully
announce ownership of an address could result in false drops of packets
originating from that address.  Unfortunately, in IPv6, due to Stateless
Address Autoconfiguration, there is no reliable way in which hosts can
announce ownership of an address.  DAD, which does serve the function of
announcing address ownerships, is only best-effort.  Therefore, if you
were to drop packets from apparently unused addresses in IPv6, you would
risk that those packet drops are false because the corresponding address
ownership announcement might have been unsuccessful.  This is why, in
IPv6, preventing attackers from hijacking unused addresses inevitably
implies a risk of false packet drops.

A related question is how important it is in the first place to prevent
attackers from hijacking unused addresses in IPv6.  After all, the
boundary between an IPv6 address being unused and being used is
negligible:  All an attacker needs to do to turn an unused address into
a used address is to send a DAD Neighbor Solicitation.

In summary, I think that preventing attackers from hijacking unused
addresses is (1) not possible without introducing a risk of false packet
drops, and (2) not absolutely necessary.

What do you think?  Does this make sense?

- Christian

On Jun 1, 2009, Fred Baker wrote:

> I'm
> thinking about it, I would like to summarize the thought and the
> permit
> data packets that correspond to no binding (eg, from is an address  
> that
> nobody in the LAN is known to be using) to pass.
>
> seems
> to me that SAVI is trying, ultimately, to guarantee that if one system
> sends a datagram to another system, the second system's reply will  
> make
> it back to the first system barring system or network failure. Address
> spoofing is the obvious attack that we have been trying to prevent -  
> the
> use of a source address such that A sends to B and B's reply is
> delivered to some third party. But it seems to me that address
> anonymization is also an attack that the technology is trying to  
> prevent
> - if A sends to B, B might reply but the network be systemically  
> unable
> to deliver it and the original source of the datagram is not
> determinable. In short, I think SAVI is trying to do more than  
> "prevent
> spoofing", it is trying to ensure that datagrams in the wild are valid
> and useful as opposed to being attack traffic. To do that, the point  
> is
> not the negative statement that "it doesn't spoof someone else's
> address", the point is the positive statement that "it uses its own
> address".
>
> from
> addresses that are associated with the putative sender, apart from
> systems that routinely originate datagrams at L2 from other L3
> systems
> simultaneously send a datagram to some targeted address using a random
> source address. To track these back, what operations folks try to do  
> is
> track the trajectory of those attacking datagrams. The effectiveness  
> of
> the attack is limited by BCP 38 filters (uRPF or whatever), which only
> allow packets through for which the random number in fact selected the
> right source prefix. But in IPv6, selecting the right /64 still means
> one has 2^64 interface identifiers to choose from, and that the
> probability of randomly selecting that of a neighbor is pretty low. So
> while preventing address spoofing is an obvious goal, simply doing  
> that
> doesn't prevent attacks in which the source address is incorrect; one
> also has to prevent address anonymization.
>
> are
> doing is preventing systems from sending from addresses that are not
> their own, then there is no real question of interoperating with
> switch
> equipment by replacing it. The one case where that does not follow  
> is a
> desktop switch, in which the larger switch may not be able to

---

From: "Greg Daley" <[email-masked]>
Date: Wed, 10 Jun 2009 14:08:14 +1000

Hi Chris, 

I think that if a prefix must be statefully configured, it would be
possible to make use of DHCPv6 to 
control address allocation for those prefixes.  Devices could be
configured with such prefixes,
or identify them by seeing Router Advertisements.

Devices which do not get addresses allocated via DHCP then do not get
transmission rights.

This is essentially what some deployed products do today with IPv4.  It
is fairly reliable, although
I personally have reservations about what should be done in the case of
state loss on the snooping device
(for IPv4).   

This may actually be an important use case:  Spoofing on address managed
networks.

Greg Daley
Security Consultant
NetStar Australia Pty Ltd

E-mail: [email-masked]
Mobile: +61 401 772 770
Direct: +61 3 8532 4042
Fax:    +61 3 8532 4032
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Vogt
Sent: Wednesday, 10 June 2009 1:50 PM
To: Fred Baker; SAVI Mailing List
Subject: [savi] On Protecting Unused Addresses in IPv6

Fred and all -

- Christian

> trying to prevent
> unable to deliver it and the original source of the datagram is not 
> "prevent spoofing", it is trying to ensure that datagrams in the wild 
> are valid and useful as opposed to being attack traffic. To do that, 
> the point is not the negative statement that "it doesn't spoof someone

> else's address", the point is the positive statement that "it uses its

> own address".

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 10 Jun 2009 10:28:59 +0200

Christian Vogt escribió:
> that prevents attackers from hijacking unused addresses.

I fail to see what this means.
Whether you use CPS or FCFS, an attacker can simply send a DAD and 
acquire an address that is unused...

So what exactly means to prevent hijacking of unused addresses to you?
>   I think you
> is CPS,

i disagree.
You can use FCFS and eventually a savi protocol to propagate the 
information and you reach a similar level of security (wihtout the false 
drop problem)

> and we have seen that CPS suffers from the problem of occasional
i agree with all the argument above, i.e. you cannot rely on DAD to 
grant access to the network. My only discrpancy is that DAD does not 
actually provide hijacking of unused addresses since an attacker can 
perform dad as well an get the address (bypassing DAD)

In other words, i don't understand what it means to protect an unused 
address in the stateless autoconf case

> a used address is to send a DAD Neighbor Solicitation.
exactly!

> addresses is 

i think these are true for using DAD to grant access to the network,
> (1) not possible without introducing a risk of false packet
>> flesh out the idea that he discussed on the call this morning. While I'm
>> that we only set up binding state on control packets but that we permit
>> data packets that correspond to no binding (eg, from is an address that
>> My question goes to the heart of what we are trying to do here. It seems
>> sends a datagram to another system, the second system's reply will make
>> spoofing is the obvious attack that we have been trying to prevent - the
>> anonymization is also an attack that the technology is trying to prevent
>> - if A sends to B, B might reply but the network be systemically unable
>> determinable. In short, I think SAVI is trying to do more than "prevent
>> and useful as opposed to being attack traffic. To do that, the point is
>> or data packets, we can only allow datagrams to pass that originate from
>> example. We often see DDOS attacks in which some large number of systems
>> source address. To track these back, what operations folks try to do is
>> track the trajectory of those attacking datagrams. The effectiveness of
>> while preventing address spoofing is an obvious goal, simply doing that
>> Which brings us back to the question of address binding. If what we are
>> know which ports connect to hosts (as opposed to routers, switch/switch
>> equipment by replacing it. The one case where that does not follow is a
> ------------------------------------------------------------------------
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 10 Jun 2009 10:31:28 +0200

> or identify them by seeing Router Advertisements.

mmm, this would be essentially a subset of what ingress filtering does, 
right? i mean verifying that the prefix comes from the subnet that the 
prefix was assigned.
The current scope of SAVI assumes that we have ingress filtering and 
attempts to increase the security i.e. we are assuming that the prefix 
cannot be spoofed, and we try to say something about the address.

Regards, marcelo

---

From: "Greg Daley" <[email-masked]>
Date: Thu, 11 Jun 2009 10:50:09 +1000

Hi Marcelo,

Sorry to misdirect the conversation, the issue is about knowledge of existing address state,
and the inability of most IPv6 protocols to handle this.

DHCPv6 is placed here as an example that the protection is available under some constraints.

> > possible to make use of DHCPv6 to control address allocation for those 
> > prefixes.  Devices could be configured with such prefixes, or identify 
> > them by seeing Router Advertisements.
> >   

> mmm, this would be essentially a subset of what ingress filtering does, right?
> i mean verifying that the prefix comes from the subnet that the prefix was  assigned.

The verification is not the important part of the process.  The important part is the certainty
that all address allocations (for a non link-local prefix) must come from a valid DHCP Relay or Server.

> The current scope of SAVI assumes that we have ingress filtering and attempts to
> increase the security i.e. we are assuming that the prefix cannot be spoofed, and we try to say something about the address.

This has nothing to do with ingress filtering, as all communications for address configuration
are link-local.

The inference that addresses must use DHCP to bind addresses in a particular prefix is made either:

a) via manual DHCPv6 snooping switch configuration (for one or all on-link global prefixes)

or

b) by monitoring the Router Advertisements' own Prefix Information Options (which may also have SEND
   authorization).

Once the inference is made (about a global prefix), only DHCP link-local messages (and the mechanisms to bootstrap link-local
addresses) would be allowed by LAN switch ports.  Reception of a DHCPv6 REPLY messages with an address binding would create state.

Some exceptions for DAD defence may be allowed for responses to Neighbour Solicitation from unknown ports (not yet explored).  
All other source address presentations from unknown ports would be dropped.

DHCPv6 message monitoring mechanisms could also be used to create ingress filtering in adjacent LAN switches when DHCPv6-PD is in use.

In terms of motivation, this is not intended to resolve the entire situation for IPv6 access networks, but
should provide access network Global Address to switch port mappings in controlled addressing domains.
The mechanism described is reliable in that it makes use of DHCPv6's retransmission timers, and the state created by the
allocation of addresses by using the (Request, Renew, Rebind, Release)/Reply exchange.

Greg

---

From: Christian Vogt <[email-masked]>
Date: Thu, 11 Jun 2009 13:14:59 -0700

Greg -

If I understand you correctly, you are proposing a "DHCP-only mode" for
SAVI, for use in networks where Stateless Address Autoconfiguration is
disabled.  In DHCP-only mode, due to DHCP exchanges being reliable, SAVI
devices could drop packets without corresponding binding without risking
false packet drops.  Please correct me if I misinterpreted your email.

I think your observations are correct.  Yet we have to analyze what the
implications of a DHCP-only mode would be.

The proposed DHCP-only option was discussed before in the working group,
although this discussion hasn't gotten far yet.  One of the difficulties
is to prevent spoofing of DHCP messages.  Another is to prevent SAVI
devices from getting tricked into DHCP-only mode.  Especially the latter
would be a disaster in networks where no DHCP is used.

- Christian

On Jun 9, 2009, Greg Daley wrote:

> is fairly reliable, although I personally have reservations about what
> should be done in the case of state loss on the snooping device (for
> IPv4).
>

---

From: Christian Vogt <[email-masked]>
Date: Thu, 11 Jun 2009 13:34:23 -0700

> I fail to see what this means.

Marcelo -

The discussion Fred initiated was about whether or not to protect
addresses without a corresponding binding.  These addresses are what I
called "unused" in my previous email.  After all, for addresses that are
used legitimately, the modified FCFS approach that you had been
describing would normally have a binding -- barring premature binding
expiration or loss of DAD packets.

The conclusion is hence that the modified FCFS approach may actually be
good enough.  After all, its only disadvantage is that packets from
unused addresses are not discarded.  But since all that is needed to
turn an unused address into a used address is DAD, there is not much
value in discarding packets from unused addresses anyway.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 11 Jun 2009 23:28:36 +0200

> would be a disaster in networks where no DHCP is used.

Other potnetial issues include:
- how to recover the binding state when the savi devices reboots
- how to deal with mobility like scenarions, where the two dhcp 
exchanges for the same address traverse different set of savi devices 
(woudl this imply that 2 savi devices have different bindings for the 
same address? would this cause any problem?)

Regards, marcelo

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 15 Jun 2009 12:59:14 +0800

We carefully discussed the default forwarding, we have some considerations:

1
Default forwarding will make the attacker easy to use it to launch spoofing 
packets:
1) When the SAVI switch directly attached to the source host lost DAD (a 
very low possibility case, CPS need to be enhanced in this case), both legal 
user and attacker under the same SAVI switch could send packets.
2) Even the SAVI switch directly attached to the source host get the DAD 
(the most usual case, and CPS works perfectly in this case), other switches 
in the same link may still lost the DAD (due to the DAD multicasting 
mechanism, it's not a low possibility case. Another reason is the link 
distance increasing brings more possibility to lost packets). Which means, 
host under other switches in the same link may don't have the binding. Then 
becaue of the default forwarding rule, attackers under those switches could 
send spoofing packets out.

So that's the shortcomings of default forwarding (decrease the security 
level),then it doesn't meet the goal of SAVI and I also don't think the 
users will like it.

2
I think SAVI device should bring more security,
so the default action should be dropping packets before binding is set up.
Today, every 802.1x device will drop packets without passing 
authentication,and we didn't see any problem.
So the default dropping is OK for users.

The requirement of default dropping is actually how to make the binding more 
accurate.
The only problem of CPS is that some DAD packet may be lost in the directly 
attached SAVI switch (in a very low possibility).
A easy way to fix it is to make DAD redundant (like what IPv4 did, requires 
sending 3 packets,which is easy to be implemented). Certainly, we could find 
other way to enhance DAD. Any idea is welcomed.
Anyway, I think default dropping will be the right approach (to meet the 
goal of SAVI and anti-spoofing).

thanks,
Jun Bi

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Fred Baker" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Sent: Monday, June 08, 2009 3:12 AM
Subject: Re: [savi] forwarding datagrams without bindings

Fred Baker escribió:
> thinking about it, I would like to summarize the thought and the question 
> that was running through my head.
>
> sends a datagram to another system, the second system's reply will make it 
> back to the first system barring system or network failure. Address 
> use of a source address such that A sends to B and B's reply is delivered 
> to some third party.
> But it seems to me that address anonymization is also an attack that the 
> technology is trying to prevent - if A sends to B, B might reply but the 
> network be systemically unable to deliver it and the original source of 
> the datagram is not determinable.

> In short, I think SAVI is trying to do more than "prevent spoofing", it is 
> trying to ensure that datagrams in the wild are valid and useful as 
> opposed to being attack traffic. To do that, the point is not the negative 
> statement that "it doesn't spoof someone else's address", the point is the 
> positive statement that "it uses its own address".
>
> To make that positive statement, whether we set up bindings on control or 
> data packets, we can only allow datagrams to pass that originate from 
> addresses that are associated with the putative sender, apart from systems 
> that routinely originate datagrams at L2 from other L3 addresses, such as 
> routers do.
>
>
> right source prefix. But in IPv6, selecting the right /64 still means one 
> has 2^64 interface identifiers to choose from, and that the probability of 
> randomly selecting that of a neighbor is pretty low. So while preventing 
> address spoofing is an obvious goal, simply doing that doesn't prevent 
> attacks in which the source address is incorrect; one also has to prevent 
> address anonymization.

> doing is preventing systems from sending from addresses that are not their 
> own,

Regards, marcelo

> then there is no real question of interoperating with non-SAVI switches in 
> other parts of the network. SAVI switches somehow know which ports connect 
> to hosts (as opposed to routers, switch/switch trunks, and some kinds of 
> servers), and drop datagrams they send that are not from addresses bound 
> to them. If one wants to have a SAVI network, one doesn't try to be 
> backward compatible with non-SAVI equipment, one replaces non-SAVI 
> equipment with SAVI equipment, hopefully by an upgrade for large switches, 
> but for consumer grade equipment by replacing it. The one case where that 
> does not follow is a desktop switch, in which the larger switch may not be 
> able to distinguish between a virtual host and a set of hosts connected by 
> a 5 port potentially-non-SAVI switch and that to the wall; there, the big 
> switch might associate IPv6 addresses with MAC Addresses and those in turn 
> with a port.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 15 Jun 2009 17:04:19 +0200

Jun Bi escribió:
> Default forwarding will make the attacker easy to use it to launch 
> spoofing packets:
> 1) When the SAVI switch directly attached to the source host lost DAD 
> (a very low possibility case, CPS need to be enhanced in this case), 
> both legal user and attacker under the same SAVI switch could send 
> packets.
sure,
So the options here are either we log the occurence of these packets, or 
we create a binding with a data packet (the first data packet)
It is perfectly ok to create a binding with the data packet. The 
question at this point is how do you deal with the usage fo this address 
in other switches.
One option would be to introduce some form of SAVI protocol. None of us 
like this, but, maybe the only way out. The other option would be to 
keep this binding information only to this switch and we don't care if 
the address is used in other switch. That would allow the usage of the 
same soruce address in another switech, but not in the same switch. this 
woudl provide some additional level of protection without the complexity 
of a savi protocol. (not full protection though)

> 2) Even the SAVI switch directly attached to the source host get the 
> DAD (the most usual case, and CPS works perfectly in this case), other 
> switches in the same link may still lost the DAD (due to the DAD 
> multicasting mechanism, it's not a low possibility case.
I understnad you are referring to the case the SAVI device does not has 
any host subscribed to the the particular sol mcst group? It would be 
possible to require that all DAD msgs are forwarded to all the SAVI 
devices, even if there is no host subscribed to them

> Another reason is the link distance increasing brings more possibility 
> to lost packets). Which means, host under other switches in the same 
> link may don't have the binding. Then becaue of the default forwarding 
> rule, attackers under those switches could send spoofing packets out.
>
> So that's the shortcomings of default forwarding (decrease the 
> security level),then it doesn't meet the goal of SAVI and I also don't 
> think the users will like it.
>
the problem with default discarding, unless DAD is received is that 
hosts are disconnected from the network if the DAD packet is lost.

> So the default dropping is OK for users.
note that authentication exchanges are designed to be reliable and hosts 
retry until it works. this is not the case of DAD, it simply has not 
been designed that way
> The requirement of default dropping is actually how to make the 
> binding more accurate.
> The only problem of CPS is that some DAD packet may be lost in the 
> directly attached SAVI switch (in a very low possibility).
> A easy way to fix it is to make DAD redundant (like what IPv4 did, 
> requires sending 3 packets,which is easy to be implemented). 
> Certainly, we could find other way to enhance DAD. Any idea is welcomed.
you would need to change the hosts and this is clearly out of the scope 
for savi

regards, marcelo

> Anyway, I think default dropping will be the right approach (to meet 
> the goal of SAVI and anti-spoofing).
>
> thanks,
> Jun Bi
>
>
> ----- Original Message ----- From: "marcelo bagnulo braun" 
> <[email-masked]>
>> The discussion related to whether we should set up SAVI bindings 
>> using FCFS only on control datagrams or also on data exchanges. He 
>> suggested that we only set up binding state on control packets but 
>> that we permit data packets that correspond to no binding (eg, from 
>> is an address that nobody in the LAN is known to be using) to pass.
>>
>> trying to prevent - the use of a source address such that A sends to 
>> B and B's reply is delivered to some third party.
>> it is trying to ensure that datagrams in the wild are valid and 
>> useful as opposed to being attack traffic. To do that, the point is 
>> To make that positive statement, whether we set up bindings on 
>> control or data packets, we can only allow datagrams to pass that 
>> originate from addresses that are associated with the putative 
>> sender, apart from systems that routinely originate datagrams at L2 
>> from other L3 addresses, such as routers do.
>>
>>
>> selecting the right /64 still means one has 2^64 interface 
>> identifiers to choose from, and that the probability of randomly 
>> selecting that of a neighbor is pretty low. So while preventing 
>> address spoofing is an obvious goal, simply doing that doesn't 
>> prevent attacks in which the source address is incorrect; one also 
>> has to prevent address anonymization.
>> distinguish between a virtual host and a set of hosts connected by a 
>> 5 port potentially-non-SAVI switch and that to the wall; there, the 
>> big switch might associate IPv6 addresses with MAC Addresses and 
>> those in turn with a port.