Subject: [savi] Scope of savi

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 13 Oct 2008 10:54:14 +0200

Hi,

I am trying to understand what would be the scope of a SAVI solution.
A first question that comes to my mind when i start thinking about this 
is whether we want a solution that complements ingress filtering or we 
want a solution that substitutes ingress filtering. In other words, one 
option would be to assume that we have ingress filtering and try to 
define a SAVI solution that mitigates or even eliminates the remaining 
threats. As the threat analysis draft describes, even if we have ingress 
filtering deployed, we would still have the potential threat that a node 
located in a give LAN could spoof the address of another host of the 
same LAN and that would not be detected by the ingress filters. I 
understand that several of the proposals (like Erik's FCFS or Fred's 
SAVA implementation) go in that direction.
The other option is to state that ingress filtering is far from deployed 
and we need to define a SAVI solution that is stand alone, i.e. that 
protects against the threats that ingress filtering is supposed to 
protect against. I am not sure if we can do much better than ingress 
filtering with the imposed constraints, but since i haven't seen this 
acknowledged in the charter, it seemed worthwhile to me to make this 
matters clear

Regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Mon, 13 Oct 2008 19:32:43 +0300

Marcelo,

you are raising a very good question.  But I think you are too fast. :-)
What we should in my opinion consider first is the higher-level question
of where we want SAVI solutions to be deployed.  Or, the same question
phrased more specifically:  Which (existing and unchanged) protocols do
we want a SAVI solution to rely upon?  Should it be plain IPv6 Neighbor
Discovery and ARP?  Should it be SeND?  Or should it be something even
more sophisticated?  We need to answer this question first in order to
be able to answer the more specific question you are raising.

Your question addresses a very specific, technical goal.  It falls into
the same category as several other questions that have been raised:

(a) Should SAVI support hosts with multiple IP addresses per interface?

(b) Should SAVI support hosts with multiple link layer addresses per
     interface?

(c) Should SAVI support hosts that move at the link layer?

(d) Should SAVI support hosts that are multi-homed at the link layer?

(e) Should SAVI support routers?

(f) Should SAVI support NATs?

(g) Should SAVI support anycast addressing?

(h) Should SAVI detect spoofed unused IP addresses?

(i) Should SAVI detect spoofed off-link IP addresses?

(j) Your question:  Should SAVI complement or substitute ingress
     filtering?

It is tempting to answer all of these questions with "yes".  But without
knowing which protocol SAVI can rely upon and make use of, answering any
of these question with "yes" would be dangerous:  It would set us a goal
that we may not be able to meet.

I would therefore suggest to first revisit the initial, high-level
question of where in the tradeoff space between strong security and easy
deployability a SAVI solution should reside in our opinion.  We can
answer this question very specifically by pinpointing the (existing and
unchanged) protocols that we want a SAVI solution to rely upon --
keeping in mind that we cannot create new protocols.

Once we have settled on an answer to this high-level question, we will
have a much clearer understanding of what is achievable and what is not.
And we will be able to confidently answer the questions that you are
raising, as well as the other more specific questions in the list above.

- Christian

On Oct 13, 2008, marcelo bagnulo braun wrote:

> Hi,
>
> I am trying to understand what would be the scope of a SAVI  
> solution. A
> first question that comes to my mind when i start thinking about  
> this is
> whether we want a solution that complements ingress filtering or we  
> want
> a solution that substitutes ingress filtering. In other words, one
> SAVA implementation) go in that direction. The other option is to  
> state
> that ingress filtering is far from deployed and we need to define a  
> SAVI
> solution that is stand alone, i.e. that protects against the threats
> that ingress filtering is supposed to protect against. I am not sure  
> if
> we can do much better than ingress filtering with the imposed
> constraints, but since i haven't seen this acknowledged in the  
> charter,
> it seemed worthwhile to me to make this matters clear
>
> Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Oct 2008 09:43:52 +0200

Hi Christian,

> be able to answer the more specific question you are raising.
this is my take on this.
First, i understand that the constraints are:
- no changes to hosts
- SAVI must run either on the router or in the bridge

So, in order to communicate with the hosts, we can only leverage on 
existing protocols. I understand that the possible candidates are:
- ARP/ND
- SeND
- DHCP

Any others? (i don't see any other one...)

However, we could make changes to the router behavior or bridge. So for 
the router parts, we could either think to extend any of the previous 
ones or we could define a new protocol for the communication of savi 
routers/bridges. However, i am not ure if we are even allowed to do that 
by the charter, since it states:  The WG is prohibited from creating its 
own protocols
or extensions/modifications of current protocols. So, if we take this 
literally, we could only re use current protocol messages and maybe do 
additional checks, which scopes the work even more.

A second high level question i guess is who will be the policing agents. 
I mean, who is going to check that the source addresses are not spoofed. 
I think that the clear candidates are again the router and the bridges.

As a strawman, i think the best way would be to try to see how far can 
we go with the more constrained scenario. i.e. we do not define a new 
protocol and we don't define any extension to existent protocols and try 
to re use existent messages to see how much can we do. If the result is 
clearly no satisfactory, we can then argue that we need more 
modifcations to make something decent.
> (a) Should SAVI support hosts with multiple IP addresses per interface?
yes, well at least in IPv6 this is a must. For ipv4, i guess we could 
live without this or treat as ane exception
> (d) Should SAVI support hosts that are multi-homed at the link layer?
For all these question, i think we should try. I mean, i think we should 
start by trying to find a solution that relies on exsitnet protocols and 
does not requires any new message or new protocol and see if we can 
support these cases. In other words, i think it important to try to do 
soemthing that is deployeable (i.e. dos not requires new messages nor 
hos changes) than supporting these

> (e) Should SAVI support routers?
I don't understnad what you mean by this
I understand that we need to support a scenario where there are multiple 
routers in one link

> (f) Should SAVI support NATs?
not sure hwy this is a problem.. i think this is easier to support than 
a normal router, since the packets coming from the nat actually carry 
the nat source address (at least on the public side) which makes life 
easier imho

> (g) Should SAVI support anycast addressing?
imho this one fails in the category of nice to have

> (h) Should SAVI detect spoofed unused IP addresses?
i guess so

> (i) Should SAVI detect spoofed off-link IP addresses?
this is essentially my question of ingress filtering

I think we need to assume a trust model

One option is as i mentioned in the other email, to assume that routers 
are trustworthy and that they and only they can send packets coming from 
source address with an off link prefix. If you do that everywhere, you 
are actually protecting from spoofed off link IP addresses.
the next question is how do routers verify that the source address is 
not spoofed if the turst chain is broken, i.e. when there is link with a 
router that cannot be trusted. In that case, we can fall back to ingress 
filtering, i guess. But new ideas would be great in this area.

So, we can split the problem in two here:
- One part is how to verify that on link addresses are not spoofed. i.e. 
addresses that are supposed to be on the link are actually used by a 
host that owns them in some way. I think this is the "easiest" problem 
and we can find somehow efficient ways todo this
- the other part, is when a packet is flowing through a link with a 
source address that doesn't belong to the link, how we can verify that 
the source address has not been spoofed. This is harder. Either requires 
some trust chain, where everyone implements the previous security 
technique i.e. if every on link address is not spoofed and everyone does 
the same, then the source address are also valid in transit (this option 
could be suitable for a intra site communication). Or the other option 
is to rely in something like ingress filtering.
> keeping in mind that we cannot create new protocols.
My take is that we should go as far as we can with exsiting protocol and 
not changing the host behaviour in no way. We should set us the goal of 
trying to achieve the above features, but with the preivous constraint.

Morevoer, for IPv6, i think we should have a basic solution using ND and 
another more secure one relying on send (defining only a send based 
solution is a not such a good iea cause the deployment of send is very 
limited)

Regards,

>> I am trying to understand what would be the scope of a SAVI solution. A
>> first question that comes to my mind when i start thinking about this is
>> whether we want a solution that complements ingress filtering or we want
>> SAVA implementation) go in that direction. The other option is to state
>> that ingress filtering is far from deployed and we need to define a SAVI
>> that ingress filtering is supposed to protect against. I am not sure if
>> constraints, but since i haven't seen this acknowledged in the charter,

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 15 Oct 2008 11:51:29 +0200

> existing protocols. I understand that the possible candidates are:

Not all hosts support SEND or DHCP. In fact, very few support SEND,  
and presumably (haven't seen this in the wild), hosts that _can_ do  
SEND may also use stateless autoconfig, DHCPv6 address assignment or  
manual configuration. So this pretty much makes it impossible to  
depend on SEND...

>> (f) Should SAVI support NATs?

A NAT box acts as a router on the private side and as a host on the  
public side. So there is no specific action necessary to support NAT.

</delurk>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Oct 2008 12:02:15 +0200

> manual configuration. So this pretty much makes it impossible to 
I am not arguing to define a solution that only works when send is 
available, i am arguing for having a solution that when send is 
available, takes advantage of this and is more secure

regards, marcelo

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Oct 2008 14:05:49 +0300

> A first question that comes to my mind when i start thinking about 
> this is whether we want a solution that complements ingress filtering 
> or we want a solution that substitutes ingress filtering. In other 
> words, one option would be to assume that we have ingress filtering 
> and try to define a SAVI solution that mitigates or even eliminates 
> the remaining threats. As the threat analysis draft describes, even if 
> we have ingress filtering deployed, we would still have the potential 
> threat that a node located in a give LAN could spoof the address of 
> another host of the same LAN and that would not be detected by the 
> ingress filters. I understand that several of the proposals (like 
> Erik's FCFS or Fred's SAVA implementation) go in that direction.
> The other option is to state that ingress filtering is far from 
> deployed and we need to define a SAVI solution that is stand alone, 
> i.e. that protects against the threats that ingress filtering is 
> supposed to protect against. I am not sure if we can do much better 
> than ingress filtering with the imposed constraints, but since i 
> haven't seen this acknowledged in the charter, it seemed worthwhile to 
> me to make this matters clear

I believe SAVI should complement ingress filtering, not replace it.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Oct 2008 14:13:00 +0300

Christian Vogt wrote:
> of where we want SAVI solutions to be deployed.

Let me quote the charter: "The working group considers only solutions 
implemented on systems located on the same IP link as a to-be-verified 
node. The goal of the working group is the LAN environment and solutions 
running in routers or layer 3 aware Ethernet bridges."

I think that is still valid. Now, taken together with the idea that we 
are here to address needs that have not yet been covered by ingress 
filtering, I think that sets your scope fairly well.

> Or, the same question
> more sophisticated?

These are good questions, too, but I would actually think about this in 
a slightly different manner.

We know we want to have a solution with a higher granularity than 
ingress filtering, and this forces us to use more information, including 
looking at things like MAC addresses, ND/ARP, etc. Your other set of 
questions a through j are requirements or desirable properties. However, 
I think it would be a mistake to go about this effort in an entirely top 
down fashion. As you point out, it can be dangerous as there might be 
something we cannot achieve.

As a result, I would actually recommend that you spend time going 
between what is possible i.e. the solution and what you want to achieve. 
I though the discussion we had with Erik in the first SAVI meeting was a 
good one in this respect. I'd be wary of creating too many new documents 
at this stage before the fundamental tussle between what's possible and 
what you want to do is a little bit clearer.

Jari

---

From: Christian Vogt <[email-masked]>
Date: Thu, 16 Oct 2008 16:23:01 +0300

> running in routers or layer 3 aware Ethernet bridges."

Jari,

my question wasn't about /where/ to deploy SAVI in a given network, but
in which networks SAVI should be deployable -- deployable without having
to deploy additional protocols at the same time.  To exemplify:  If a
SAVI solution required SeND, then obviously it wouldn't be deployable in
networks that run only plain ND.  So requiring SeND would limit
deployability.

On the other hand, the toolbox that SeND provides to design a SAVI
solution is more powerful than the toolbox that plain ND provides.  So
to decide which situations a SAVI solution should be able to handle --
i.e., to answer questions (a) through (j) in my earlier email --, we
need to have some consensus about the protocols that SAVI should rely
upon.  That consensus may be of the form:  "Let's try to do with plain
ND first, and if we see that this is insufficient, we will reconsider."

Hence the suggestion to first get to some consensus regarding the
protocols SAVI should rely upon -- i.e., our design toolbox --, and then
talk about how to achieve the most using this toolbox.  So we start
top-down to confine our solution space, and then try to find the optimal
solution within that space, possibly in bottom-up fashion.

Having said this, I think that the discussion so far has shown several
convincing arguments (many by Marcelo) in favor of trying to do with
ARP/ND/DHCP in the basic case, and perhaps take advantage of SeND where
available.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 16 Oct 2008 18:25:29 +0200

> ARP/ND/DHCP in the basic case, and perhaps take advantage of SeND where
that sounds reasonable to me
I think that the other input received from Jari is also to rely on 
ingress filtering i.e. not try to replace ingress filtering, but try to 
defien a solution that complements it, which also makes sense to me

I think that if we agree on these issues, we are ready to go :-)

Regards, marcelo

---

From: Fred Baker <[email-masked]>
Date: Thu, 16 Oct 2008 09:42:57 -0700

> I believe SAVI should complement ingress filtering, not replace it.

Very much agree.

---

From: ZhangDong <[email-masked]>
Date: Fri, 17 Oct 2008 14:55:22 +0800

>  I think that if we agree on these issues, we are ready to go :-)

It seems there is a temporary conclusion after several days discussion.
So can i say we have the direction of the SAVI solution? 

Dong Zhang