Re: [nbs] [Int-area] New draft related to name-based sockets

Joe Touch <touch@isi.edu> Sat, 11 December 2010 19:57 UTC

Return-Path: <touch@isi.edu>
X-Original-To: nbs@core3.amsl.com
Delivered-To: nbs@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 357903A6CF0; Sat, 11 Dec 2010 11:57:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.597
X-Spam-Level:
X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JBulgxdAcoe; Sat, 11 Dec 2010 11:57:39 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 151623A6CAF; Sat, 11 Dec 2010 11:57:39 -0800 (PST)
Received: from [192.168.1.92] (pool-71-105-94-39.lsanca.dsl-w.verizon.net [71.105.94.39]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id oBBJwfXT012596 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 11 Dec 2010 11:58:50 -0800 (PST)
Message-ID: <4D03D7EE.9010308@isi.edu>
Date: Sat, 11 Dec 2010 11:58:38 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Pete McCann <mccap@petoni.org>
References: <AANLkTin4-uiFXoS9DaDWtTQartUb6DKEee+B8717odm5@mail.gmail.com> <4CFFFD8D.2000601@isi.edu> <AANLkTi=KG_CL5hQ0k4JQAy6oB=3RV3UWGQxTbYzGmsR3@mail.gmail.com> <72504C2E-CE17-4AE0-ACBC-E6BB4F002267@isi.edu> <AANLkTimmQ-HKJBpoqQCc9t1P=GFPFa8VojPTFh-D8Nay@mail.gmail.com> <4D011EF3.8080407@isi.edu> <AANLkTi=+PQKxMj4C83A90-DK3V-89ydBR02rR5zvA68L@mail.gmail.com> <4D0129B3.4050906@isi.edu> <AANLkTi=j1NdofgpJUDjFPcGSTT_96GByLaNTRxx7yuCy@mail.gmail.com> <4D01CE2A.9090804@isi.edu> <AANLkTim4jRQUE=FOvtQRZa7mFH1LS1h=OwkdspEV2k_J@mail.gmail.com> <4D02E9D9.2030508@isi.edu> <AANLkTimFfCcd4AnVejtp0cBwj6y-KVF+jCdH69nw3=xr@mail.gmail.com>
In-Reply-To: <AANLkTimFfCcd4AnVejtp0cBwj6y-KVF+jCdH69nw3=xr@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: "int-area@ietf.org" <int-area@ietf.org>, "nbs@ietf.org" <nbs@ietf.org>
Subject: Re: [nbs] [Int-area] New draft related to name-based sockets
X-BeenThere: nbs@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Name based sockets discussion list <nbs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nbs>
List-Post: <mailto:nbs@ietf.org>
List-Help: <mailto:nbs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nbs>, <mailto:nbs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Dec 2010 19:57:40 -0000

Hi, Pete,

On 12/11/2010 9:04 AM, Pete McCann wrote:
...
>>> By performing a dynamic key derivation
>>> operation, the endpoint and the middlebox can agree on a shared secret
>>> to protect subsequent packets with an HMAC-based tag which should
>>> be verifiable at line rate.
>>
>> You expect the middlebox to derive a shared key with the endpoint WHILE in
>> order to protect subsequent packets?
>>
>> What will you be doing with the packets for the connection in the meantime?
>> (this will take a while)
>
> An elliptic curve cofactor diffie-hellman computation on known keys
> takes less than 10^6 cycles:
>
> http://cr.yp.to/ecdh/reports.html
>
> This would be under a millisecond on modern processors in software.

Right, but that's 1,000 such attempts per second. That puts a cap on 
software support for middleboxes that is fairly low.

>> HMAC verificiation at line rate is likely to require additional hardware
>> that middleboxes typically don't have (and cannot afford, AFAICT).
>
> I haven't run the experiments, but from data on the web it looks like
> an HMAC is about two orders of magnitude faster than a D-H key
> derivation.

My previous experiments suggest that HMAC calculations are fairly 
prohibitive for line-rate devices in the middle of the net as well.

 > I think we could get up to a substantial fraction of 1gpbs
> even with a software implementation.

See RFC1810; MD5 is one of the fastest algorithms. You're now talking 
about a single CPU running flat-out 100% just to keep up with the line 
rate, maybe...

...
>> Well, you'll introduce a lot of delays every time you meet a middlebox in
>> the middle of a connection. The overhead in EACH packet that is required to
>> ensure that a packet can be signed is a bit prohibitive, AFAICT, as well
>> (what's the raw number?)
>
> Hopefully the discussion above clarifies.  The public key operations are
> only on the first time two parties interact in some way.  An ECC digital
> signature with NIST P-256 is 64 octets long.  The HMAC tag in subsequent
> packets (when using the pickle packet fragment signature header given
> in the draft) is 20 bytes plus variable amount depending on what level
> of protection is desired.  I expect SHA-1 (20 bytes) to be nominal for
> most connections.  The draft has enough flexibility to allow multiple
> HMACs on each packet to account for multiple middleboxes that all
> want to validate a tag from the same endpoint; however, I expect in
> most deployments that the tags will be computed on a pairwise basis
> between adjacent middleboxes so only one signature per packet will
> be needed.

Not sure what that means; why would adjacent middleboxes be involved, 
vs. separate interactions between each such middlebox and the endpoint. 
This needs to be made more clear in your architecture.

>>> TCP-AO is in an architecturally similar place in the stack but is also
>>> end-to-end
>>> and doesn't have any key management defined for it.
>>
>> The key management is separate, but as you note there's not enough
>> information after connection start to establish shared keys with new parties
>> (the ISNs are gone).
>
> But configuration of the root symmetric shared secrets must be done
> manually, no?  Public key cryptography offers more flexibility and security
> in this respect.

TCP-AO can easily be extended to include other algorithms that support 
public-key (you just need to specify the other algs and register them 
with IANA, as per RFC 5926, AFAICT.

Joe