Brian E Carpenter writes:
 > Indeed, it is clear that users who wish to be protected against
 > anthing beyond source/destination traffic analysis cannot use 
 > the proposed flow-label diffserv mechanism. That's a user trade-off,
 > not a decision for the IETF to make.

   Moving the lose-lose situation to the user does
   not seem like a very useful recommendation. We
   shouldn't be in the business of letting end users
   decide which lossage due to bad architectural 
   assumptions is better. Foisting the NAT
   hackitecture on the world was bad enough and 
   is probably the single largest source of
   entropy we face; we shouldn't take this sort
   of thing lightly.

            Mike

 > 
 >    Brian
 > 
 > Michael Thomas wrote:
 > > 
 > > With Intserv-like networks, you don't ever need to
 > > reveal any L4+ headers. This is also true with
 > > diffserv networks if you don't require
 > > (re)classification, which is a perfectly
 > > reasonable way to design a diffserv network.
 > > 
 > > This entire controversy surrounds whether diffserv
 > > networks which have interior routers do the
 > > classification is legitimate. Considering that it
 > > breaks a perfectly reasonable user desire --
 > > privacy -- I'd say that's a pretty good reason
 > > to question the base premise.
 > > 
 > >             Mike
 > > 
 > > Alex Conta writes:
 > >  >
 > >  >
 > >  > Francis Dupont wrote:
 > >  > >
 > >  > > Alex, perhaps I was unfair about the c) option.
 > >  >
 > >  > You were Francis.
 > >  >
 > >  > > I understood that you'd like to replace the MF classifier on
 > >  > > the 5/6 tuple (adresses, DS field, protocol, ports) which I'll call
 > >  > > the 5F classifier by a simpler MF classifier with the flow label
 > >  > > in place of protocol and ports. This cancels the efficiency issue
 > >  > > of the extension header chain of IPv6.
 > >  > >
 > >  > > My first concern is the 5F reclassification is a bad idea because
 > >  > > an ACL-like classifier will never give what I want as an user.
 > >  > > This is too rigid, not real-time, ...
 > >  > >
 > >  >
 > >  > It may not give you what you want as a user, but it would give me
 > >  > what "I" (read my customers) want as user(s).
 > >  >
 > >  > Remember, having a Intserv, and Diffserv use of the flow label gives
 > >  > the user the option, and that is a good thing.
 > >  >
 > >  > > The second concern is with ESP: the 5F classifier wants to look at
 > >  > > bits I want to hide. No conciliation is possible, IPsec people
 > >  > > (like Michael) will *never* accept to reveal transport layer or
 > >  > > payload details for a 5F classifier. [...]
 > >  > >
 > >  > > Francis
 > >  >
 > >  > Let's put religion aside.
 > >  >
 > >  > Conceptually, with IP QoS, infrastructure devices delivering packets to
 > >  > destination, are processing forwarding and QoS information.
 > >  >
 > >  > As traffic between two end-nodes may have distinct QoS requirements, it
 > >  > is obvious that the information to be given to an infrastructure device
 > >  > must provide the differentiation of the traffic between the two
 > >  > end-nodes.
 > >  > That information, by definition, is in some relationship with the
 > >  > multiplexing
 > >  > of the communication between the two end-nodes, which is being realized
 > >  > through the
 > >  > transport (host-to-host) header information. At an extreme, that
 > >  > information is the
 > >  > transport protocol and source and destination ports, themselves.
 > >  >
 > >  > Since, with IP QoS, the QoS information is in the same class, relative
 > >  > to privacy,
 > >  > with the forwarding information, if one needs to apply full privacy to
 > >  > QoS information,
 > >  > it will apply the same criteria as for forwarding information: use
 > >  > tunnel ESP.
 > >  >
 > >  > Regards,
 > >  > Alex
 > > --------------------------------------------------------------------
 > > IETF IPng Working Group Mailing List
 > > IPng Home Page:                      http://playground.sun.com/ipng
 > > FTP archive:                      ftp://playground.sun.com/pub/ipng
 > > Direct all administrative requests to [EMAIL PROTECTED]
 > > --------------------------------------------------------------------
 > 
 > -- 
 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 > Brian E Carpenter 
 > Distinguished Engineer, Internet Standards & Technology, IBM 
 > On assignment for IBM at http://www.iCAIR.org 
 > Board Chairman, Internet Society http://www.isoc.org
 > 
 > "We shall need a number of efficient librarian types 
 >  to keep us in order." - Alan Turing, 1947.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to