2.8.22 Access Link Intermediaries Assisting Services (alias) Bof

Current Meeting Report

Access Link Intermediaries Assisting Services BOF (alias)


Tuesday, July 15 at 1545-1645
==============================


CHAIRS: Kevin Fall <kfall@EECS.Berkeley.EDU>
        Hui-Lan Lu <huilanlu@lucent.com> 


Notes taken by Carl Williams with supplements from Igor Faynberg and 
Spencer Dawkins. Many thanks to them!



FINAL AGENDA:


+ A brief history, Area Directors, 5 min.


+ INTERSEC perspective, T. Woo, 15 min.


+ TRIGTRAN perspective, S. Dawkins, 15 min.


+ Tentative charter


+ Wrapping up



MAILING LIST: 
alias@mailman.berkeley.intel-research.net
TO JOIN:  
http://mailman.berkeley.intel-resea
rch.net/mailman/listinfo/alias



DESCRIPTION:


Several types of access links in widespread use for Internet 
connectivity today has characteristics that affect the operation 
Internet protocols and services. Low-bandwidth, high latency links 
patched over telephone lines via modems are one common example. Radio 
links in wireless networks (such as GSM, IS-95, GPRS and 802.11) are 
another example. These links often have undesirable 
characteristics such as high loss, high delay and low reliability.


Transport intermediaries have been used to enhance the performance of 
problematic links in the past (see RFC 3135). This BoF investigates 
further work in support of transport intermediaries that provide 
assistance to access links, including (but not exclusively) wireless 
links, primarily in the areas of security protocol interaction with 
transport intermediaries and response to changing link conditions. In 
particular, existing intermediaries used for these purposes interfere with 
IPSec and may weaken overall end-to-end security - work is therefore 
necessary to determine how to request, authenticate and authorize the 
services of intermediaries, and when possible to mitigate the 
interference of intermediaries in security.


This work focuses on support for TCP initially but does not preclude 
consideration of other transport-layer protocols. The relationship of 
transport intermediaries to devices constrained by OPES and UNSAF is also 
critical to the architectural framework.


Reading:



http://www.ietf.org/internet-drafts/draf
t-blumenthal-intermediary-transport-00.txt

http://www.ietf.org/internet-drafts/draf
t-dawkins-trigtran-framework-00.txt

http://www.ietf.org/internet-drafts/draf
t-dawkins-trigtran-probstmt-01.txt



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


Hui-Lan stated that the goals of the BoF were two-fold: further clarify the 
problems previously discussed at the INTERSEC and TRIGTRAN BoFs and work 
toward a charter.
 
History review from Transport Area Director Jon Peterson


- Regardless of whether we like these intermediaries, they do exist - 
Encourage people to minimize effects at transport level.


If we don't address them, they will pop up without end user 
involvement.  So the argument has to be that given that these things do 
exist and problems are being identified by a number of vendors and 
service providers out there, are we better off to try to find ways to 
minimize the impact of intermediaries or do we let this exist as it is.  We 
need to identify the problem space and see what we can do.


John Loughney:  Similar to issues in MIDCOM and NSIS working groups. How are 
these things different?  


Jon:  Maybe they are similar after we look at all the 
architectures and problems.  Maybe we decide that NSIS is the 
solution.


Comment: Solution in search of a problem.  Reason giving for this is not 
cohesive.


Jon:  Intermediaries are there.  We are trying to learn how to mitigate the 
side effects of these intermediaries.


James Kempf:  NATs aren't good.  Do we need to better engineer them 
because they will be used anyway?


Mike Richardson:  Maybe 5% are legitimate problems.  I have been asking for 
but haven't seen the problems yet.


Jon:  Hoping that the discussion doesn't turn into why 
intermediaries should be there.



Intersec perspective - Thomas Woo


Thomas Woo presented the intersect perspective.


- Thomas Woo presented Classic "motivations" for transport 
intermediaries. These examples were presented at the intersec BoF.  


James Kempf - Work with the 10**-2 loss rate?


Dave Oran - "Access link" is associated with a subscriber - do you mean 
that? A: Not really...


Michael Richards - Same security admin domain? Are tunnels in scope? A: 
Yes.


Glenn Zorn, Cisco - Still confused about what an access link is? Could you 
say what one is NOT? Kevin: No signaling relationship. Thomas: Any link 
that would benefit from an intermediary...


Michael Richardson - Definition of intermediary is pretty invasive, 
including traffic modifications


Thomas Woo presentation comments:


Intermediaries help mitigate problems.  There are two types of 
functions that an intermediary would perform. One function is to signal to 
the endpoints for something.  For example, in TRIGRAN if the net goes up or 
down or changes speed, you may want want to signal to the endpoint of that 
particular event.  The other function is to inspect or even modify the 
traffic sent to the endpoint.  


With these two functions new security threats are opened.  First is an 
attacker can send bogus signals to the endpoints.  Second, if there 
exists end-to-end security between the endpoints, in order for the 
intermediary to inspect selected portion of the header, that 
end-to-end security would need to be relaxed or compromised.  In 
particular, an attacker can potentially gain unauthorized access to 
end-to-end traffic.


Dave Oran - Are "modifications" data preserving or not? A:  Cover both 
cases.


Henry Sennich - Model is not complete - endpoints don't always see each 
other?


Comment - Is the requirement to relax Internet security? A: potential 
problem we need to address.


Michael Richardson - Why do you need to modify the traffic? Is that the 
right thing to do? Go back a step.  Tell us the purpose of these things. 


James Kempf - You're in the exact space of OPES. Thomas: Sally sees no 
overlap, per last BoF.


Melinda Shore - There are a lot of architectures for middle boxes in the 
IETF. What is this most like?  (It is not OPES as the relationship is 
initiated by the device in the network).  Question:  Who initiates the 
relationship?  Doesn't look like OPES to me.


Markus Hofmann (OPES chair) - In OPES we assume end-to-end is not 
secure. As far as I can see, there is no overlap of the problem space 
between ALIAS and OPES.



TRIGTRAN Perspective - Spencer Dawkins and Carl Williams


Spencer Dawkins presented the TRIGRAN perspective.


Spencer stated that keep in mind that this is the ALIAS BoF.  We are not 
repeating TRIGTRAN or intersec BoFs.  Spencer and Carl co-chaired the 
TRIGRAN BoF in Atlanta and SF.  TRIGTRAN work comes out of PILC work. 
Improve TCP performance over links.   BCP on improving TCP.  What do links 
know that transports would like them to know.  Spencer states that he is 
talking about traditional access links.  


Three notifications (link up, link down and packet discard) were 
identified at these BoFs. We had consensus on link up.


Spencer went over traditional TRIGTRAN functionality.  Bad thing happens on 
the left and node on right is notified. Spencer presented slides on the 
functionality and trust relationship. Link down is interesting but is 
vulnerable to DOS attacks.  


Lessons for ALIAS:  We were able to agree on one notification and that was 
link up.  End-to-end notification is required to make this happen.  But 
notification complicates the TCP state machine. If I am sending you link 
down and you are still getting acks, then you should assume that you are 
being lied to and ignore it.  That resulted in more complexities than 
worthwhile.  At the IETF-56 there was no support for that.  Link down was an 
extreme case.  Spencer's conclusion from the BoFs is that there is no 
future for middlebox guidance without authentication.  


James: Very interesting.  There are no mechanisms for securing 
signaling.  What you are facing is a general problem in 
architecture and not a deficiency in what you are proposing.


Comment:  Like TRIGTRAN and think it is a great idea!  Can tell if link is up 
or down independently of looking at the packets.  Don't need to look into my 
packets to do this.  What you are doing is generating new traffic to tell 
the world of what is going on.  I think that is really exciting stuff.   
Trust relationships (delegation of authority on the box to the far left (in 
Spencer's diagram) to the middlebox so that it could authenticate itself to 
the box on the right there in those protocols.  Agree with James, 
middlebox security needs to be addressed.


Spencer:  Why was this NOT source quench?  Please see the TGIGTRAN 
framework draft.



* Discussion of tentative charter


Dave Oran - Links that could do compression technique - need to figure out if 
it needs to compress a stream - in or out of scope? This work comes from a 
narrow perspective - what about links that just want to do better? Tell 
IPsec that traffic has already been encrypted? Kevin: turn down volume on 
IPsec... 


Allison: yes, this would be in scope. Kevin: level of 
authentication matters to endpoints.


Uri: Can intermediaries see traffic? Can intermediaries communicate with 
endpoints? Securely? In a standard way?


Melinda:  we always tend to punt on the discovery problem. We've got to 
stop doing this!


John Loughney:  there are additional classes of solutions, but I'm not a big 
fan of problem statement and requirements documents. In this case, 
however, they are needed to differentiate from other working groups.


Comment:  Endpoints should control what intermediaries see and do on 
behalf of endpoints.


Sally Floyd: The charter isn't clear - there are two issues - need to 
define security of signaling, this is orthogonal to what 
intermediaries actually do, and that's another interesting problem that 
really fell out of the proposed charter. What services do we find 
compelling? Jon seemed to say this was in scope. Jon - 
authentication is more what I was thinking of. 


Allison:  we won't develop a PEP, but we will define what's required to do 
PEPs.


Jonathan Rosenberg: Authorization is for something - how can you 
authorize for a service you didn't define?


Michael Richardson:  TRIGTRAN said we needed to identify what 
intermediaries provide as services. There are service providers in the 
world who want to impose a service model that I don't want to assist 
(filtering port 80, etc.) Do we need the consent of both parties? 


Comment:  Notion of intermediary isn't clear to me. What does the 
intermediary actually do? Is an intermediary addressable or 
transparent?
Kevin: transport or below, addressable.


Jon:  Moving forward - there is a need for a common framework.  All in 
favor going forward on a common framework.  Jon took a humm poll.  The 
result was in favor...  We will move forward on requirements and the 
framework. 

Slides

Access Link Intermediaries Assisting Services (alias) BOF
Securely Enabling Intermediary-based Transport Services
Triggers for Transport (TRIGTRAN) Perspective