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

Re: Field Variance Analysis



In message <199508141948.AA68240@interlock.ans.net>, "William Allen Simpson" wr
ites:
>First, I will agree with Craig's statement, there are header fields that
>must pass though the network unchanged.

	Well, at least we agree here.
>
>Second, I will then utterly disagree with the remainder of his analysis!

	While I find this unfortunate, it's important that we be talking
about these things and come to some sort of consensus.

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

	I think that we are disagreeing as to what certainty we would like
to provide with the Authentication Header. It is my opinion that we need
to provide certainty that the packet that arrives at the receiver is what
the sender expected the receiver to receive and that the claimed sender is
the actual sender. These guarantees are at odds with certainty of packet
delivery in some cases that you have brought up. I have not seen a case
presented yet, however, in which it was not my clear opinion that the spirit,
if not the letter, of the appropriate standards and reasonable network
practice was being violated.

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

	This is a fundamentally important design decision. I believe that
this has already been decided. If it has not, then we better do so now
before trying to proceed, because it has a dramatic effect on further
directions.

	It is my understanding that there are basically three "checklist"
attacks that IPsec must offer reasonable protection against, and it is
my understanding that these are requirements that we either meet or pack
up and go home:

	1. TCP connection stealing
	2. Source-route attacks
	3. IPSO modifications

	The third is one that many people discount, claiming that IPSO is
just broken and shouldn't be a factor. I'm not here to judge IPSO, but
certain government organizations have a large IPSO deployed base and they
won't buy into IPsec at all if it leaves them SOL with IPSO. Both the second
and third on this list implies no alternative but to protect IPv4 options
if we are going to defend against these attacks. If we aren't going to
defend against these attacks, then we can talk in terms of not authenticating
options.

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

	Bill, I've been at sites that use Proxy-ARP as an IGP across multiple
buildings. I've been at sites where admins ROUTINELY assign multiple machines
the same IP address. I've been at sites where a single, massive Ethernet has
over three hundred machines directly attached (no routers, no bridges, all
gobs of big hubs). You and I can probably agree that these are three
scenarios that are examples of bad network design. In none of those cases did
the parts used to build those networks come out of the box drain bamaged --
bonehead network administrators made them that way. And they won't go and fix
it BECAUSE IT SEEMS TO WORK.

	This has a lot to do with my fundamental disagreement with you on the
Cisco/Telebit router issue. On the Ciscos, yes, you can configure them in ways
that will cause them to munge IPv4 headers. This is a configuration that is
as valid per the specs as using Proxy ARP as your IGP, and it's a configuration
that is just as dead wrong. Causing these kinds of setups to break is more of
a feature to me because it forces the admins into the realization that they
are doing something that is really brain damaged and that they better fix it.
IPsec might just provide a suitable carrot to these network admins to fix
things.

	Also, I strongly believe that sites with Cisco routers configured to
munge IPv4 headers are in the vast minority of deployed IP sites. This seems
analogous to engineering all UNIX software to run on a VAX 11/780 just
because some sites still use them. Do you want to be the person at Cisco
that tells large corporate customers who do things right that the security
guarantees they're getting from IPsec aren't as strong as they could be
because it might break some sites who are doing things that are drain
bamaged? I know that I wouldn't want to be.

	And on the NetBlazer... I've used one for a good bit of time, and I
have never noticed it messing with my TOS bits. I'd be interested in more
data on this example of yours (as with the Cisco example, you have provided
a canned conclusion as a reason for why network-level data must be all but
omitted from IPsec without much data to independently confirm or deny your
claims). RFC791 doesn't say it, but it seems to me that routers that twiddle
the TOS bits aren't conforming to the spirit of the spec even if they might
be conforming to the letter. TOS bits tell routers what kind of data the
packet is in a form that routers might be able to deal with in a very
simplistic way (i.e., low-delay, bulk-data). If a router changes the TOS bits,
the routers upstream are getting a different request for treatment than what
the sender asked, and I doubt that the router mucking with the TOS bits has
more information about the type of data being sent than the sending host.

	Please don't interpret this to mean that I'm against operating with
the installed base. This is not so. I'm for trying to push technology, in
this case, trying to push people who've been doing the wrong thing into
fixing what they've got. IPsec could provide the motivation for them to do it.

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

	It remains unclear to me how a router can know more than the sending
host what kind of data is in transit.

	If we find that enough systems mess with the TOS bits, we can call
them variant and move on. Protecting the TOS bits is a Good Thing, IMO,
because it pushes people in the direction I believe is correct. The TOS
bits are mostly unusable even today because so many widely deployed
implementations have completely drain bamaged TOS processing. While I'd like
to see that get fixed, I can live with calling TOS a loss and moving on.
We all have bigger fish to fry.

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

	Is it just me, or do these statements directly conflict?

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

	Again, these are design decisions.

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

	As I understand it right now, we have a number of bubbles forming
of IPsec implementations that won't talk to each other. This is why we
need to come to a consensus as to what goes into the authentication soup.

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

	Then I expect that you'll make sure to give away something that
follows the consensus that develops.

>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 source is also a part of the security association nowadays. Also,
source and dest frequently are needed for transport demuxes (for instance,
finding the right TCP connection).

> - the Length, to preclude appending attacks.

	Strictly speaking, the total length isn't necessary by your logic,
since appending without also munging the checksum will cause the packet
to fail auth, and the transport has a length field in all cases I know of.

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

	How do you define this "might as well authenticate"? Could you
expand as to how you are making these conclusions? On what basis are
you classifying these fields?

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

	Again, this is a design question. I can predict that if I send a
packet over our routers, it will either get there with its options
the same way I sent them or it will get dropped because our filter got it.
We have Cisco routers. It just happens that we don't have configurations
on our routers that cause them to go munging packets. For that matter,
Bill, I've never seen a site in my entire life that has a router that
messes with IPv4 options on a packet in transit. Maybe they're more
common in your environment.

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

	Again, this is a design decision.

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

	Personally, I could easily live without source routes. I don't like
them -- never have, never will. But there are a number of legitimate cases
in which you might need them. Do we tell people who have systems that might
process source routes that they're SOL if they use them, or do we try to
give them some guarantees through AH? I believe that source routes can be
authenticated, and I explained how I think it can be done. I have code that
has been able to authenticate IPv4 source routes. If you believe that my
method of handling source routes is in error, please elaborate. If you
believe that we shouldn't be authenticating options, as you seem to have
been indicating, then please explain this conclusion.

	We need to talk about this. Simply saying that it's not right, we
shouldn't do it because people could break, or that you don't care doesn't
seem to me to be a good alternative to putting facts on the table that back
up your conclusions.

								-Craig


Follow-Ups: References: