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

Jean-Michel Combes <> Wed, 15 June 2011 14:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AEA1921F8585 for <>; Wed, 15 Jun 2011 07:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.384
X-Spam-Status: No, score=-103.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qUWd4iJSg9dl for <>; Wed, 15 Jun 2011 07:46:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3A72021F8584 for <>; Wed, 15 Jun 2011 07:46:23 -0700 (PDT)
Received: by yie30 with SMTP id 30so399746yie.31 for <>; Wed, 15 Jun 2011 07:46:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=563b64dweD8HSqdjNJ03PTHLcr33B/ZLJQXQBDK0BEY=; b=lDgpf2aWl1qIEWo/esE6TGJge4U66cCUsWaFZWcslec5lRVlu5vc9FPRYVthHF6NQy 4aYjdttJ5oHhL+9YslrshS/BCJEJi91kdgoGkvDbfhlavFSZ6+7v9Q+uAhQvA27grhRV yf3AW5SVfKkdyo8wXNHIBbfy/tF0tKbRXljbg=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CLkgq124GsBKZvHAfFkPBfg1fVzvR+1jii4KyuXA2BmFPyQVuOn1K5OtnP8sjObXUd fvnZa0CjfhCd4wBmovcfz2OP8hpMczR/DnaRuI5jYCVXeE4APzTgQPt4qyd6EPRBJV39 4zbeSv664y1dLCL9VOsJfG6OfW0gMR3aKeID8=
MIME-Version: 1.0
Received: by with SMTP id e30mr1062145yhn.226.1308149182185; Wed, 15 Jun 2011 07:46:22 -0700 (PDT)
Received: by with HTTP; Wed, 15 Jun 2011 07:46:22 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Wed, 15 Jun 2011 16:46:22 +0200
Message-ID: <>
From: Jean-Michel Combes <>
To: Stephen Farrell <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc:, SAVI Mailing List <>
Subject: Re: [savi] Status of draft-ietf-savi-threat-scope
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mailing list for the SAVI working group at IETF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Jun 2011 14:46:25 -0000

Hi again,

2011/6/15 Stephen Farrell <>ie>:
> Hi Jean-Michel,
> On 15/06/11 15:11, Jean-Michel Combes wrote:
>> Hi Stephen,
>> I totally agree with you about the fact that deploying different SAVI
>> solutions on a same architecture may have as consequences extra
>> residual threats.
>> That's why, from my point of view, the right place for such an
>> analysis was the MIX SAVI document
>> (
> So if you're saying that that document will eventually contain
> the residual threat analysis for all the others then I'm fine
> with that. Sorry for not spotting it, but I guess I can use
> the missing security considerations section in the -00 as my
> lame excuse:-)


> If that's the plan I'm happy to clear that part of the discuss.

Yes that's the plan and this is clearly identified in my TODO list for
the review of this document.



> Cheers,
> S.
>> Cheers.
>> JMC.
>> 2011/6/15 Stephen Farrell <>ie>:
>>> 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 <>et>:
>>>>> 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.
>> _______________________________________________
>> savi mailing list