[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Network Layer Security Properties

Ran Atkinson:
>In my view, these two properties need to be available in an ordinary
>IP/SIP/CLNP/etc option and must not require the use of an encapsulating
>protocol -- if we want to really provide basic security to the majority
>of the Internet sites.

I don't see how this follows. As the core protocol of the Internet,
IP's simplicity (so far) is largely responsible for the success of the
entire Internet. There's a very real danger of the "second system
effect" in the IPv7 project, especially as the frustrated OSIers get
involved. (Personally I agree with Noel Chiappa that switching the
whole Internet to a new routing and addressing architecture at the
same time would be sheer madness. I'd much prefer to find clever,
compatible ways to get more out of the 32 bit addresses in IPv4
headers.)

So I think it's important to review what I personally consider to be
the most important principles of the current IP (IPv4) design that
ought to be retained in any new IP -- if in fact there *is* to be a
new IP:

1. The protocol is connectionless. (This ought to go without saying,
but I guess it doesn't.)

2. The internet protocol contains ONLY those fields that must be there
for the routers to do their job. This is true for every field in the
IPv4 header with the exception of the Protocol field, which is
interpreted by the destination host.

3. There is a "basic" IP header format with fields of fixed size that
is sufficiently useful to account for the vast majority of Internet
packets. High performance routers can then be heavily optimized around
this format, perhaps by building custom hardware. The relatively few
packets with options can be processed by software with little impact
on average performance.

Principle 3 pretty much follows from 1 and 2. Since network layer
security information is interpreted only by the destination host, by
principle 2 it just doesn't belong in the IP header. Putting it there
anyway could well violate 3, especially since many sites might well
opt to run without network layer security even if it is widely
available.

By the way, some years ago I originally proposed adding authentication
to IP as an IP header option. Jeff Schiller talked me out of it, and
he was correct.

As for the layer 3/4 controversy, I think it shows that there's a need
for both. Layer 3 security is arguably much more flexible and
complete.  It covers and protects any arbitrary transport protocol.
E.g., authentication between TCP and IP protects TCP against
maliciously generated spurious RSTs and connection hijacking.  If the
authenticator includes a timestamp, it could protect against
long-delayed replay attacks (defense against short-term replay would
still be the responsibility of the transport protocol, but this is
something it has to defend against anyway since the Internet can
duplicate packets occasionally on its own.)

And if encryption is used, an eavesdropper is denied the maximal
amount of information.  All he sees is traffic between two hosts; he
can't tell what application or even what transport protocol is in use.

The only problem I can see with layer 3 security has to do with
efficiency.  For example, it breaks Van Jacobson TCP/IP header
compression. Some slow serial line users might not be willing to give
this up to gain all of the benefits of network layer security. If
they're mainly interested in confidentiality, then they could simply
run a stream cipher on top of TCP. This could be part of the
application (as it is in Kerberos) or it could become a TCP option.
This would make security an optional level 4 service.

Phil