Subject: RE: [Int-area] Architectural reasons why tunnelling is an indicationofa failure

From: "Bound, Jim" <[email-masked]>
Date: Wed, 3 Aug 2005 03:15:03 -0400

In addition we need to think when are tunnels valid if networks and
virtualization are operating end-to-end, and in cases where IPsec has
encrypted the entire payload except the header and any options above the
payload.  Classification and VPN handling may have to be done with only
header information and the software for this will not see transport
payload for discrimination.  That is the objective of an end-to-end
trust model which is also part of this discussion from architecture
perspective.

/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Scott W Brim
> Sent: Wednesday, August 03, 2005 3:09 AM
> To: James Kempf
> Cc: Internet Area; IAB; Joe Touch
> Subject: Re: [Int-area] Architectural reasons why tunnelling 
> is an indicationofa failure
> 
> On 08/02/2005 16:58 PM, James Kempf allegedly wrote:
> > Pekka,
> > 
> > I agree with Joe and Tony. Tunnels are a tool for 
> virtualizing the address
> > space. If you are going to propose that they are a flawed 
> tool, then I think
> > you need to propose an alternative that has "better" (for 
> some sense of the
> > word)  properties. The only alternative I can think of (swapping IP
> > addresses in the header, i.e. NAT) is worse,  but maybe 
> there are other
> > alternatives.
> 
> This is where I come down.  I was revolted when tunnels became
> architecture (I believe I argued with Steve Deering about it in Santa
> Fe), and I used to think of MPLS as a sign of shortcomings in IP
> routing and addressing, but since then requirements have changed.  We
> now have to handle "network of networks" scenarios, where you need
> complete isolation of client and server "networks".  We could invent
> other ways to do this, but in the end they would have the features we
> currently call "tunnels".
> 
> As an exercise it would be good to explore thinking about these
> mechanisms as other than "tunnels".  Perhaps a different conceptual
> view would be a better base for going forward architecturally.
> 
> swb
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/int-area
> 

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area