[e2e] Security implications blurring the name/address distinction

[David P. Reed]

We've strayed far afield from the original question, prompted by my 
digression about the history of "not securing" TCP.   And it is great to 
have this discussion - it would have been even better to have this 
discussion years ago!

Both Vadim and Joe make good points, from particular points of view.  
Since they are both right, I think it's worth teasing out the structure 
of the problem here.  (Lloyd - in this I'm not intending to be 
sanctimonious, just slightly pedantic in hopes of better clarity).

There are two end-to-end security properties under discussion here:

1) end-to-end messages contain names and data that are certain to be 
correct, without depending on the transport. (integrity and )

2) endpoints' workload should be protected as much as possible from 
hostile actors. (protection from denial of service)

There is a third security property that is somewhat controversial - 
end-to-end messages should be readable only by authorized recipients 
(CALEA-not).

Vadim points out that confusing network addresses with endpoint names is 
both unnecessary and opens up risks to the first property.  The cost of 
his proposal is maintaining two sets of names, exposing only the address 
hints to the network.  This also helps manage the third property (though 
traffic analysis can reveal something about the messages if the 
addresses are too richly endowed - encrypted onion routing minimizes the 
third risk).

Joe focuses on the need for measures to minimize the denial of service 
risk.   There are other possible measures that could manage this, once 
one realizes that this risk has little to do with end-do-end naming, and 
everything to do with "universal addressibility".

The risk of each node being able to address every physical node in the 
network, which is mostly a good thing, leads to all kinds of denial of 
service possibliities.

This really has little to do with the "end-to-end" protocol (whether TCP 
or UDP), though.

A much better formulation of the denial of service risk that arises due 
to network addressing  would focus entirely on the IP layer, and not on 
TCP at all.

Solutions to the denial of service issues would then focus on the work 
factor involved in a malicious actor being able to impose work on other 
actors, the cost of detecting and disciplining the malicious actors, and 
the cost of isolating disruption.   One would then focus on IP layer 
solutions that address these problems.  Such IP layer solutions might 
involve filtering gateways that have time-varying tokens for entry, 
time-varying addresses (changing your phone number is a lot easier than 
changing your name when harassed), network layer packet backtrace 
capability, eliminating or guarding "packet amplifiers" like broadcast, etc.

But by confusing the layers, we confused the responsibility for very 
different security properties, and a better layer separation would have 
been a good idea!

I shouldn't need to say it here, but TCP is not the perfect embodiment 
of the "end-to-end" principle, but instead is full of compromises. It's 
far more end-to-end  than was SNA or Tymnet or NCP, some of its 
predecessors.   The sharing of the name field was indeed such a 
compromise.   We did it in the name of "saving header overhead", and 
because the address/name debate was not fully understood by the community.

I feel bad, though, that the "security" community seems to take the 
blurred distinctions as a given, blurring their own notion of what makes 
a secure network.  As Vadim rightly points out, security should not be 
the province solely of the network administration, yet that is where the 
burden is put by most corporations, including most major endpoint 
application vendors (e.g. Microsoft gets sucked into discussions about 
"open ports" as if that puts the end-to-end virus or worm security risk 
into the realm of firewalls to fix).