In your previous mail you wrote:
> Alex, perhaps I was unfair about the c) option.
You were Francis.
=> I agree, c) is not a bad idea, the problem is with diffserv itself
(the MF re-classification on the 5/6 tuple or worse which:
- has bad privacy/security implications
- is hard to do at very high speed, even with IPv4
- makes IPv6 slower than IPv4 because of the extension header chain
(problem you try to fix))
> 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).
=> I am not convinced because I have no control on random intermediate ISPs.
Perhaps we are using the term user for different things, my user is
an end-user, your user is a ISP?
Remember, having a Intserv, and Diffserv use of the flow label gives
the user the option, and that is a good thing.
=> because of its scalability problem, Intserv is usable only locally,
for instance on the first or last wireless segment between me and
my correspondent. But diffserv seems to have the same restriction,
ISPs that we are in business are first or last ISPs. Core transit ISPs
are pseudo-randomly (for us) chosen and if they re-classify my packets
I'd like to know what silly rules on the 5/6 tuple they use...
The only reasonable option is to see what are source and destination
ISPs (using BGP table for instance) and to remark packets according
to them.
> 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. [...]
Let's put religion aside.
=> security/privacy is a religion we can't fight (:-). I definitely don't
want to have to choose between QoS and security/privacy.
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.
=> I disagree: your proposal is to drop diffserv QoS if I'd like to get
security/privacy. I can't accept this. As intserv has not this issue,
the problem seems to be in the QoS information, and how it can be used
by ISPs.
I have contracts with my first ISPs (and my correspondent with last ISPs)
so I can mark my packets with the desired QoS, ISPs will apply the QoS
(keep my packets, drop others :-) and send the bill to me.
This model doesn't work for core transit ISPs: in general I can't choose
them, in fact I don't know what they are. I have no trust in them,
I don't pay their bill, etc. And of course they have no trust in me,
nor in the bits I've put in the DS field of my packets. So any QoS
information I have put in my packets has no meaning...
In conclusion I have no relationship with core transit ISPs, they can
re-classify by packets on the 5/6 tuple or worse, this is only a crazy
way to slow down the core routers. I rely on the first/last ISPs to
have business relationships with core transit ISPs in order to get
a reasonable service, and core transit ISPs should use MF re-classifier
only on the 2/3 tuple (addresses/DS field). BTW IPv6 gets an advantage
over IPv4 because of its addressing (better aggregation: simpler prefix
matching on source and destination addresses).
So I propose to refocus the discussion on the real issue: what will be
in practice MF re-classifiers and what constraints will this imply?
Regards
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
