Re: [savi] Status of draft-ietf-savi-threat-scope

[Stephen Farrell <[e-mail]>]

Hi Jean-Michel,

On 08/06/11 18:28, Jean-Michel Combes wrote:
> Hi,
> 
> At first sorry for the delayed reply.
> 
> Please, see my comments inline.
> 
> 2011/5/30 Jari Arkko <[e-mail]>:
>> Joel,
>>
>>> As I have said, i am happy to make most of the changes.
>>> However, there are two changes requested by Ralph that change the scope in
>>> a way that I do not feel I (or you) can call for.
>>> I have been awaiting the Chair's review on these two substantive issues:
>>>
>>> 1) The issue of analysis of the effect of SAVI, and what threats remain
>>> after SAVI was requested by Stephen.  I pointed out that this is not in
>>> scope for the document, and he said that he wanted it anyway.  I punted to
>>> you and the chairs.  I believe it would take WG agreement, AD agreement on
>>> scope change, and chair direction, before I can make that change.
>>
>> My opinion is that this document should NOT do that analysis or attempt to
>> find out precisely what residual threats are after some set of SAVI tools
>> have been implemented in a network. I think we touched upon it in the call,
>> but I  can talk to Stephen about it.
> 
> 
> I agree with Jari:
> (1) IMHO, this would be like to put the cart before the horse :)
> (2) to doing such an analysis you need a clear specification of a SAVI
> mechanism which is outside the scope of this document. BTW, during my
> review of FCFS SAVI for the ID Write-Up document, text about residual
> threats was added inside the Security Considerations section. I will
> carefully check that the DHCP SAVI, SEND SAVI and the Mix Scenario
> documents take into account this issue before requesting AD/IESG
> review.

So my question then is where will I go to find a description of
the residual threat for SAVI generally? Right now, it looks like
there's going to be no place for that.

The problem I see with that not being available is the following.

Each SAVI mechanism (FCFS etc.) is going to catch certain forms
of spoofing but inevitably leave others available and as you
say those mechanism-specific residual threats will need to be
documented in each SAVI spec.

But I think there are dangers inherent in deploying a network
with multiple SAVI mechanisms because of this - the issue being
that an innocent party might be blamed for some action on the
basis that a combination of SAVI mechanisms makes it "impossible"
that the action actually involved spoofing.

That kind of thing has happened in DRM-related cases so I
think its important that the residual threat when all the various
SAVI mechanisms are defined be properly documented somewhere.

In addition I would assume that vendors are likely to implement
more than one SAVI mechanism in some of their products, so
customers for those products should also be interested in the
residual threat for combinations of SAVI mechanisms.

And I think that only the SAVI WG will have the expertise
required to do that.

Would it make sense to try get someone to write a document
just on that towards the end of the process? (Assuming you
could get a volunteer? I can try see if some security area
type person would be willing to help as well if you like.)

Cheers,
Stephen.