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

[Peter Ford <peterf at microsoft.com>]

Phil

At least one company is planning on shipping a high volume product that
makes it easy to use IPSEC end to end in transport mode.  I note there are
other end system companies who are already shipping IPSEC in this manner.
Over time I expect that E2E will be the dominant model.  In the mean time I
agree with your observation that Tunnel mode dominates.

Your proposed partitioning does not solve the problem the SNOOP guys have on
the public network where they want a proxy at the base station (public side)
to massage and manipulate packets based on TCP seq #s to better accomodate
losses and handoffs of mobile stations. 

We could probably have an interesting debate as to whether SNOOP is the best
way to go...

cheers, peter



> -----Original Message-----
> From:	Phil Karn [SMTP:karn at qualcomm.com]
> Sent:	Thursday, March 26, 1998 11:11 PM
> To:	jgc at optimal.com
> Cc:	pkoning at xedia.com; iesg at ns.ietf.org; minshall at fiberlane.com;
> ipsec at tis.com; ietf at ns.ietf.org; karn at qualcomm.com
> Subject:	Re: Last Call: Security Architecture for the Internet
> Protocol to Proposed Standard
> 
> >The issue that Greg brings up is very important.  My company relies on
> >port information heavily for analysis of protocols and applications and
> >if this information is obscured it becomes difficult to accurately
> >report on the different applications that are running.
> 
> IPSEC is most often implemented on border routers between private
> subnets and the public Internet to protect inter-subnet traffic
> between hosts that can't protect themselves on an end-to-end
> basis. (It seems less likely that IPSEC will replace existing
> end-to-end encryption mechanisms like PGP, SSH and SSL where they are
> already implemented.)
> 
> In such "tunnel" configurations, the packets are still available in
> plaintext within the private networks, where they can be monitored and
> debugged by the operators of those networks. Similarly, any
> information needed by the subnet's internal and border routers for
> traffic classification is still available.  Only the external, public
> part of the path is encrypted.
> 
> Phil