2.6.9 Secure Transport Proxy (stp) bof

Current Meeting Report

Minutes of STP BOF at 42nd IETF-Chicago meeting

Secure Transport Proxy BOF August 24, 1998

Chairs: Wei Lu <wlu@syl.dl.nec.com>

Report by Wei Lu
--------------------------------------------------
AGENDA
--------------------------------------------------
- Review BOF agenda 5 minutes
- Overview of SOCKS 5 minutes
- Overview of STP requirements 10 minutes
- Multicast proxy 15 minutes
- TCP/UDP proxy 10 minutes
- IPSec/IPv6 integration 10 minutes
- Security/performance consideration 15 minutes
- Charter discussion 20 minutes
- General discussion 20 minutes
--------------------------------------------------
Review of BOF agenda
--------------------------------------------------
The BOF's primary goal is to discuss and define requirements for the next version of
SOCKS protocol.

The web site and the mailing list were provided: http://www.socks.nec.com

--------------------------------------------------
SOCKS Overview
--------------------------------------------------
Wei Lu did shared an overview of SOCKS:

- SOCKS is not a firewall, VPN, or NAT technology.
It is a transport proxy technology.
- SOCKS provides the framework to integrate existing security technologies.
- TCP, UDP, and Multicast are part of transports for IP networks.
- SOCKS is simple, powerful, and useful.
--------------------------------------------------
Overview of STP requirements
--------------------------------------------------
Josh Cohen outlined a list of requirements for the next version of SOCKS protocol:

- SOCKS Client transparency. Currently, SOCKS is client-aware. Protocol
enhancements can ensure transparent client operation.
- Automate client configuration. In a complex network environment, SOCKS client
configuration can be burdensome. Server-based remote client configuration can
significantly reduce the burden.
- Complete DNS proxy support. Currently, SOCKS supports proxy for domain name
resolution only and it is on a per-proxy basis. Full support of DNS proxy will
facilitate application proxy operations.
- Multicast proxy support. Multicast proxy support is indispensable for multimedia
Internet applications.
- Provision for an application server behind SOCKS. SOCKS is designed primarily
for application clients. Basic support to application servers is needed.
- Take full advantage of IPSec for SOCKS security. Since SOCKS operates on top
of the transport, it should take full advantage of lower layer security services such
as IPSec.
- Non-IP network support. There are still many non-IP networks, such as IPX.
SOCKS can be used to proxy applications on those non-IP networks to
applications on IP networks.

Comments on Josh's presentation included:

- Some requirements, such as automated client configuration, are
implementation-specific.
- Some requirements, such as DNS support, can be met without SOCKS.
- Some requirements, non-IP support, are not appropriate for the IETF.
--------------------------------------------------
Multicast proxy
--------------------------------------------------
Jamie Jason presented Intel's proposal to extend SOCKS protocol to support multicast
proxy. Intel has developed a prototype and tested it with a number of multicast
applications. The proposal's motivations include providing:

- Finer control over multicast application. IGMP only provides group information
(group address), not application information (port number).
- Some controls over who can bring in and/or bring out multicast data. SOCKS
provides a framework to convey user information. IGMP does not include user
information.
- Proxy mechanisms to securely bridge/tunnel multicast applications. Multicast
infrastructure is not yet pervasive. Proxy is a good approach to deploy multicast
applications in a mixed multicast/unicast network environment. SOCKS does
proxy with security.

Comments on Jamie's presentation include:

- SOCKS with IGMP can meet some requirements, including user authentication.

Ross Finlayson presented his thoughts and comments on when to use SOCKS proxy
for multicast applications, and when not to use it, including:

- Unicast control on multicast data is not efficient. Lower-layer approaches serve
better.
- SOCKS user authentication does not fit well with multicast applications. Data
authentication is more suitable to multicast applications.
- Unicast proxy of multicast application is useful in a limited scope.

Comments on Ross's presentation included:

- Lower-layer approaches can not meet Jamie's requirements.
- SOCKS relies on lower-layer technologies. SOCKS proxy of multicast
applications is complementary to lower-layer approaches.
- Non-multicast-routable networks, mobile users, and multi-party multicast
applications require unicast control and/or multicast application proxy.
--------------------------------------------------
TCP/UDP proxy
--------------------------------------------------
Wei Lu pointed out two deficiencies in the current version of SOCKS (RFC 1928):

- TCP BIND command only accepts one incoming connection. It is not general
enough for some applications.
- There is no UDP BIND command, complicating streaming application support.
--------------------------------------------------
IPSec/IPv6 integration
--------------------------------------------------
General comments are:
- Since SOCKS relies on the lower-layers, it is ready to use IPSec to enhance security.
- SOCKS already provides a basic framework to support IPv6.

Gabriel Montenegro presented his work on how SOCKS is being used for negotiated
address reuse (NAR). Highlights include:

- Complementary to NAT.
- Designed to reuse IPSec.
- Useful for mobile IP and IP tunneling.

Comments on Gabriel's presentation are:

- Although it is an interesting use of SOCKS, it is beyond SOCKS' scope of secure
transport proxy.

Hiroshi Kitamura presented his work on how to improve SOCKS proxy in a mixed
IPv4 and IPv6 network environment. The proposal is to add a new SOCKS command
to do the IPv4/IPv6 address association.
--------------------------------------------------
Security/performance consideration
--------------------------------------------------
Pat Calhoun presented his thoughts on the integration of a backend authentication
server with SOCKS authentication framework, including:

- Need to support generic authentication devices.
- SOCKS support of a backend authentication server facilitates integrating with
existing security service infrastructure.

Comments on Pat's presentation included:

- SOCKS already provides a framework to support generic authentication schemes.
- In terms of underlying protocol, which mechanism is generic enough to implement
the framework? GSS-API with SNEGO is a good candidate.

Marc VanHeyningen presented his thoughts on improving SOCKS performance by
multiplexing application data and SOCKS messages over proxy channels, providing
these two performance improvements:

- Reducing connection establishment overhead
- Reducing SOCKS authentication overhead
--------------------------------------------------
Charter discussion
--------------------------------------------------
The charter discussion focused on the list of requirements for the next version of
SOCKS. The BOF chair, Wei Lu, emphasized that:

- STP must focus on transport layer only
- STP will follow AFT's approach to deal with authentication and encryption related
issues, implying that:

1. STP will not develop specific authentication protocols. Instead, it will use
existing work of other working groups and the industry.
2. STP will not develop specific cryptographic, or related key management techniques.
It will use existing techniques.

The proposed requirements are:

- Generic TCP BIND support
- UDP BIND support
- Multicast support
- Defined a basic authentication mechanism
- Improve address mapping
- IPSec integration
- Separate the data channel from SOCKS control channel
- SOCKS feature discovery support
--------------------------------------------------
General Discussion
--------------------------------------------------
Area director Marcus Leech did straw polls on two questions:

- How many participants are interested in implementing the new version of SOCKS
protocol?

Response: 5 participants

- How many participants would use the new version of SOCKS if it is available?

Response: about 25 particpants

Slides

None received.

Attendees List

go to list