[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
>The 32 bit hack probably will not be enough. Folks have proposed the use of
>SNOOPing protocols that need to look at the TCP seq numbers passing by to
>enhance the performance of TCP on wireless/mobile links.
Indeed. This is yet another reason to avoid such hacks, which I feel
are a bad idea anyway. (The requirements of special links, such as
radio channels, are IHMO better addressed with mechanisms operating
down at those levels, not with hacks to an Internet standard transport
protocol that must, by its very nature, remain generic. But I digress.)
As I said earlier, one of the side benefits of encryption is to promote
cleaner protocol layering, which is itself a worthwhile goal.
>While I am not fond of the idea of this form of "management" I agree that
>many people have become dependant on the use of port numbers for managing
>their networks (firewalls, filters, etc.)
Interesting examples. A firewall that filters on port numbers is a
security hack that is obviated by IPSEC. If I give you the means to
authenticate every packet you let into your network, doesn't that
eliminate the need for a conventional packet filter?
Actually, an IPSEC gateway can *augment* a packet filter. Instead of
making ad-hoc filtering decisions on unauthenticated header
information that can easily be spoofed, you can make them on the basis
of cryptographic authentication that tells you -- quite reliably --
WHO sent you this packet in addition to WHAT he sent you. Isn't that
what you really want to know?
Phil
Follow-Ups:
References: