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

[Joe Touch <[e-mail]>]

Hi, Pete,

On 12/10/2010 9:54 AM, Pete McCann wrote:
> Hi, Joe,
>
> On Fri, Dec 10, 2010 at 12:52 AM, Joe Touch<[e-mail]>  wrote:
>>> I hope
>>> you can find the time to read the draft.
>>
>> I have, albeit briefly. Some comments:
>
> Great, thanks!
>
>> - it'd be useful to understand the problem this is trying to solve. The doc
>> just says "avoiding unwanted traffic", but doesn't define the boundaries of
>> that problem
>
> Yes, re-reading the introduction now I see it could use some additional
> explanation.
>
> 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).

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

HMAC verificiation at line rate is likely to require additional hardware 
that middleboxes typically don't have (and cannot afford, AFAICT).

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

> There have been a range of such options discussed in the literature
> such as Lightweight Internet Permit System (LIPS) [1] and Passport [2].
> I believe LIPS doesn't protect the payload in any way and Passport
> protects only a limited portion of the payload.
>
>> - during the TCP-AO discussion, the issue of trying to exchange keying info
>> inside TCP connection establishment was considered, and determined
>> infeasible (for the reasons already noted; need for too much space, and
>> inability to use the data of a SYN as a shim layer)
>
> Yes, I definitely need a lot of space to put the DNS names and public
> key signatures in.  If we are dealing with a path that does TCP re-segmentation,
> it might be better to use UDP as you suggest below.
>
>> - overall, you're doing a bunch of things at once, and the rationale is not
>> clear
>
> The draft attempts to describe a complete system including both the
> packet authentication tags, key distribution, and DNS-based credentials.
> I know this is unusual for work in the IETF that is usually done in smaller
> chunks.  The draft grabs a bunch of bits and pieces and shows how to
> fit them together, but maybe an overall system diagram would help.

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

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.

>> It would be useful to start with a concise description of the problem you're
>> trying to solve, the conditions for a solution (backward compatible or not,
>> etc.), as well as a comparison of existing solutions in this space (IPsec,
>> TCP-AO, SSL), and a discussion of the value this solution adds.
>
> IPSec and SSL are end-to-end, and the Diffie-Hellman exchange done
> up front means that middleboxes have no chance to even see the identities
> being exchanged in the credentials, let alone validate them (I'm sure the
> designers of these protocols consider that a feature).  The endpoints of
> an IPSec or SSL connection have to be known to the sender in advance.
>
> In contrast, pickle packets put the DNS names in the clear for any middlebox to
> examine and validate.  They can even participate in the key distribution
> and subsequently filter out packets with bad authentication tags.  All without
> pre-configuring their identities into clients or adding additional round-trips
> (modulo the DNS queries, which could benefit from caching).

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?)

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

Joe