intersec BOF minutes - IETF 56

[Allison Mankin <mankin@psg.com>]

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 provide
these 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
should.