Subject: Re: [savi] WG Last Call for SAVI Threat Scope Document

From: Pekka Savola <[email-masked]>
Date: Tue, 5 Oct 2010 14:54:45 +0300 (EEST)

On Wed, 8 Sep 2010, Christian Vogt wrote:
> This is a working group last call for the SAVI Threat Scope document.
> The authors have revised the document, as announced at our previous
> meeting in Maastricht, and we believe that the document is now ready for
> a final evaluation by the working group.  Please find the latest
> document version here:
>
>    http://www.ietf.org/id/draft-ietf-savi-threat-scope-03.txt
>
> Please read the SAVI Threat Scope document carefully and provide your
> feedback by Wednesday, September 22.  Thank you.

General comment: I think the document could be significantly improved 
by increasing focus and SAVI WG problem specificity.  It might be 
sufficient as it is as well, but is less useful to the reader. But I 
may be misunderstanding the purpose of this document.

..............

First, I understand that this document is expected to cover the 
following charter item:

   For background information, the working group will also develop a
   threats analysis document that describes what threats the solutions
   from the WG protect against. This document also contrasts SAVI
   to existing solutions.

.. the draft does fill this gap, after a fashion.  It also includes a 
lot of other material.  My interpretation is that the aim of the 
document is to provide a threats analysis from SAVI WG perspective 
(where the main focus is the "same link solutions" as specified in the 
charter).

As a consequence, I think the main body of S 6 (except S 6.1) is not 
specific to this document and is rather generic. Similarly, S 7 in 
almost all of its entirety is rather generic and lacks SAVI 
specificity.  S 8 could also be removed without major loss of content, 
or rephrased/summarized.  A half of Security considerations is not 
really from SAVI WG problem perspective.

In the document I found in its generic content most useful the 
following: S 3 (though this could have been organized differently as 
well), S 4.1-4.4, S 4.10.1-2, S 5.1-5.2, S 5.2.3-4. In its SAVI 
specific content I found S 6.1 very well written and useful.

I found still looking for clear text, a table or something that would 
describe "so, what exactly are the residual threats after various SAVI 
solutions?" and "what else needs to be deployed in addition to SAVI 
solutions?".  I did not find an explicit contrasting to existing 
solutions.

A few more specific comments:
-----------------------------

I think S 4 ("Current Anti-Spoofing Solutions") is a bag of 
miscellania, and the document would improve by some editing or 
restructuring.  Trying to sum it up:
  * S 4.1-4.4 describe IP spoofing prevention at various topological 
locations, in rather generic terms
  * S 4.5-4.6 describe two scenarios but no solutions (merge w/ 4.1?)
  * S 4.7 describes a topological scenario and a solution
  * S 4.8-4.11 describe anti-spoofing methodologies which are somewhat 
unrelated and overlapping with the previous sections.

Some restructuring would be useful.  The minimum approach would be to 
merge 4.5-4.6 or fill them up a bit, put 4.1-4.7 under a new 
subsection "topological solutions" and 4.8-4.11 under a new subsection 
"methodological solutions" or some such.  But more extensive edit 
would be even better.  For instance, S 4.8-4.9 just repeat what has 
been said earlier and if they are not necessary for the sake of 
completeness, they could be removed altogether.  Another approach 
would be to create a new Section before S 4 on solutions 
(tools/mechanisms), trimming current S 4.8-S 4.11 a little bit, and 
have the rest as S 5 on solutions (applying the tools in various 
environments/topologies).

..........

4.10.3. IEEE 802.1X

    IEEE 802.1x is an authentication protocol that permits a network to
    determine the identity of a system seeking to join it and apply
    authorization rules to permit or deny the action.

.. this is just stating what is irrelevant from the POV of this 
document.  What you should do is to make a statement on the 
applicability of 802.1x (use the lower case x?) as an anti-spoofing 
solution.  You could say e.g. that 802.1x but are not as such tied to 
IP addressing or bindings and cannot be used to prevent source address 
spoofing.

4.11. Cryptographic Techniques

.. in the same vein, this section mentions e.g. DNSSEC (different 
capitalization). It does not describe how exactly it is a 'current 
anti-spoofing solution' per section title.  DNSSEC in itself does not 
do anything for anti-spoofing, and maybe the best would be to focus 
only on SEND in this subsection (but in order to be useful, you should 
describe how SEND solves and does not solve these issues).  If you 
want to mention DNSSEC, some context wrt the subject title would be 
useful (maybe the assumption is that if DNSSEC would be ubiquituous, 
DNS cache forgeries would be less of a problem, or that if TCP + 
DNSSEC was used for queries, blind attacks would be more difficult. 
But IMHO these are rather far-fetched in this case).

............

S5 "Topological considerations" would IMHO be better titled 
"Challenges facing SAVI solution" or "Challenges" or some such.  This 
is really all about "requirements" or "things to think about when 
designing the savi solution".

editorial:
----------
    sources may or may not be legitimate sources, it's difficult to
    discriminate if the sources are not directly connected to the local
    routing system.

.. "discriminate" may be right but looks a bit strange here. maybe 
'determine' or some such would be clearer.

    can be used to perform broadly the same kinds of poinsonings as

.. s/poin/poi/

    Prevention:  Some of the threats described above explicitly require
       that a host send packets using some other active hosts IP address
       as a source.  Anti-Spoofing measures can prevent these attacks.

.. s/hosts/host's/

    or externally (and traced to the site( it can be critical to

../site(/site)/

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Oct 2010 13:45:40 -0400

Sorry for the delay in responding to this.
The major content of Pekka's review, retained below, is to remove a 
number of sections from the document.

I am happy to remove the text as he suggests.  But given the scope, I 
need concurrence from the WG, as judged by the chairs, for this scope of 
change.

Do folks want the text removed, or retained?

Thank you,
Joel

On 10/5/2010 7:54 AM, Pekka Savola wrote:
...
> .. the draft does fill this gap, after a fashion. It also includes a lot
> of other material. My interpretation is that the aim of the document is
> to provide a threats analysis from SAVI WG perspective (where the main
> focus is the "same link solutions" as specified in the charter).
>
> almost all of its entirety is rather generic and lacks SAVI specificity.
> S 8 could also be removed without major loss of content, or
> rephrased/summarized. A half of Security considerations is not really
> from SAVI WG problem perspective.

...

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Oct 2010 13:49:09 -0400

While I like the idea of a table of threats and coverage such as Pekka 
describes below, I am concerned that it is not practical.  The threats 
document can not mandate what solutions SAVI will actually provide, how 
they will work, or what deployments they will actually be used in.  I 
would like to keep the threats document focused on describing the 
SAVI-relevant threats that exist before SAVI is deployed, and not try to 
describe what SAVI will do.

I would like opinions from the rest of the WG as to whether this 
constitues an acceptable response to this request?

Thank you,
Joel

> solutions?". I did not find an explicit contrasting to existing solutions.
...

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 12 Oct 2010 19:50:39 +0200

I don't have a problem removing what pekka suggests

El 12/10/10 19:45, Joel M. Halpern escribió:
> need concurrence from the WG, as judged by the chairs, for this scope 
> of change.
>
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: Fred Baker <[email-masked]>
Date: Tue, 12 Oct 2010 10:51:31 -0700

To my mind, a "threats" document should, as you say, be about "threats". If that implies a "how to respond to specific threats" document, so be it.

On Oct 12, 2010, at 10:49 AM, Joel M. Halpern wrote:

> While I like the idea of a table of threats and coverage such as Pekka describes below, I am concerned that it is not practical.  The threats document can not mandate what solutions SAVI will actually provide, how they will work, or what deployments they will actually be used in.  I would like to keep the threats document focused on describing the SAVI-relevant threats that exist before SAVI is deployed, and not try to describe what SAVI will do.
> 
> I would like opinions from the rest of the WG as to whether this constitues an acceptable response to this request?
> 
> Thank you,
> Joel
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 12 Oct 2010 19:54:00 +0200

imho, we are way passed the requirements phase, and i wouldn't want to 
open that debate at this point.
in my review, i suggested a set of comments aimed to identify the 
residual threats once ingress filtering is deployed, which afaiu, is 
what savi needs to tackle. I think this would make sense
Then, i believe that the residual threats for savi belong to the 
security considerations of the SAVI solution documents and not here.

regards, marcelo

El 12/10/10 19:49, Joel M. Halpern escribió:
> document can not mandate what solutions SAVI will actually provide, 
> how they will work, or what deployments they will actually be used 
> in.  I would like to keep the threats document focused on describing 
> the SAVI-relevant threats that exist before SAVI is deployed, and not 
> try to describe what SAVI will do.
>

---

From: Pekka Savola <[email-masked]>
Date: Wed, 13 Oct 2010 09:26:08 +0300 (EEST)

On Tue, 12 Oct 2010, marcelo bagnulo braun wrote:
> imho, we are way passed the requirements phase, and i wouldn't want to open 
> that debate at this point.
> in my review, i suggested a set of comments aimed to identify the residual 
> threats once ingress filtering is deployed, which afaiu, is what savi needs 
> to tackle. I think this would make sense
> Then, i believe that the residual threats for savi belong to the security 
> considerations of the SAVI solution documents and not here.

I could see arguments boths ways.  For clarification, it seemed as if 
this was initially planned to be done in this document, per charter 
item below.  But I agree that WG could shift these around if it makes 
more sense to do so.  My main concern is that the document focused too 
much on "background" rather than applying it to SAVI work:

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 13 Oct 2010 09:05:46 +0200

El 13/10/10 8:26, Pekka Savola escribió:
>> imho, we are way passed the requirements phase, and i wouldn't want 
>> to open that debate at this point.
Right, i pointed out that in my review as well.
My suggestion here was to assume the ingress filtering was deployed and 
identify what would be the remaining threats that SAVI should try to tackle.
I made a number of comments in that direction, trying to identify what 
threats SAVI could address

would that make sense to you?

Regards, marcelo

---

From: Pekka Savola <[email-masked]>
Date: Wed, 13 Oct 2010 10:14:35 +0300 (EEST)

> would that make sense to you?

Let me clarify my assumption wrt what you wrote on ingress filtering. 
It should be assumed that ingress filtering is enabled on the subnet 
router where SAVI solution is enabled (i.e. what SAVI adds on top of 
this targeted ingress filtering). I have not followed the WG closely, 
so I'm not sure if SAVI solutions assume an externally configured 
ingress filtering solution, or the solution implements this more 
generic, subnet-specific ingress filtering method on its own.  I 
explicitly point out that global ingress filtering deployment should 
not be assumed.

As another 5c, I'm not opposed to some (background) discussion on 
ingress filtering, but it should be relatively concise, and the main 
focus should be on what you get by going to the next step (SAVI).

Yes, that would make perfect sense.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 13 Oct 2010 09:39:28 +0200

El 13/10/10 9:14, Pekka Savola escribió:
>> My suggestion here was to assume the ingress filtering was deployed 
>> and identify what would be the remaining threats that SAVI should try 
>> to tackle.
>> I made a number of comments in that direction, trying to identify 
>> what threats SAVI could address
>>

I am not sure i understand your comment.
Let me see if i manage to express more properly what i am trying to say 
and figure out if the agree or not.
SAVI is not chartered to solve a tool to substitute ingress filtering. 
It is chartered to design a solution that complements ingress filtering. 
So, basically to complement ingress filtering enhancing the security 
provided by ingress filtering, with a higher granularity. ingress 
filtering works at the route and with a prefix granularity and avi can 
work at a host level granularity.

That is what i meant by assuming ingress filtering. In order to identify 
that threats that SAVI can tackle, we can assume ingress filtering and 
see what are the residual threats. I am not saying that in order to 
deploy SAVI , you need to have universla deployment of ingress filtering.
Makes sense?

Regards, marcelo

---

From: Pekka Savola <[email-masked]>
Date: Wed, 13 Oct 2010 10:43:27 +0300 (EEST)

On Wed, 13 Oct 2010, marcelo bagnulo braun wrote:
> Let me see if i manage to express more properly what i am trying to say and 
> figure out if the agree or not.
> SAVI is not chartered to solve a tool to substitute ingress filtering. It is 
> chartered to design a solution that complements ingress filtering. So, 
> basically to complement ingress filtering enhancing the security provided by 
> ingress filtering, with a higher granularity. ingress filtering works at the 
> route and with a prefix granularity and avi can work at a host level 
> granularity.
>
> That is what i meant by assuming ingress filtering. In order to identify that 
> threats that SAVI can tackle, we can assume ingress filtering and see what 
> are the residual threats. I am not saying that in order to deploy SAVI , you 
> need to have universla deployment of ingress filtering.
> Makes sense?

Yes, agree.

(A part of my comment related to the fact that I was not sure if SAVI 
solutions were also allowed to provide an ingress filtering solution: 
"both get turned on if you turn on this toggle".  But it's fine if 
it's a complement.)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Oct 2010 07:21:16 -0400

The discussion in the WG about SAVI and prefix filtering has actually 
led the documents to include mechanisms for SAVI switches to enforce 
prefix behavior (BCP 38 compliance.)  I would agree that such a feature 
is of small value assuming the ISP is providing BCP 38 filtering at the 
edge anyway.

One of the reasosn for including the feature is that it allows the 
enterprise deployment to take responsibility for complying with BCP 38 
whether or not the operator does his job.  Traditional BCP 38 
enforcement is at a very different topological place than SAVI enforcement.

Yours,
Joel

On 10/13/2010 3:43 AM, Pekka Savola wrote:
>> Let me see if i manage to express more properly what i am trying to
>> say and figure out if the agree or not.
>> It is chartered to design a solution that complements ingress
>> filtering. So, basically to complement ingress filtering enhancing the
>> security provided by ingress filtering, with a higher granularity.
>> ingress filtering works at the route and with a prefix granularity and
>> avi can work at a host level granularity.
>>
>> That is what i meant by assuming ingress filtering. In order to
>> identify that threats that SAVI can tackle, we can assume ingress
>> filtering and see what are the residual threats. I am not saying that
>> in order to deploy SAVI , you need to have universla deployment of
>> ingress filtering.
>> Makes sense?
>
> Yes, agree.
>
> "both get turned on if you turn on this toggle". But it's fine if it's a
> complement.)
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 13 Oct 2010 04:36:34 -0700

On Oct 13, 2010, at 4:21 AM, Joel M. Halpern wrote:

> The discussion in the WG about SAVI and prefix filtering has actually led the documents to include mechanisms for SAVI switches to enforce prefix behavior (BCP 38 compliance.)  I would agree that such a feature is of small value assuming the ISP is providing BCP 38 filtering at the edge anyway.

Of small value to whom? We have a number of access ISPs that deploy IP Source Guard (Cisco's SAVI-for-IPv4) as their way of implementing BCP 38. And recall that some ISPs say that they don't want to turn o BCP 38 uRPF because the value is not to them but to other ISPs; with SAVI technology, the value is also to one's own *enterprise* network.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Oct 2010 09:38:01 -0400

My comment was quite specific.
If the access ISP is performing BCP 38, then having SAVI also perform 
BCP 38 checking is a small increment.

I agree that when the ISP is not doing BCP 38, or if the topology is 
such that the ISP can perform SAVI, then the value of including BCP 38 
enforcement in SAVI is larger.

The reason I phrased my comment the way I did is that the suggestion 
from other participants in the discussion was that the SAVI threats 
document should talk about what SAVI can do with the assumption of BCP 
38 deployed by the ISP.

The debate about who should do 38 work, and why, is a different question.

Yours,
Joel

---

From: Pekka Savola <[email-masked]>
Date: Thu, 14 Oct 2010 13:22:22 +0300 (EEST)

On Wed, 13 Oct 2010, Joel M. Halpern wrote:
> The reason I phrased my comment the way I did is that the suggestion from 
> other participants in the discussion was that the SAVI threats document 
> should talk about what SAVI can do with the assumption of BCP 38 deployed by 
> the ISP.

My comment was actually even more specific than that.

The assumption I though Marcelo had was that the enterprise itself 
performs BCP 38 on the router connecting the LAN interface, and you 
look at what happens when you enable SAVI on the Ethernet switch on 
that same LAN. You were the first to mention ISP in this thread :-)

(The same applies if the ISP runs BCP 38 on a LAN regardless of 
whether it connects customers or not, and then enables SAVI on the 
LAN.)