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

["Howard C. Berkowitz" <hcb at clark.net>]

At 21:03 -0500 3/31/98, Stephen Kent wrote:
>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.

It's certainly reasonable, for pure editorial reasons, not to include a
security analysis _in_ the architecture document.  A reference to another
document or even series of documents would serve the same purpose.

As you suggest, it is complex. But look at the responses to this last call
to begin to see how things are muddled without reference to trust
boundaries, etc., in user environments.  Such references don't even
necessarily need to be IETF documents, but expositions that exist elsewhere
yet are acceptable to the IETF security experts.

Otherwise, in commercial environments, we can have situations similar to
one we just saw.  Simply as an example, I raised the issue of NAT
interactions. While I was not explicit about the architectural detail,
simply because I was inquiring about the area, I was thinking of a NAT on
the edge of an enterprise, and within the trust perimeter (other than the
outside interfaces).

I had raised the issue of host-to-host requirements because this has been
suggested by some NAT participants to be an absolute contraindication to
NAT.  Clearly, a host-to-trusted gateway and gateway-to-gateway model can
be constructed.  Yes, there has to be transitive trust.  But this is wildly
different than one comment in this thread that the alternative to
end-to-end is making your keys available to half the routers of the
Internet.


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

Again, it would not need to be in the physical document.  But I do feel at
least reference to trust models is needed to help the less experienced
reader.

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

Editorial tuning to make it clear what this document does NOT cover, a bit
more strongly than "out of scope of this document," would help.  Again,
this is for the benefit of the nonspecialist reader. It might be no more
than a few sentences clarifying that the enterprise architect MUST do
tradeoff analyses among the various trust models.  It's not necessary to
detail _how_ to do this, but it is going to help users, especially those
that need support with upper management to deploy IPsec.  The reality is
that some Dilbert-style top managers will decree "Implement IPsec by
Tuesday," and it would help the beleaguered architect to be able to point
to an IETF guideline "you've got to do the analysis first."
>
>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.

Ah. I think pointers to the trust boundary analysis, even if this is not
inside the architecture, would help a great deal.  And I think it also
needs to be made clear that trust boundaries will vary among
applications/communities.  Many statements are flying about saying One Size
Fits All.

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

What would be the feasibility of spinning off these analyses into a
separate document, along the lines of a standardization report?  I'd prefer
it be considered Standards Track, but Informational would be  better than
nothing.  I have two I-Ds dealing with multihoming and OSPF-specific
deployment issues in the pipeline now; I make no secret I feel that it
would be enormously helpful to the less-than-elite, if you will, if more
informational deployment guidance were available.  Unfortunately, this sort
of thing may be dismissed as "operational."

Thank you and the WG for the immense work in this document and series of
documents.  These comments are meant to help its acceptance and effective
use, not delay things.


Howard