[e2e] purpose of pseudo header in TCP checksum

[Joe Touch]

Vadim Antonov wrote:
> On Wed, 16 Feb 2005, Joe Touch wrote:
> 
> 
>>Security at each layer is designed for a different purpose.
>>
>>The only way to secure the network layer information (used at the 
>>network layer (e.g., for forwarding) and transport - for connection 
>>demuxing) is to secure the network layer header. No amount of 
>>application layer protection works there, unless you terminate the app 
>>layer at each hop and forward there (e.g., P2P). Are you proposing that?
> 
> I propose doing security at the appropriate layer.  Data encryption is 
> appropriate at the application-to-application layer, not at the 
> network-to-network (or even host-to-host) layer.

Data encryption should be secured by the source. The IP packet that 
causes the ICMP error is the source, and IPsec is what should secure 
(authenticate) it. IPsec on that packet is the appropriate level of 
security; no application security can authenticate the IP header, even 
when it becomes payload for the ICMP.

> Of course, some paranoid people encrypt data at both network and 
> application layers, but this does not increase security much.

Apps don't secure the IP layer; they often don't know what the IP header 
will be when the packet is emitted (leaving, e.g., source IP address 
unbound at the socket).

>>Sure, you can require only security at the app layer, which means that 
>>layer is going to get a lot of junk misforwarded and mis-demuxed that it 
>>has to invest effort - at the routers and the endstations - processing. 
>>Security at other layers helps winnow that junk before it consumes that 
>>effort inappropriately.
> 
> Misrouted or mis-demuxed junk means only that the routing
> equipment/software is broken.

If the link layer generates problems, the routing system can still work 
fine and be forwarding a packet correctly that some would consider 
'misrouted'.

> Working equipment doesn't do that,
> generally, and it never was a problem, if the routers or switches
> themselves aren't compromised (and when an end-host OS is compromised
> you've got problems way more serious than some additional junk in the
> network traffic).

Or, as above, the link has errors that are undetected (lack of link 
checks, or turning them off for UDP Lite).

>>Security at any ONE layer is doomed. Security is a multilayer issue; 
>>always has been. We can always talk, in the context of multilayer 
>>security, at what layer to address a given vulnerability.
> 
> Of course, but what you need at the network layer is integrity and 
> security of routing information and router OSes, not the 
> integrity/security of user data.

Security of the IP header used for forwarding too.

> This is because data encryption in the network (not at end-points) leaves 
> traffic vulnerable to the snooping or modification by network 
> administrators, who (in most cases) aren't in the same group as service 
> users, and, therefore, have different trustworthiness profile.  On the 
> other hand, they are in control of network routing, so protection of 
> routing infrastructure is appropriately done at the network layer.
> 
> What network layer can do for e2e security is to provide some support for
> resistance to flooding attacks. 

Or attacks on network-level systems, e.g. ICMP. Or attacks on protocols 
that include IP header information at their level - as we've been 
discussing for TCP, e.g.

> Unfortunately, encryption is exactly the
> wrong way to achieve that, because it takes more resources to handle an
> encrypted packet, and the whole point of flooding DoS attack is to exhaust
> resources of a target system.

One point of a flooding attack is to exhaust resources. Other points are 
to disrupt services by killing connections, e.g., or interfering with 
PMTUD.

> VPNs don't do anything to protect routing information, and don't do 
> anything to handle flooding attacks. They mostly create an illusion of 
> network security, distracting people from addressing the real security 
> threats.
> 
> --vadim

You've already spoken of that position before, but it is not relevant to 
this discussion.

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/53265d12/signature.bin