Thanks to Carl Williams for the fine minutes-taking.


Transport Service at the Intermediary BOF (intersec)

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

Minutes taken by Carl Williams

Chair:  Allison Mankin, mankin@psg.com

Scheduled date/time:  Friday, March 21 at 0900-1130.



Allison Mankin started the meeting by making some statements to give some 
context to the meeting.

Allison stated that this is really a joint concern of both the 
transport area and the security area.  Allison stated that she is the area 
director for the Transport Area and that Jon Peterson is thus acting as the 
area director for this BOF.  If we were to go forward with this work, we 
would have a chair who was not an area director.    Allison is chairing to 
provide a structure today.  It is important to have a very strong 
security component and we are looking today to understand what the 
problem and the problem statement are.  Also, what are some of the 
requirements when we understand this problem?  We also are trying to have a 
strong focus where we understand the transport service and where we 
understand the security concern to be.  Please keep that in mind as we move 
forward in our BOF discussion.  

Some discussion on the agenda:

Thomas Woo will have some discussion on the problem statement and 
requirements, and will also ask about differences from OPES, MIDCOM and 
others like it.  Hilarie Orman will also discuss the OPES question.   We can 
also have discussion on how this problem is different the midcom 
problem.  Also Sally Floyd will discuss some related architectural work, 
from an IAB perspective.

Thomas Woo presentation is looking to open the discussion.  Allison 
stated that if Thomas can clarify the questions in his presentation that 
would be good.

Presentation based on internet draft:  

Intermediary-Based Transport Services, Performance Optimization 
Mechanisms, and Relevant Requirements


draft-faynberg-intermediary-transport-00.txt  

Presentation made by Thomas Woo of Lucent 
(thomas.woo@lucent.com).  Need for intermediary based services and 
performance optimization mechanisms.  Go through series of examples -  
these examples are not new as they have been communicated in previous 
literature.  These examples are intended to serve two purposes:

1)	provide concrete examples of type of services and mechanisms that we are 
talking about here.
2)	Examples are to illustrate a different aspect of performance that we are 
trying to solve here.

Hopefully based on these examples we can understand the problem and if we 
can solve the architecture approach to this problem.  Second part will be to 
identify and go through a list of goals and requirements for possible 
architectural approach to this problem.  At the end will invite 
discussion on possible solutions and protocols for addressing these 
requirements. 

Thomas states that the case for intermediary based services and 
performance optimization mechanisms have been well-presented.  Last few 
years there have been many examples of such services and mechanisms.  
Thomas presented information that presents some of these mechanisms or 
argues that these mechanisms are useful for enhancing end-to-end 
communications.  We believe that there are situations where 
intermediary based services and performance optimization mechanisms are 
useful.  As such if you believe they are useful then we need to address the 
problem raised in the application of using intermediary services and 
mechanisms and the need for end-to-end security.  Reason it is 
interesting for an intermediary to providethese services is due to the 
location advantages of the intermediary node.  For example, such nodes have 
potentially more knowledge of network traffic, routing in network, and have 
filtering capability within the network.  Typically in providing these 
intermediary services and mechanisms, the key issue is that the 
intermediary node will need to analyze, manipulate, or somehow process the 
packet header or in some cases the packet itself.  When you have 
end-to-end security such as IPsec, because it will encrypt things that are 
transport level and above - such mechanisms will exclude the 
application of these services. 
 
We need to reconcile this conflict: the need for end-to-end security and the 
desire to have an intermediary node provide some performance 
enhancement services.  The compromise that we are proposing is maybe that we 
can systematically bring in these intermediaries so that the inclusion of 
the intermediaries providing the services is actually controlled  by the end 
points.  What this means is the need for a protocol that 
systematically and securely establish the consent and provisioning of 
these intermediary based services. 

Series of examples are presented to illustrate these services each 
bringing out a different aspect of the problem.

Example 1: TCP enhancement
Problem is that for wireless links we observe is a significant delay 
variance.  The delay is not large but the variance of the delay is large.  
The variance in delay is found to be an important factor influencing TCP 
performance.   TCP throughput performance suffers as a result.  
Solution to this problem is well-known.  RFC3135 presents same problem and a 
number of mechanisms.  Thomas noted to see TCP/IP performance over 3G 
wireless links with rate and delay variations.  In Proc. of ACM 
Mobicom, September 2002.  Here we have as an example a TCP-ack 
regulator implemented at the intermediary node.  
 
Relies on information from TCP header - for example, need port number for 
flow identification.  Pacing of ACK is done on per-flow basis.  Also, in 
order to know how to calculate the pacing schedule it needs to access the 
TCP sequencing numbers.  

If you have end-to-end IPsec tunnel between the mobile and end server then 
you would prevent the use of this TCP-ack regulator at the PEP.  

What this example brings out:  intermediary node needs to access TCP 
header.  It only needs read access in the example that Thomas 
presented.

Example 2:  Header Compression

Problem here is that access link bandwidth tends to be limited.  In 
wireless case and and some wirelined cases this problem is seen.  Thomas 
states the solution is well known.  Can perform some sort of header 
compression between the end system and intermediate access router.  
Again, these methods are well documented and presented in various RFCs 
(1145, 2507, 3095).  What is the requirements for the intermediate access 
router: in this case you are compressing the header - so you will need to 
have access to the header and you may need to modify the header.  In this 
case you need read access as well as write access to the packet header.  

If you have an end-to-end IPsec tunnel between the two end points then this 
would prevent header compression at an intermediate node.  The question 
here is can we support header compression and have good security at the 
same time.

Example 3 (Final example):  Network-based packet filtering

Thomas presented an example of a VPN client going over wireless network and 
go back to enterprise.  We assume that there is an enterprise VPN 
application between mobile user and the enterprise IPsec gateway.  
Problem is similar to a Denial of Service attack but instead of 
attacking the server the client is attacked.  Here spoofed IPsec packets to 
VPN client can consumed value transport resources, especially in 
bandwidth-limited wireless links.  We need to prevent spoofed IPsec 
packets from going to the mobile as we don't want the mobile receiving all 
these packets and throwing them away.

Bigger problem:  This is a DOS that is not on a single endpoint - 
because the wireless access network is a shared network - so the DOS 
attack on one of the clients can effect the entire network.  Others also 
won't get service. 

Solution: some network-based packet filtering method.  This should on the 
interface between the wirelined network and the wireless access 
network. Again, if you have IPsec packets there is a problem, you can't 
tell what is in an attack packet and what is not in an attack packet.  
IPsec would have provided privacy of the packet. So normal firewall would 
not be able to work here.

This case illustrates mobility of the client so VPN client can move from one 
access network to another access network.  As client moves the 
provisioning data that existed prior to move needs to be transferred to a 
different packet filter.  Because of client mobility, these filters need to 
be dynamically configured and invoke/revoked as client moves.    

Summary: At this point Thomas hopes he has convinced us that there are 
benefits to these mechanisms.  We have also identified problems with each of 
these mechanisms where end-to-end security methods are used such as 
IPsec.  We need some architecture approach in solving these problems.

Issues to Explore in Architecture:

  - Define and be specific about what type of trust relationship exists 
between end systems and intermediary node.

    Two aspects of this trust: once you have included this 
intermediary to provide a service it should do so as specified.  
Secondly, some access (read, write, or both) is in hands of 
intermediary - end points must have trust so that intermediary node can 
perform its function.

  - Protocol functions : one way to reconcile is to have some protocol that 
can securely establish the consent and provisioning of these 
intermediaries.  

    So what does the protocol look like?  Thomas proposes two 
questions - (1) How to reliably and securely configure, invoke and revoke 
intermediary-based transport services.  THis needs to be done with 
consent of the end point. (2) How do the intermediate nodes obtain that 
information.  Some sort of protocol agreement between the end point and 
intermediary as what part of packet needs to be open and what is the 
intermediary allowed (i.e., access) on the packet.

Thomas went into a preliminary set of requirements (not exhaustive list) for a 
possible solution.  They are presented to stimulate discussion.  End point is 
in charge and should pass configuration info to the intermediate nodes 
(simple, reliable, secure).  It is the end-points that control the 
dynamic invocation/revocation of services during session.  The 
solutions should be extensible, scalable, efficient and 
interoperable with existing network nodes.  End point could be mobile - so we 
would like that what is proposed that it handles limited resources (i.e., 
bandwidth and battery power).  

On policy side here is what we see as the goal of the solution: (1) 
end-points should decide what services are enabled and what 
information should be exposed to intermediate node(s).  (2) 
End-points may allow manipulation of accessible info by 
intermediate nodes in a controlled manner.  (3) End-points should be 
addressable at the network layer. 

For security goals:  Still want end-to-end security for all the stuff that is 
not needed by intermediary node(s).  We expect some security 
relationship between end-points and intermediate nodes will be 
establish when services gets invoked. The security relationship will be 
torn down when service is revoked.  If ther is a change in the 
intermediary node (case of mobility) a new security relationship will be 
established with new intermediary node(s).  If state data is 
transferred between one intermediary node to another, it should be done in a 
secure fashion.  Finally, there should be mechanisms in the protocol to 
detect that the intermediary node is behaving inappropriately and take 
corrective action.


Final comments of presentation:  Highlight the tension between 
end-to-end security and desire to have services provided by 
intermediary nodes.  Thomas hopes to have provided examples of why these 
services are interesting.  In addition, Thomas refers us to the 
internet-draft that identifies requirements and goals for a solution:  
draft
-faynberg-intermediary-transport-00.txt

Open Issues:  There are other working groups on intermediary nodes - 
example, midcom and OPES.   Interest with this work is primary on 
transport level services.  How do we define boundary requirements from 
midcom and OPES work.

Thomas proposed the following Work item for IETF: study protocol for 
secure end-system-intermediary interchanges on transport services, 
starting from the requirements stated in the talk.


OPEN MIC DISCUSSION
===================

Derek Atkins:  I agree that there is a problem here.  Trying to piece out 
the differences between what the actual problem is and separate that out 
from the proposed solutions - the way you want things to work.  Have a 
problem here but not convinced that we have a clear understanding of what 
that problem is and what the requirements are  for a proposed 
solution.  Going forward we should define problem and ignore any 
potential solutions.  Don't force ourselves into a particular way of doing 
things because we have some notions on how it should work.  Clear 
understanding of what requirements are first.  

Bernard Aboba:  Not convinced that we have a problem that we need to 
solve.  For example, looking at your 3 examples (not sure about 3rd case) 
TCP enhancement and header compression case are well known and we have 
solutions.  Do the security above transport layer and stuff that was 
presented on header compression has been exactly the motivation for 
standardization secure rtp.   

Thomas: Some sort of solution already with each of these examples.  
Hoping that there structure for these types of problems. Need unifying 
solutions for all types problem.  Don't work on individual solution for 
each - in arena there are more problems than what has been 
illustrated.  Hopefully, we can work out a general solution - for 
problem A we have solution A - for problem B we have solution B.  

Henry Sinnreich:  Should not be a working group.  If you look around here in 
the room we have all these laptops using wireless lan and we can ping all 
the way to australia or any other destination.  Ping succeeds and 
telephone video calls succeed - with or without VPN. Your problem is that 
there is no problem.  Now the solution:  you may have encountered a 
problem for a particular implementation - we have solved this dilemma with 
3gpp with SIP with a "pheader"  - that is publish something with 
something proprietary  - don't need to spoil the Internet with more 
intermediaries.  Internet is good because it is good for all the 
applications and services. Value of Internet is that there is no 
intermediaries.  Vote that this is bad proposal and not IETF item.  But if 
you have field experience and want to make a BCP - solution  for 
particular problem - than that is a different story.  I may support that. 

Comment: puzzle at requirement that everything that wasn't necessary for the 
intermediary has to be transferred securely (end-to-end).

Thomas: If you want to preserve the original end-to-end security.

Allison:  One reason this came into transport is that we would like for 
this to be (if we were working on this) that there would be a 
relationship to intermediary services where there was no IPsec.  We have 
header compression boxes - something heavy duty happens and there is no 
protocol in that it is all proprietary in how it is agreed upon with the 
endpoints.  There is often no IPsec there.  We would like to have 
solution that doesn't assume if IPsec is there or not - IPsec 
independent.  This security association is not necessarily tied to an 
IPsec story.

Comment:  But is tied to some cryptographic protection story.

Allison:  For the relationship between the endpoint and the 
intermediary and should there be an end-to-end security then there should be a 
relationship to that.  We are into solutions but your question is a very 
reasonable question.  

Comment: You are trying to establish a general framework that had some 
consistency for intermediary services.  Presentation is heavy on 
solution and light on problem. It causes some confusion to try to apply it.  
What you are missing: Why is it that the transport header is 
protected?  You might just say that IPsec got it wrong you shouldn't 
protect the transport header - put that out in clear like tls does.  But you 
say that there is some value in protecting it, then you have to talk about 
those security invariances when you talk about weather or not the 
intermediary is trust worthy and when you talk about weather or not you 
protected the information appropriately.  And you even have to talk about it 
with respect to the solution - because if you say for example, that you 
will take the transport header and move it out of the protected area - I am 
going to copy it in front of the protected area - I am going to 
compress it - I am going to re-protect it for the intermediary - then your 
overhead will crush whatever service you tried to provide.  I 
recommend you to look at this top-down and look at the security 
invariance - ask why they are there and do you want to give them up - and 
what your overhead is.

Thomas: Not talk about solutions.

Allison: We are talking about the whole framework here. Not the 
solution.

Derek:  If you don't have intermediary, you can't protect yourself 
against DOS attacks. You need an upstream provider - you have a thin pipe 
and your upstream provides much more bandwidth than you do.  There is a 
problem where you need intermediary - short of back tracing all your users 
who are doing to you and shutting them down.

Derek:  Want to comment also to those who stated that we have 
solutions to all these problems already.  That depends very much on the 
threat model.  Looking at this one here - well you have tls - well, 
maybe... tls is still subject to the reset attack.  I think saying that we 
have solutions to these particular problems is a little shaky.  
Security is all about threat models.  Also, you will need to maybe look at 
each of these problems separately - as they each may have there own sets of 
requirements.  Going to look at TCP ACK window size versus header 
compression versus DOS attacks differently.  They are different problem 
spaces...

Thomas:  Not suggesting there is a general solution - but there may be a 
general framework.  

Basavaraj Patil (Raj): There does exist a problem. Some networks will 
benefit from these intermediary nodes.  But one thing concern about is that 
we are looking at privacy in the Internet and this tends to violate 
privacy concerns that endpoints may have.  THis gives service 
providers a significant amount of control to them - to prevent certain 
kinds of traffic.  Service providers are gaining more control here - this is 
negative side of things.  If protocol itself enables what endpoints can and 
can't do, then this may be ok.

Allison:  What we are doing is saying that instead of that person doing 
that without you not knowing that you are going to have a secure 
association where you signed up for them to do that.  At least a goal to 
consider having this BOF was to authorize there role in this rather than it 
take place without them knowing. There is still some more explicit role for 
these intermediaries rather them doing it without you knowing about it.

Raj:  You mention the moving of the cache data when a client is mobile.  The 
context transfer work being done in seamoby can be used here... Have a 
general framework would be a good idea.

Pete McCann:  This discussion needs to take place.  The transport layer 
security solutions  -  do not solve all problems.  Some of the 
solutions mentioned don't always work.  There is some good work that needs to 
be done here.

Comment:  The solutions presented here are application dependent.  IPsec 
only protects it - doesn't carry what is being transported.  Some data is 
more sensitive than the other. Then it is up to the endpoint to decide what 
data can revealed and what can't be revealed to the trusted 
intermediary for providing conditional services.  Would be good for 
industry as a whole.
 
Comment: Using PEP and more and more customers using VPN from all around 
world.  Almost 100% we rely on satellite so this is very good for us.

Marcus Brunner:  Looks like nsis working group has a new customer here. 
Define generic signaling protocol where you can put on top different 
services - brings easier to find your intermediary - don't know if it is 
suitable here - but you may want to look at it.

Hilarie Orman: If one end point thinks that things are getting really 
screwed up and it wants to know if there is a PEP in there that are 
screwing things up then you may have to trace that to in order to debug any 
problems you may have. 

Comment:  Solutions that work above the headers don't always work 
because they don't protect the headers.  On other hand, how much do you 
trust something else.  For example, you have to trust your router to 
deliver your packet.  The router must access some headers.  So perhaps 
something can be done to arrange secure relationship between the 
endpoint and intermediary so that the headers are also protected. On the 
other hand, end-to-end protection for user data MUST be done and a 
unified solution is preferred.  That means again application layer and 
above transport layer is not always acceptable.  Solutions on 
per-application basis often are too expensive.

Allison: I wouldn't endorse that as a blanket statement.  Don't know how you 
were applying it - but will take it as a suggestion for a top-down 
framework here.  

Allison:  Write down mailing list - we should have another try at 
expressing the problem and the mailing list is another place we can do 
that.  Mailing list is intersec-(request)@psg.com


Will have two more talks and then look at where we are.

Sally Floyd presentation

Don't have particular architectural insight on this yet.  Will go 
through previous architectural framework and see how they relate.

RFC 3135 PEP

Talks alot about state sharing problems, mobility problems, problems with 
diagnostics.  

The end-to-end principle in designing Internet protocols should be 
retained as the prevailing approach and PEPs should be used only in 
specific environments and circumstances where end-to-end mechanisms 
providing similar performance enhancements are not available.  

In any environment where one might consider employing a PEP for 
improved performance, an end user should be aware of the PEP and the 
choice of employing PEP functionality should be under the control of the end 
user, especially if employing the PEP would interfere with end-to-end 
usage of IP layer security mechanisms or otherwise have undesirable 
implications in some circumstances.

A very nice document for evaluating costs/benefits of PEP.

3238 OPES

Application level services versus transport level services.  So the 
considerations don't map one-to-one.  

Question of trace : Even though you are trusting the intermediary what are 
all the things that it can do wrong. Are the ways that end nodes can deal 
with this.  Not that you won't design so that the intermediary can't do 
anything wrong.


3426 General architectural considerations


how do weigh benefits versus costs.  Cost such as security.

Why do you do it at one layer versus another and what are the 
interactions between the layers. 

See these RFCs for more details...



Allison: We do have a Security AD in audience.  Jon, Allison, and Russ will 
get together.

Last presentation on OPES by Hilarie Orman.

One reason for inviting people from OPES group here - the framework may 
find itself giving us application which will send us to the OPES 
document quickly. Are they OPES or intersec?

Hilarie states that she believes that OPES and intersec are far enough away 
from each despite similar considerations and framework.  It is quite 
different. In short, these are proxy based application extensions.  
Protocol we are developing is for proxy to communicate with servers that 
stand applications.  That protocol is different than anything you are 
talking about - not a transport related.

All kinds of things you may want from an application protocol.  
Endpoints can ask for services and have privacy considerations in the 
Internet.  Rule vectoring might be something architecturally to adopt so 
this is worth looking at.

Hilarie says lots of IAB folks don't like the architectural diagram on 
OPES.   Hilarie discusses OPES details in terms of rich sets of aspects of 
the architecture which you can view from her slides.

Endpoints are fairly active party in OPES.  Allows the application to 
separate into two parties - one is remote.  Need to see all of the data not 
parts of it.

OPES has a rule dispatcher.  Complex to look at all attributes in a 
header.  These rules - sort of like policy - is a nice way of having 
control.


WRAP UP
=======

Allison:   Impression is that one of next steps is that we should 
formulate the problem in a more framework like way than we have already 
have.  Get a feeling from more people working and have another BOF.

Want to get some impressions from people:

Real interesting problem worth working on - Hum....
Not a problem that should be worked on  - Hum....

Consensus exists that there is a real interesting problem worth working on.


THose who would support taking step of working on mailing list towards 
formulating a problem and developing a framework that we can work on in 
another BOF. Hum if this "yes".

Ok. Not a good procedure now Hum....
 
Clear consensus that we should take this up on the mailing list to 
continue the work.

Raise your hand if you still need mailing list address and need it.  Go see 
Allison for mailing list and let's get to work on the mailing list.

There is some interesting real work to do.  Will break now so can get to 
airport given the protesters.  Will see you at the next IETF.  Until 
further notice it will be BOF but if marvelous things happen - who 
knows....  Right now not in position to know all the edges of the 
problems as we