Re: Last Call: Security Architecture for the Internet Protocol to Proposed Standard

[Stephen Kent <kent at bbn.com>]

Howard,

>Let me try to rephrase.  Yes, I have read the spec and understand these
>modes are present.  I am raising concerns about the applicability of these
>modes, since some significant user communities have insisted on
>host-to-host, a technique that can complicate administration and make it
>extremely difficult to use some infrastructure techniques such as NAT.  The
>issue of a trusted NAT has been dismissed by some.  I'd simply like to see
>more security analysis alternatives in the document or referenced by it.
>Otherwise, I have the sense of several working groups each saying "this is
>our protocol/mechanism and it's irrelevant how other mechanisms interact
>with it."

The earlier (RFC) version of the IPsec architecure did try to perform some
of this analysis, and you can see what that looked like in RFC 1825.  The
general view has been that this version of the architecture document is
better, in part because it did not try to incorporate such analyusis.
Unfortunately, there are many factors involved in deciding where and how to
deploy security mechansims such as IPsec.  A superficial analysis might
lead one to make inappropriate choices, but a thorough analysis would be
large and would make the document unwieldly.  I agree that we could reword
part of the document to provide a better picture of the set of issues that
will be addressed by IPsecond.  That's a well-defined sort of edit that
would address part of your concern.  However, I don't think it is
reasonable to include an analysis of the sort you seem to be suggesting.

In particular, when one begins discussing NAT, TCP window spoofing, etc.,
where should we stop?  Any intermediate system processing that involves
examination or modification of any protocol above the IP layer will be
impacted by use if IPsec, if the intermediate system in question is outside
of the trust boundary of the organizations and individuals employing IPsec.
Should TLS provide an analysis of the impact of its use on web page
caching?   Should we do the same?

You cite the BGP security analysis that was recently published as an
example fo what you might like to see.  Since I am involved with an ongoing
BGP security project I can say that the analysis in question was pretty
good, but was not complete.  We performed a somewhat more through analysis
last year, comparing various proposals and analyzing their relative merits,
and the result is a noticeably larger document.  The question is how much
background ought one provide in a document of this sort, which is clearly
not a black or white issue.

Steve