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

Field Variance Analysis

> From: Craig Metz <cmetz@sundance.itd.nrl.navy.mil>
> 	Yes. "Invariant = If this field changes, the packet is not authentic".
> This is to say that there exists a set of fields, which I call invariant, that
> MUST be passed through the network without change in order for the packet to
> maintain authenticity. If these invariant fields are changed, then the packet
> is not authentic. Which fields fall within this definition of invariant is
> a decision that we need to make by some sort of reasonable consensus.
>
First, I will agree with Craig's statement, there are header fields that
must pass though the network unchanged.

Second, I will then utterly disagree with the remainder of his analysis!

The unspoken fundamental assumption is that it is better to throw
traffic away in the event of uncertainty.  I do not agree.  We must
design for _only_ the utmost certainty.

We are not authenticating packet headers.  We are authenticating payload
data.  The purpose is to get that data across a diverse network, not
throw as much as possible away.

Therefore, in order to promote _use_ of authentication, we need to make it
as easy and robust to _use_ as possible!  Suddenly discovering that data
stops flowing because of a change in some router somewhere that is not
under the user's control will not be a big win, folks....

                                ----

As to specific IP header fields, I have written code that is widely
deployed that changes the TOS en route.  That is not a "security"
violation, it does not affect the _DATA_, it just changes the path
characteristics....

I have worked on at least 3 routers that set the "reserved" bit in the
IP header when congestion is experienced, and every router and host that
I have worked on passes that bit transparently (even if it doesn't use
or understand it).

My current software base does not use most IP options, and certainly not
the IPSO.  I do not care about its authenticity, since it does not
affect the Security Association that I have with my peer.

In short, I am not currently working on software that could possibly
talk to Craig's software.  That is up to him.  It may be his security
policy.

But I plan on _giving_ this software away to every compatible router
vendor that I have ever worked with, and I won't design a security
policy that could cause the Internet to fragment!

                                ----

There are only a few fields that require authentication:

 - the Destination, as it is the field that together with the SPI will
   determine the Security Association.

 - the Source, since we probably want to send a response.

 - the Length, to preclude appending attacks.

There are a couple of other fields that we might as well authenticate,
as they well known to be invariant:

 - Version (has to be constant).

 - Identification (invariant end-to-end, or fragmentation would fail).

 - Protocol (it had better be ours, or processing will fail anyway).

                                ----

Here is the pseudo header that I have implemented (so far only in the
receive direction).  I beleive this is similar if not identical to what
other vendors have implemented, and hope to test this week.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |       0       |          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |0 0 0|            0            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |    Protocol   |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Source                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Destination                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Options = 0                  |  Padding = 0  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The rationale is that since we can't predict rearrangement of options,
we can't verify them.  But if some router _ADDS_ or _REMOVES_ them, or
lengthens or shortens existing ones, that in itself could be a security
violation, which we can easily test for, using IHL and zero placeholders.

I am zeroing not just the Option data fields, but the lengths and types,
too.  I don't care what they are, as they have absolutely no effect on
the authenticity of the payload.  Routers can rearrange them to their
heart's content....

I never reverse LSRR, so I do not care how authentic it may be.

Bill.Simpson@um.cc.umich.edu
          Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: