Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks

[Tom Herbert <[e-mail]>]

On Tue, Aug 2, 2016 at 12:47 AM, Eliot Lear <[e-mail]> wrote:
> Hi Tom,
>
>
> On 8/1/16 10:06 PM, Tom Herbert wrote:
>
> TOU will negotiate a session identifier (similar to connection
> identifier) in QUIC. With this the TCP endpoints no longer use the
> 5-tuple to identifier the connection, they use the session identifier.
> This provides unambiguous connection identification that is
> independent of addresses or encapsulating UDP ports (the most
> immediate problem this resolves is NAT state remapping). Strong
> security is required to prevent connection hijacking and there are a
> couple of other caveats. Please look as section 3 in
> draft-herbert-transports-over-udp for details.
>
>
> TOU is similar in many ways to what HIP did in the early days, and the HIP
> developers had a pretty cool demo of it.  The threats we faced back then
> were nowhere near as advanced as they are today, nor are they as prevalent.
> There is not a single platform upon which you base your software that hasn't
> been attacked successfully, although some have been attacked more regularly
> than others.
>
> Let me be as clear as I possibly can be: I view a protocol that doesn't
> offer an answer to the question “who initiated the communication” as unsafe

Eliot,

With that view IP is completely unsafe and shouldn't be deployed since
IP source addresses can and are trivially spoofed. Session identifiers
with security that authenticates the peer provide an unambiguous and
far more trustworthy answer to the question about who initiated a
communication.

> to be deployed on the Internet.  I will make another bet with you, that at
> least half of your user base is running on old code with known
> vulnerabilities.  This is even more critical on battery-powered constrained
> devices, where a broad-scaled and sustained DDoS attack could drain those
> batteries and harm a lot of people, in a short period of time.
>
Yes, we all want DDoS prevention. But my application needs to be able
to run securely on _every_ network on the planet. Unless you can prove
that every one of these networks implements some common standard DDoS
mitigation and other required security mechanisms, then I really have
no choice but to treat the network is an insecure black box, assume my
applications are at risk, and implement all of my own security.

> If there are tradeoffs to be made in mobility design because of this, then
> those tradeoffs should be made.  But before you view it in that light,
> lengthy research has demonstrated that RF requires repeated selection
> queries to determine what is available.  That is the work done by SCTP
> researchers such as Randy Stewart, and so mobility isn't being traded off at
> all.
>
> You are seeking formal agreement of network behavior.  I am seeking an
> answer to my question.  If we formalize the answer to that question, then
> you have what you want and I have what I want.  I've been told that QUIC has
> such an answer to my question, which is good.
> I'd like to understand how that is accomplished in a secure manner.
> Certainly integrity protecting the 5-tuple and any sequence #s sounds like a
> good idea, to say the least, if it can be efficiently accomplished.
>

To be clear I am not seeking formal agreement of universal network
behavior (I believe that is supposed to be already covered by
networking layer standards), we are trying to resolve protocol
ossification to move the Internet forward. Protocol ossification
happens in the network when devices anonymous to the endpoints attempt
to interpret transport layer information to some effect and does this
without the auspices of any standard. Usually this is with benevolent
intent, but the problem is that when the end points attempt something
"new" (e.g. TCP fast open, new TCP options, using SCTP, trying sustain
connections between mobile networks) the network can break E2E
communication in a variety of ways because the communication doesn't
match _its_ concept of what a "legal" communication is. Encrypting the
transport layer is the only proposed solution to defeat protocol
ossification.

I don't believe the PLUS proponents will argue against the rationale
of encrypting the transport layer. Protocol ossification is a real
problem and we can demonstrate several examples where it has thwarted
innovation of transport protocols. What is at question is what
transport layer information hosts are either required or should
voluntarily "give back" once the transport layer is encrypted. IMO,
from the perspective of a large application provider, the default
answer is currently none. If signaling transport layer information
were to be explicit between hosts and network devices, and there is an
established trust relationship with an agreement the spells out the
precise use of the information and the scope of information
propagation-- then I think there is a much better chance to achieve
the cooperation necessary to solve things like the mobile DDoS problem
you mentioned above. I think the mobile guidance draft
(draft-flinck-mobile-throughput-guidance) is on the right track in
this regard, it make signals explicit and non-anonymous (although I
don't like the part where they allow middleboxes to parse and modify
TCP options, IMO this, as well as PLUS, should be using HBH options
for host-network signaling). Explicit non-anonymous signaling can also
adhere to the E2E model if network devices are expressly acting on
behalf of a host with specific directives to do that.

All of this is just my opinion, but it is why I had to hum no at the BOF...

Thanks,
Tom

> Eliot
>