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 PROTECTED] > [mailto:[EMAIL PROTECTED] 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 protected] > https://www1.ietf.org/mailman/listinfo/int-area > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
