[e2e] Security implications blurring the name/address distinction

[Joe Touch]

David P. Reed wrote:
> 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).

Having separate network addresses still requires that they be secured 
somehow, or else spoofing can still occur. Granted, that does help 
decouple the TCP vs. IP solution space for such solutions, though.

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

Actually, I'm dealing with all sorts of attacks, not just DOS. I don't 
consider PMTU distruption a DOS attack, nor do I consider TCP RSTs one 
either. These are attacks on connections, not on bandwidth or buffer 
space, which is what I think of as a defining property of a DOS attack.

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

As above, these aren't DOS attacks. They are attacks on the protocol. 
It's natural to assume that attacks on a specific protocol are solved by 
securing that protocol - in this case TCP. However, because TCP uses the 
pseudoheader, and because that information isn't authenticated, TCP is 
expected to take up the slack, and with mechanisms that are 
correlation-based, not security-based.

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

Security of ICMP should definitely be the purvue of a network 
administrator. Applications can't protect connections that are cut from 
under their feet.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050216/082411c8/signature.bin