Re: intersec BOF

[Sally Floyd <floyd@icir.org>]

>	summary: classic problem, end-to-end encryption versus intermediate
>	box which would like to tweak/peep traffic.  there's no good solution,
>	but that's life.

I liked this BOF because the feedback from the floor would mostly 
useful and to-the-point, raising and clarifying issues that had to be
addressed.  (Part of the feedback from the mike was about the
relative merits of end-to-end security (IPsec) vs. tranport-level
security (TLS, SRTP).)

The consensus seemed to be that there really is a problem here to be
addressed.  And that a problem statement would be a good next step,
somewhat more separated from a proposed solution.

I was asked last week to give a presentation at the BOF, and gave
a short presentation of related architectural issues.  (E.g., from
RFC 3135: Performance Enhancing Proxies Intended to Mitigate
Link-Related Degradations; RFC 3238: IAB Considerations for OPES;
and RFC 3426: General Architectural and Policy Considerations.)

Notes are below, just FYI.

- Sally

----------------------------------

intersec

Thomas Woo

Motivating the need for intermediary-based transport services.

An intermediary has knowledge of network traffic, routing behavior,
and filtering capacity in the network.

An intermediate node will have to read or process packet headers,
and end-to-end secure tunneling (e.g., IPsec) excludes the
application of these services.
We have to reconcile this conflict, with a protocol that can establish
the consent and provisioning of intermediary-based services.

TCP Enhancements:
They want an ACK regulator to regulate ACKS from mobile user,
to account for downlink delay variance.
This relies on TCP port number, TCP sequence number in TCP header.
This would be prevented by an end-to-end IPsec tunnel.

Header Compression:
An end-to-end IPsec tunnel would prevent header compression at
intermediate notes.
Can we support header compression and have good security at the same time?

Network-based Packet Filtering:
Spoofed (address-spoofed, IPsec encrypted) IPsec packets to VPN client.
How to prevent spoofed clients from going to the mobile?
Client mobility requires dynamic invocation of packet filters.

Issues to explore:
* Trust assumptions?
* Protocol functions?
  How to reliably and securely configure, invoke, and revoke intermediary-based services?

Identify goals and requirements.

* End-points pass service configuration info to intermediaries.
* Dynamic invocatio/revocation.
* Extensible, scalable, efficient, interoperable.
* End-points with limited resources.

Discuss methods and protocols.

----------------

Derek from security:
We should start with the problem, and not force ourselves into a
particular solution.
There really is a problem here.

Reiner: Not convinced that we really have a problem.
The TCP PEP and header compression: use TLS, SRTP (Secure RTP).
  People put the TCP PEP at the end of the IPsec tunnel.

Mic: TLS is subject to the reset attack, because it doesn't protect
   packet headers.
Do we need a general framework?
  Reiner: No.
  T.:  He thinks that we want a general solution.
Mic:  There is no problem.  He thinks there is a need for an
  intermediary.
Hilarie:  What if end-to-end security is not required?
Why is it that the transport header is protected in IPsec?
What is the value?  
You need the intermediary to protect you from upstream attacks.
TLS doesn't protect you from the reset attack.

More about transport-layer security solutions:  They solve some of the
  problems, but not all.  So the problem space needs to be addressed
  with higher security (IPsec).

With IPsec, confidentiality, authentication, 

>From mic:  This framework is very suitable for us.

NSIS?  Doesn't this fit there?

>From OPES: tracing.

Gorry: 

Sally's presentation.

Hilarie: OPES and intersec are quite different, and have different
  protocols.

Next steps: 

Mailing list:
intersec(-request)@psg.com