Re: [privacydir] request for a SAVI doc review

Ted Hardie <> Mon, 31 October 2011 20:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B7FE911E81F3 for <>; Mon, 31 Oct 2011 13:08:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.516
X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nVRMKUVnEO7Z for <>; Mon, 31 Oct 2011 13:08:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A523411E81ED for <>; Mon, 31 Oct 2011 13:07:55 -0700 (PDT)
Received: by gyh20 with SMTP id 20so7535242gyh.31 for <>; Mon, 31 Oct 2011 13:07:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LNBTyLWqu7JF07R4ZZe8mHtuV2yeWO0mCjn383MsYbI=; b=V9DQWaKTPKVvPk4XPpHZyFpHTJXNqA+vh0DkGOcfuVi/M7KDxAOhmanhXRegKSPDcM xSVkCiBc1/qtdY2ApxvQ654ER/oncCjzF1H0FekX0rRlDJVe2WiBiID7/BvUpjC+BPbS 6yO/61qbQQyuFz6+bLPOGqH7Pm5VYwETxvB5w=
MIME-Version: 1.0
Received: by with SMTP id t4mr18693889yhd.58.1320091675264; Mon, 31 Oct 2011 13:07:55 -0700 (PDT)
Received: by with HTTP; Mon, 31 Oct 2011 13:07:55 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Mon, 31 Oct 2011 13:07:55 -0700
Message-ID: <>
From: Ted Hardie <>
To: Stephen Farrell <>
Content-Type: multipart/alternative; boundary="20cf300510406005e204b09dcb0a"
Subject: Re: [privacydir] request for a SAVI doc review
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Privacy Directorate to develop the concept of privacy considerations for IETF specifications and to review internet-drafts for privacy considerations." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 31 Oct 2011 20:08:00 -0000

Hi Stephen,

I've read through the framework document.  My baseline impression is that
the document makes a presumption about the relationship between the host
and the network employing SAVI that is true when it is the access network
(that is, the network assigning the IP address to be verified).  In that
deployment scenario, it is expected for the network to be able to associate
layer two identifiers with the layer 3 identifier (after all, it must to be
able to deliver return traffic).

What's not clear to the naive reader (read: me) is how you prevent SAVI
from operating from other parts of the network; that is, how does the
overall framework guard against SAVI being used by some later network
on-path getting access to these bindings? I assume that this is detailed
elsewhere in the protocol documents, but I believe a short discussion of
the privacy threat in framework, along with a pointer to the protocol
mechanism would be valuable.

If the expectation is that SAVI can operate from multiple places in the
network (including, say, the destination network), then I believe there is
a more serious privacy concern.


Ted Hardie

On Thu, Oct 27, 2011 at 9:07 AM, Stephen Farrell

> Hi,
> There's a SAVI document [1] on the Nov 3 telechat. I'd appreciate
> a review of that from a privacy perspective if someone has the
> time in the next week. (Just reply to this if you've time.)
> Previous SAVI documents have generated privacy related
> DISCUSSes [2,3] which may be useful background.
> Thanks in advance,
> S.
> [1]**doc/draft-ietf-savi-framework/<>
> [2]**doc/draft-ietf-savi-fcfs/<>
> [3]**doc/draft-ietf-savi-threat-**scope/<>
> ______________________________**_________________
> privacydir mailing list