Re: [lisp] RFC 6830 - possible extension.

jnc@mercury.lcs.mit.edu (Noel Chiappa) Wed, 21 August 2013 14:31 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C421121F9B80 for <lisp@ietfa.amsl.com>; Wed, 21 Aug 2013 07:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.762
X-Spam-Level:
X-Spam-Status: No, score=-5.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuYX3zroVWVG for <lisp@ietfa.amsl.com>; Wed, 21 Aug 2013 07:31:00 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id A1AF311E8210 for <lisp@ietf.org>; Wed, 21 Aug 2013 07:31:00 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 2317B18C16E; Wed, 21 Aug 2013 10:30:58 -0400 (EDT)
To: lisp@ietf.org
Message-Id: <20130821143058.2317B18C16E@mercury.lcs.mit.edu>
Date: Wed, 21 Aug 2013 10:30:58 -0400
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [lisp] RFC 6830 - possible extension.
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2013 14:31:05 -0000

    > From: Nick <nick@lupine.me.uk>

    >> The impetus for developing it was the Snowden PRISM/XKeyscore
    >> disclosures - currently, a privacy-conscious ISP can't do much to
    >> prevent traffic (especially headers) between themselves and another
    >> privacy-conscious ISP from being snooped on.  Use of RLOCs instead of
    >> EIDs in the outer IP header means that individual users share an
    >> anonymity set which is the size of the number of users sharing that
    >> RLOC. When both source and destination are obscured this way, it
    >> becomes less "alice and bob are communicating", and more "someone in
    >> chicago is talking to someone in toronto".
 
This sounds quite interesting (although the denizens of certain large
buildings might be grinding their teeth).

All, does this fit within our current charter? If not, something to keep in
mind if/when we redo the charter.

    >> Obviously, preserving this anonymity requires the inner IP headers to
    >> be encrypted

Wonder if it's worth doing the payload, too? Obviously, that would cost more
computing, but...

    > I'm reasonably ignorant of the processes and politics of RFCs and
    >  things.

That's OK, we have plenty of experts on that... :-)

     Noel