[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last Call: Security Architecture for the Internet Protocol to
Steve,
>All that notwithstanding, this is not a new issue. We've been over
> this ground before in the working group. Several of us, myself
> included, suggested deleting AH. We lost. Fine; so be it. Let's ship
> the documents and be done with it.
No, saying that it is fine is not okay given that there is now an order more
experience in building these implementations and from my own personal
polling the utility of some of this stuff is questionable (I am picking on
AH as a tanglible large item to jettison from this ark). No one is stopped
from building and shipping product; the documents should be right, not
expedient.
IPSEC as currently spec'd is HUUUUUUGGGGGGGEEEEEEEEEEEEEEEEE.
The amount of MUSTs in the current IPSEC Architecture document is
unnecessary (and I paraphrase here): host implementations MUST have certain
mgmt interfaces, manual keying is a MUST, etc., etc.
The minimal IPSEC implementation that complies to all of the gorp in these
documents is unnecessary for many interesting generally consumer based
applications.
The specs can be pared down so that smaller, cheaper, better implementations
are possible and they meet all of the MUSTs in the specifications. AH is a
RIPE target for such pruning.
As Steve notes (and as I noted in my original posting) this is an old issue.
When reading the spec from the perspective of a really cheap IP based device
the specs are outdated with a focus on Router and "Host" implementations.
What is galling is that there is functionality mandated that will probably
not prove useful.
Of course, if the bulk of the people who are building this stuff remain
silent and on the sidelines the powerful process of inertia will take over
and yet another ITU^H^HETF standard will be on its way out the chute. Folks
will elect to build the subset they need and deprecate the meaning of "IPSEC
standards based". This is particular disconcerting given the coupling of
IPSEC to IPv6.
This is not to say that AH should disappear completely. A few MAYs would
give it comfortable quarters in the specs.
rant, rant, rant,
peter
> -----Original Message-----
> From: Steve Bellovin [SMTP:smb@research.att.com]
> Sent: Friday, March 27, 1998 10:36 AM
> To: Dan McDonald
> Cc: baiju.v.patel@intel.com; Peter Ford; iesg@ns.ietf.org; ipsec@tis.com
> Subject: Re: Last Call: Security Architecture for the Internet
> Protocol to
>
> One of the biggest reasons we have AH is because there _are_
> some things in the middle of the "IP header" that need to be
> authenticated for them to be simultaneously safe and useful.
> The biggest example of this is source routing.
>
> In my opinion -- and I've posted this before -- there's nothing in the
> IP header that's both interesting and protected. You can't protect the
> source routing option, since the next-hop pointer changes en route.
> Appendix A of the AH draft recognizes that, and lists it as 'mutable --
> zeroed'.
>
> When you look over the list of IP header fields and options that are
> either immutable or predictable, you find that the only things that are
> really of interest are the source and destination addresses and the
> security label. To the extent that we want to protect the addresses --
> a point that's very unclear to me -- they're bound to the security
> association. The security label certainly should be. If you're using
> security labels (almost no one does) and you don't have the facilities
> to bind it at key management time, use tunnel mode and be done with it.
>
> I'll admit that I've never been in the operations business, but
> I've been told that source routing is a very useful tool for
> diagnosing some classes of problems. AH allows source routing
> to be useful again w/o opening the holes it opens.
>
> Well, yes, but not for the reason you specify. The problem with source
> routing is that it makes address-spoofing trivial. With AH, people
> will either verify certificate names -- the right way to do things --
> or they'll bind a certificate to the source address, and use AH to
> verify the legitimacy of it. The route specified has nothing to do
> with it, and ESP with null encryption does the same thing.
>
> I don't like AH, either in concept or design (and in particular I don't
> like the way it commits layer violations). Its only real use, as I see
> it, is to answer Greg Minshall's objections -- it leaves the port
> numbers in the clear, and visible in a context-independent fashion.
> With null encryption, the monitoring station has to know that that was
> selected. But I'm very far from convinced that these issues are
> important enough to justify AH.
>
> All that notwithstanding, this is not a new issue. We've been over
> this ground before in the working group. Several of us, myself
> included, suggested deleting AH. We lost. Fine; so be it. Let's ship
> the documents and be done with it.
Follow-Ups: