Subject: [savi] Defining the Solution Space for SAVI

From: Christian Vogt <[email-masked]>
Date: Sun, 12 Oct 2008 01:58:15 +0300

Folks,

at our first SAVI meeting in Dublin, we presented the main solution
proposals and had a good discussion on where the working group should be
going.  We should now follow up on this discussion so that we can
eventually decide which type of solution SAVI should aim for.

The solutions proposals we have on the table [1-4] make different
tradeoffs between simplicity and easy deployability on one hand, and
strength of security on the other hand.  They fall into two classes:

(a) solutions that emphasize strong security

(b) solutions that emphasize simplicity and easy deployability

Solutions in bucket (a) bind IP addresses to credentials and therefore
involve cryptography.  Solutions in bucket (b) bind IP addresses to
physical or link layer entities and are non-cryptographic. Consequently,
solutions in bucket (b) can detect all types of spoofing attacks, but
are more complex to setup and maintain.  Solutions in bucket (a) are
rather lightweight and easy to deploy, although they may not be able to
protect against all types of spoofing attacks

The working group must now come to a conclusion as to which class a
working group solution should fit in.  In order for us to make an
informed decision, the working group chairs would like to continue the
discussion [5] from the SAVI meeting in Dublin with you.  We should
decide upon the desired properties of a SAVI solution, taking into
account the goals and requirements put forth on the working group
charter.  It may also be helpful to take another look at the design
taxonomy [6] that the working group chairs had presented in Dublin.
Based on the results of this discussion, we will be able to decide
whether a lightweight solution will be sufficient, or whether
cryptography is needed.

- Bill and Christian

[1] Source-Guard-based approach by Fred Baker
     draft-baker-sava-implementation
     http://www.ietf.org/proceedings/08jul/slides/savi-0/savi-0.htm

[2] EAP-based approach by Ren Gang et al.
     draft-wu-sava-solution-firsthop-eap
     http://www.ietf.org/proceedings/08jul/slides/savi-1/savi-1.htm

[3] CGA-based approach by Jun Bi et al.
     draft-sava-solution-ipv6-firsthop-authentication
     http://www.ietf.org/proceedings/08jul/slides/savi-4/savi-4.htm

[4] First-come-first-served approach by Erik Nordmark
     http://www.ietf.org/proceedings/08jul/slides/savi-5.pdf

[5] Minutes from the SAVI Meeting at IETF 72, Dublin
     http://www.ietf.org/proceedings/08jul/minutes/savi.txt

[6] SAVI Design Taxonomy and Analysis
     http://www.ietf.org/proceedings/08jul/slides/savi-2.pdf

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 12 Oct 2008 11:18:20 +0200

Hi Chrsitian,

thanks for the analysis, some comments below...

Christian Vogt escribió:
> solutions in bucket (b) 

You mean that solutions in class a?

> can detect all types of spoofing attacks, but
You mean that solutions in class b?

> working group solution should fit in.

but the charter already makes that decision for us doesn't it?
I mean, the savi charter states:

The scope of the WG is as follows:

- 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.

- No changes to hosts are allowed.

- The WG is prohibited from creating its own protocols
or extensions/modifications of current protocols.

So, the solution works in the bridge or router, and no host changes are 
allowed and no new protocols. I guess that solutions in class a require 
changes in the hosts and are likely to require a new protocol (in order 
to proof that actual data packets come from the claimed source)

I understand that these solutions are simply out of the scope for the WG 
charter as defined.

So, imho this decision has already been taken and we need to figure out 
what is the best we can do with the imposed constraints

I am not saying that leveraging in SeND is not possible but creating new 
protocols that use CGAs or certificates seems to me to be explicltly out 
of the charter.

>   In order for us to make an

As i said, the charter already states that we can't do new protocols or 
host changes. so maybe we cna leverage on send, or in other existent 
crypto tools that are already defined, but as currently stand, class a 
propoals are out of the charter imho

Regards, marcelo

> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: "Jun Bi" <[email-masked]>
Date: Sun, 12 Oct 2008 22:19:34 +0800

Hi Marcelo,

I thought during the IETF72 SAVI WG discussion, as Jari and others pointed,
if the solution is revised as an extension of an existing protocol (e.g., 
SeND or others),
 then it somehow won't be a new protocol or host change.

Anyway, we need solutions that can really fix the problem in the usual 
situations and deployment scenarios
that required by users.
Therefore, based on the current experience, I believe a problem statement 
draft is needed by this WG.
And maybe, according to the problem statement, a framework draft is also 
necessary to provide more detail (than charter) guideline to solution 
design, e.g. the deployment point, the upper boundary of the cost, etc.

thanks,
Jun Bi

----- Original Message ----- 
From: "marcelo bagnulo braun" <[email-masked]>
To: "Christian Vogt" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>
Sent: Sunday, October 12, 2008 5:18 PM
Subject: Re: [savi] Defining the Solution Space for SAVI

Hi Chrsitian,

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 12 Oct 2008 18:32:03 +0200

Hi Jun Bi,

Jun Bi escribió:
> if the solution is revised as an extension of an existing protocol 
> (e.g., SeND or others),
> then it somehow won't be a new protocol

i agree that we could extend a protocol and that wouldn't be a new protocol

> or host change.
it depends on what the protocol extensions affect
for instance, you can extend send so that the routers do something new, 
and that would be compatible with SAVI charter (we would need to figure 
out if this WG is the right place to do this, since SeND is been updated 
in CSI, but that's another disucssion)

However, i understand that charter explicitly precludes making 
extensions to protocols that modify the host behaviour. so if the 
hypothetical change to the SeND protocol affects host behaviour, it is 
my understanding that the SAVI charter explicitly precludes from doing 
that. But maybe i am reading too much into the charter so, maybe the 
charis or the ADs could clarify this

> Therefore, based on the current experience, I believe a problem 
> statement draft is needed by this WG.
> And maybe, according to the problem statement, a framework draft is 
> also necessary to provide more detail (than charter) guideline to 
> solution design, e.g. the deployment point, the upper boundary of the 
> cost, etc.
well, these two documents are not in the charter neither...

regards, marcelo

>
> thanks,
> Jun Bi
>
>
> ----- Original Message ----- From: "marcelo bagnulo braun" 
> <[email-masked]>

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 13 Oct 2008 01:05:04 +0800

Hi Marcelo,

The question is do we really need the two documents or not.
Since the charter only provide rough guideline that already brought some 
arguments (such as what we saw in the mailing list), I guess the WG need the 
two documents.

By the way, thank you for all the comments.

Best Regards,
Jun Bi

regards, marcelo

---

From: Christian Vogt <[email-masked]>
Date: Mon, 13 Oct 2008 17:54:12 +0300

Marcelo -

> You mean that solutions in class a?

Yep.

>> can detect all types of spoofing attacks, but are more complex to  
>> setup
>> and maintain. Solutions in bucket (a) are
>

Yep. :-)

> but the charter already makes that decision for us doesn't it?

Not necessarily.  The intention of the charter is to avoid host changes
and new protocols.  Using an existing protocol, unchanged, for the
purpose of verifying a host's IP address ownership is, of course,
in-charter.  What if a SAVI device could use SeND as is?  Then why not
increase security based on SeND in those environments where it is
deployed?  The disadvantage would be a significant applicability
limitation because SeND deployment would become a prerequisite for SAVI
deployment.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 13 Oct 2008 17:55:06 +0300

Jun Bi wrote:

> I thought during the IETF72 SAVI WG discussion, as Jari and others
> pointed, if the solution is revised as an extension of an existing
> protocol (e.g., SeND or others), then it somehow won't be a new  
> protocol
> or host change.

Jun and all,

what was considered at IETF 72 was not to extend SeND (or another
protocol).  It was the possibility to request from IESG the addition of
a charter deliverable for a SeND-based SAVI solution extension.  The
idea was that the working group could work on both, a basic
non-cryptographic SAVI solution, plus a more secure extension that would
be based on (unchanged) SeND.  This would allow easy deployment of the
basic SAVI solution without special prerequisites.  And in those
environments where SeND is deployed, stronger security could optionally
be obtained by using the SAVI solution extension.

- Christian

---

From: ZhangDong <[email-masked]>
Date: Tue, 14 Oct 2008 10:06:53 +0800

Hi all,

In my opinion, a SAVI solution based on SeND is feasible. Perhaps the solution may depend on CGA(Cryptographically Generated Addresses) directly, which also is used in SeND.
However the charter requests that both IPv4 and IPv6 need to be covered. SeND is a protocol of IPv6. That is to say the SeND-based solution must be implemented in IPv6 network. How about IPv4?
Is this a problem? Or  I miss some discussion in IETF 72 ?

Best Regards

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 14 Oct 2008 11:45:23 +0800

Hi Christian,

Thank you very much for the clarification. I actually meant the same:
considering a
SeND-based SAVI solution extension.
By the way, to investigating existing protocol, binding ID with IP address,
HIP is also being considered for the host ID, Andrei Gurtov showed interests
in IETF72.

Best Regards,
Jun Bi
----- Original Message ----- 
From: "Christian Vogt" <[email-masked]>
To: "Jun Bi" <[email-masked]>
Cc: "marcelo bagnulo braun" <[email-masked]>; "SAVI Mailing List"
<[email-masked]>
Sent: Monday, October 13, 2008 10:55 PM
Subject: Re: [savi] Defining the Solution Space for SAVI

>> protocol (e.g., SeND or others), then it somehow won't be a new  protocol
>> or host change.
>
> Jun and all,
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 14 Oct 2008 20:26:33 +0200

Christian Vogt escribió:
>>> can detect all types of spoofing attacks, but are more complex to setup
> in-charter.  What if a SAVI device could use SeND as is?
agree, this is perfectly on charter

but i haven't seen any proposal in this space i.e. reunsing without 
requiring changes

Moreover, i doubt we will be able to achieve a strong solution on these 
lines, cause current data packets don't carry any mean to verify the 
source address, even when CGAs are used, so in order to actually achieve 
a strong security mechanism, we need means to proof the host that has 
generated a given data packet and not the neighbor discovery messages 
(which is basically the scope of send)

>   Then why not
I think that a send based solution could provide more security than a 
neighbour discivery based solution, but i still don't think we will 
achieve strong security if we don't modify send, that is why i still 
think that the charter already defines that strong security are out of 
the charter

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 14 Oct 2008 20:28:35 +0200

> be obtained by using the SAVI solution extension.

that makes sense to me
moreover, i think that if we define a solution based on ND, it would 
make sense as well to figure out how it works with send (both unchanged 
i mean of course). I would even argue that this would fit in the current 
charter, since send is just the secure version of nd

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 14 Oct 2008 20:30:44 +0200

ZhangDong escribió:
> Is this a problem? 

I don't think this is a problem
we can do in IPv4 what is possible and maybe do more in ipv6 cause we
have additional tools

regards, marcelo

> Or  I miss some discussion in IETF 72 ?
>
> Best Regards
>
>
> ----- 原始邮件 -----

---

From: Christian Vogt <[email-masked]>
Date: Tue, 14 Oct 2008 22:45:45 +0300

> but i haven't seen any proposal in this space i.e. reunsing without

Me neither. :-)

> (which is basically the scope of send)

That's right, the security improvements are limited.  Using unmodified
SeND could prevent the spoofing of unused and off-link IP addresses.
And for non-shared link segments between a host and a SAVI device, this
implies that the host could not use a false IP address.  But it seems
that spoofing a neighbor's IP address is still possible once that
neighbor has convinced the SAVI device that its IP address is OK.

- Christian

---

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

> neighbor has convinced the SAVI device that its IP address is OK.
Well, actually, you could build a SeND based solution that actually does 
provides a bit more than that.
SeND basically uses two tools for security: CGAs for hosts and 
certificates for routers.
Now, we can then have two trust models. For hosts, i only allow them to 
send packets that correspond to their CGA and that the prefix 
corresponds to one of the prefixes authorized for the link (this may be 
tricky cause i would assume that any router on the link is able to learn 
all prefixes that are available on the link, which may not be guaranteed).
this basically means that each time a router receives a packet for a 
host that it hasn't got its MAC address for, it verifies that the prefix 
belong to one of the on-link prefixes and if yes, then it uses SeND to 
verify the CGA. the router should also do that when there is change in 
the mac, and the router can run periodic tests, so that he is sure that 
an attacker is not using the address once the original host has left.
For routers, i basically need to trust them to send packets from any 
source address. But that may be compatible with the model that we have 
certs for routers.

So, i think that a send based solution using SeND protocol unmodified 
from the hosts perspective but using additional checks in the routers 
could provide a somehow higher level of security.

We could try to extend this for regular ND. Actually, i think that one 
possible trust model, if we don't assume that ingress filtering is 
deployed, is to have the routers to know:
- which are the other routers (i.e. the nodes on the link that are 
authorized to send packets from any source address)
- whcih are the prefixes availabel on the link.

If you assume that routers know this information, then, you could 
actually achieve higher security, cause the regular nodes can only send 
packets from  on-link  prefix and probably you can limit the number of 
source address they should use on any period of time

Regards, marcelo

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 15 Oct 2008 19:55:30 +0800

After IETF72, a new version of CSA draft is designed making use of SeND in 
the address authorization phase (phase 1). This will be delivered soon.

thanks,
Jun Bi

---

From: Christian Vogt <[email-masked]>
Date: Thu, 16 Oct 2008 02:59:37 +0300

marcelo bagnulo braun wrote:

> provides a bit more than that. SeND basically uses two tools for
> security: CGAs for hosts and certificates for routers. Now, we can  
> then
> have two trust models. For hosts, i only allow them to send packets  
> that
> correspond to their CGA and that the prefix corresponds to one of the
> prefixes authorized for the link (this may be tricky cause i would
> assume that any router on the link is able to learn all prefixes that
> are available on the link, which may not be guaranteed). this  
> basically
> means that each time a router receives a packet for a host that it
> hasn't got its MAC address for, it verifies that the prefix belong to
> one of the on-link prefixes and if yes, then it uses SeND to verify  
> the
> CGA. the router should also do that when there is change in the mac,  
> and
> the router can run periodic tests, so that he is sure that an attacker
> is not using the address once the original host has left. For  
> routers, i
> basically need to trust them to send packets from any source address.
> But that may be compatible with the model that we have certs for
> routers.

Cool.  Now we have a proposal that takes advantage of SeND unmodified.
:-)

> deployed, is to have the routers to know: - which are the other  
> routers
> (i.e. the nodes on the link that are authorized to send packets from  
> any
> source address) - whcih are the prefixes availabel on the link.

The opposite approach seems also feasible:  to rely on ingress
filtering.  As a matter of fact, the 2nd of your assumptions ("routers
know which prefixes are on-link"), is already sufficient for routers to
do ingress filtering.  And if they do it, you no longer need the 1st
assumption ("routers know other routers"), because you don't have to
care about off-link source addresses anymore.

In short, relying on ingress filtering reduces the source address
validation problem to validating on-link source addresses.  And as you
say:  Which source addresses are on-link is something SAVI devices
can, at least in IPv6, automatically learn by listening to Router
Advertisement messages.  I would argue that this is reliable because the
periodic retransmission of Router Advertisement messages automatically
repairs occasional loss.  It is also secure because an attacker does not
gain anything by sending a spoofed Router Advertisement message.  The
transmission of a Router Advertisement message does not reduce the
strictness of SAVI devices; it can at most increase the strictness.

Of course, the assumption that all access routers perform ingress
filtering is bold. Ingress filtering is today typically deployed further
upstream to avoid having to configure it in every single access router.
But perhaps access router could auto-configure ingress filtering by
listening to Router Advertisement messages, just like SAVI devices might
distinguish off-link and on-link addresses by listening to Router
Advertisement messages...

- Christian

---

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

Christian Vogt escribió:
>> security: CGAs for hosts and certificates for routers. Now, we can then
>> have two trust models. For hosts, i only allow them to send packets that
>> are available on the link, which may not be guaranteed). this basically
>> one of the on-link prefixes and if yes, then it uses SeND to verify the
>> CGA. the router should also do that when there is change in the mac, and
>> is not using the address once the original host has left. For routers, i
>> deployed, is to have the routers to know: - which are the other routers
>> (i.e. the nodes on the link that are authorized to send packets from any
> filtering.  
yes, i was trying to figure  out a scheme that does not rely on ingress 
filtering, but if we have ingress filtering, then the problem is simplified

> As a matter of fact, the 2nd of your assumptions ("routers
> do ingress filtering.
I think we agree but just to clarify
routers need to validate two types of packets afaict.
They need to validate the source address of the packets generated by 
hosts connected to the local link For example, consider the case of 
router R2 validating packets generated from host H2). In order to do 
that, they need to know what are the prefixes assigned to the local link 
(pref2 in the example below). So, if a local _host_ (H2) generates a 
packet with a source address that does not belongs to one of these local 
prefixes (for example with Pref1), then the host H2 has spoofed the 
source address and needs to be discarded.
But routers also need to deal with packets forwarded by other routers 
that are in transit in that link.

See for example the situation where H1 sends a packet to H3. H1 will 
include the prefix Pref1 and send it to R1. R1 will send it to R2. Now 
the packet will contain a prefix Pref1 that is not one of the prefixes 
assigned to the local link, but the packet is legal. So, one option to 
make this work is to do ingress filtering based on reverse path 
forwarding. the other option that i was mentioning that is slightly 
different but could work in some trust models is that R1 knows R2 is a 
router, so R2 will accept packets from any source address if they are 
coming from R1 (an valid router)

     Pref1+--+ Pref2               +--+
----------|R1|---------------------|R2|--------
    |     +--+        |            +--+  |
   +--+             +--+                +--+
   |H1|             |H2|                |H3|
   +--+             +--+                +--+
>   And if they do it, you no longer need the 1st

Let me see if we agree:
We are considering two options
- the router knows the local prefixes and which are the routers directly 
connected (in this case the trsut models is that the routers are 
trustworthy)
- the router knows the local prefixes and performs ingress filtering. 
(in this case, the trsut assumptions depend on what type of routing do 
we have. If we have default routes, you are basically trusting the 
router for pretty much everything, sinilar to the previous case)
> validation problem to validating on-link source addresses.
exactly, that's why my initial question!

> And as you
i would like to think about this a bit more, to understand if this is a 
valid general case or there are corner cases, proxy nd for instance or 
other particualr configurations

> upstream to avoid having to configure it in every single access router.
right, but it really depends on the scope we have in mind for savi.
If the scope is a site i.e. a solution that applies to a local site, 
then the assumption could be valid. Of course, what we are after is an 
internet wide solution, then certainly it doesn,'t but i am not sure if 
we will be able to do that in any case

> Advertisement messages...
but that's not enough, right? we need full routing table to do it right 
and to cope with the cases i described above.

regards, marcelo

---

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

Marcelo -

> hosts connected to the local link.  [...]  But routers also need to  
> deal with packets forwarded by other routers that are in transit in  
> that link.

That's right.  And the second of these is what we could potentially  
solve by relying on ingress filtering.

> - the router knows the local prefixes and which are the routers  
> directly connected (in this case the trsut models is that the  
> routers are trustworthy)
> - the router knows the local prefixes and performs ingress  
> filtering. (in this case, the trsut assumptions depend on what type  
> of routing do we have. If we have default routes, you are basically  
> trusting the router for pretty much everything, sinilar to the  
> previous case)

Yes, these are two options we have for dealing with routers.

Referring to your statement "trusting the router for pretty much  
everything":  Do you feel that this option would offload too much  
security to ingress filtering?

> then the assumption could be valid.

Yes, I agree with this.  In particular if SAVI was to be implemented  
on routers, then it should be straightforward to build a network where  
all access routers use SAVI + ingress filtering.

> Of course, what we are after is an internet wide solution, then  
> certainly it doesn,'t but i am not sure if we will be able to do  
> that in any case

Right.  We are in no position to guarantee an Internet-wide solution  
since it would require universal deployment of SAVI.  Even if SAVI was  
going to be super-easy to deploy, very likely there would continue to  
be networks that wouldn't deploy it -- due to costs, due to inertia,  
due to malicious intents, you name it.

> but that's not enough, right? we need full routing table to do it  
> right and to cope with the cases i described above.

My mistake; just listening to Router Advertisement messages is not  
enough.  Routers on transit (non-stub) links need to look beyond their  
local link to discover all legitimate prefixes.

- Christian

---

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

Christian Vogt escribió:
>> directly connected (in this case the trsut models is that the routers 
>> are trustworthy)
>> (in this case, the trsut assumptions depend on what type of routing 
>> do we have. If we have default routes, you are basically trusting the 
no, i think that's fine
actually as i said before, you have two options, either simply trust the 
routers blindly or do ingress filtering as well, which provides more 
security, since you at least verify that the routing information is 
coherent with the source address you are looking in the packets.

regards, marcelo

>> certainly it doesn,'t but i am not sure if we will be able to do that 
>> in any case
>

---

From: ZhangDong <[email-masked]>
Date: Tue, 21 Oct 2008 14:59:41 +0800

Dear Christian and Marcelo,

Because I did not attend the IETF 72. So here I still have confused questions.

>  >> protocol (e.g., SeND or others), then it somehow won't be a new protocol

What kind solution is called host change?
If the solution uses the option field or reserved field, does it change the host or revise the protocol existed? 
And can extension part be added in protocol existed?

>  charter, since send is just the secure version of nd

Dong Zhang

---

From: Christian Vogt <[email-masked]>
Date: Tue, 21 Oct 2008 15:33:02 +0300

> What kind solution is called host change?

You need to change hosts if hosts need to act differently
than specified in existing RFCs.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 21 Oct 2008 16:12:05 +0200

> And can extension part be added in protocol existed?

imho, the definition is very simple. If you need to change the stack
software in the host, this is a strong hint that you are doing a change
in the protocol

If it is a configuration, i think it wouldn't be the best option, but
maybe we can live with that

regards, marcelo

---

From: ZhangDong <[email-masked]>
Date: Wed, 22 Oct 2008 09:44:43 +0800

>  than specified in existing RFCs.

I know that the SAVI solution must not change the behavior of the host specified in existing RFCs.

>  >> protocol (e.g., SeND or others), then it somehow won't be a new protocol

However, when makeing an extension of an existing protocol may let the host do some additional operation. According to the discussion earlier, it is allowed by SAVI.

Am I ringht?Or misunderstanding?

Dong Zhang

Dong Zhang

---

From: Christian Vogt <[email-masked]>
Date: Fri, 24 Oct 2008 12:55:29 +0300

Hi Dong Zhang -

> However, when makeing an extension of an existing protocol may let  
> the host do some additional operation. According to the discussion  
> earlier, it is allowed by SAVI.

No, such host changes are actually not allowed by SAVI.  Note that  
what we where discussing earlier was an extension to the operation of  
SAVI devices such that they can make use non-modified SeND support on  
hosts.

- Christian