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

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

I may have missed a writeup that already exists, but the two quotes below
add to my feeling there needs to be a clear architectural discussion of:

   -- when is true end-to-end IPsec the only acceptable means of having
      a security association?  Even here, there needs to be a distinction
      between end-host-to-end-host and end-process/port-to end process.
   -- Some of the issues raised recently, such as port identification and
      possibly satellite performance, could be handled with either
      only security-gateway-to-security-gateway associations, or
      End-to-SG, SG-to-SG, SG-to-End associations.  I recognize that
      IPsec is architected to be end-to-end, but there seems to be
      an discussions of tradeoffs for this architecturally recognizable
      set of problems -- where certain infrastructure components cannot
      work in the presence of true end-to-end security.

This reminds me of Bob Moskowitz's comments at the December NAT meeting, in
which he spoke of the incompatibility of end-to-end IPsec with NAT.
Widespread  end-to-end IPsec deployment without the possibilities of NAT
may have a significant demand on the globally routable address space.
There are workarounds here, some of which do involve trusting the NAT, or
possibly a drive toward IPv6 (with strong provider aggregation to protect
the routing system).

Howard,

who may just need a pointer.  The flavor I have is "end-to-end good,
trusted gateway bad," when the truth, as in so many things, lies inbetween
depending on the specific application.  I'd like to see guidance for
application architects.


>Alan Blair wrote,

>My understanding is that the TCP Over Satellite WG is considering the use
>of spoofing (at least as a research topic).  I presume this means that
>IPSec and spoofing to improve performance on a long latency satellite
>network are incompatible.   Is there any way to maintain security and
>still do TCP spoofing for satellites (i.e., could you elaborate on the
>evil)?
>
>                                                            Alan
>
>Bill Sommerfeld wrote:
>
>> Since often things seem to turn on the volume (or mass) of commentary,
>> I think I'll weigh in here..
>>
>> A number of folks have argued for adding various layers of
>> "transparency" to the ipsec, for a variety of reasons:
>>         1) management wiretapping.
>>         2) differential handling based on protocol.
>>         3) protocol spoofing for long-latency networks.
>>
>> None of these seem to justify this, and there are alternate means of