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

[Pete McCann <[e-mail]>]

Hi, Joe,

On Fri, Dec 10, 2010 at 9:02 PM, Joe Touch <[e-mail]> wrote:
>> The goal is to enable middleboxes to filter out unwanted traffic as close
>> to the sender as possible.  By adding a public-key based authentication
>> tag, middleboxes unknown to the original sender at the time he sends
>> the first packet can independently validate the signature and check the
>> reputation of the sender (similar to what DKIM does for e-mail, but this
>> is for transport connections).
>
> If a middlebox isn't on the path of the first packet, then:
>
> a) it isn't a NAT; that traffic would be blocked
>
> b) every packet would need to contain ALL the information needed to explain
> how to authenticate itself
>
> The latter seems prohibitive, in terms of space (just as an overhead,
> regardless of whether it fits in the TCP option space).

Sorry, all I was trying to say was that the client doesn't need to
know what middleboxes are on the path at the time it sends its
first transport packet.  These are dynamically discovered as the
first packet passes along the path.

Certainly, if the path changes, some kind of path restoration will
be needed.  That could be done end-to-end by periodic refreshes
of the ESTABLISH message or by some middlebox that has knowledge
of the path change and is both on the old path and the new path.

>> 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.
Faster if hardware acceleration is available.  As Moore's law continues,
I expect that the connection setup time will be dominated by the
message propagation delay which will be one or two orders of magnitude
higher than this.

> 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.  I think we could get up to a substantial fraction of 1gpbs
even with a software implementation.  Hardware assist should have
no problem keeping up at higher line rates.

>>> - signing the headers, i.e., to provide secure 'safe packet' tags, is
>>> insufficient protection against attack; an attacker can still read AND
>>> modify the data in the packets
>>
>> Completely agree; note that signing headers only is just one of the
>> options supported by the draft, and I expect coverage of the full
>> data packet will be commonly used.  But, the option to cover just
>> the header (or to omit the HMAC and just use a cookie) are there
>> to provide a low-overhead solution for particular threat models, e.g.,
>> when all attackers are off-path.
>
> How do you know when attackers are off-path?

It's just an assumption of the threat model in a particular deployment.
If you feel the need to protect against on-path attackers, by all means,
do a full HMAC over the packet.

> A problem statement would be a start, including a threat model and a
> description of the costs (overhead, computation, etc).

Will work on this, thanks.

> Also how much effort will this require of the protected endpoints. I'm not
> sure I want to negotiate keys with a dozen middleboxes that all are trying
> to be helpful to me, and all are upstream on the same connection.

The number of middleboxes on any given path is likely to be proportional
to the number of administrative domains through which the packet passes.
I expect this will be less than 10 for most paths.  Also, the key derivation
only needs to be done once the first time you interact with a given hostname.
You should cache the Long-Term-Shared-Secret after that and use simple
HMACs to derive keys for subsequent transport connections.

> 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.

>
>> 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.

-Pete