I gave myself 24 hours off from this thread to draw breath. Here are
comments on a bunch of points from various people.
Tony Hain wrote:
...
> But that is the point. If IPsec had been widely deployed in the
> IPv4 Internet, diffserv would have been forced to fix the DSCP
> end-to-end, because that would be the only alternative.
I can only repeat that diffserv did fix the the DSCP values
but only with a SHOULD. My private opinion is that in the end the
ISPs will need to settle down to using the recommended values across
domain boundaries, but what they do in their bilats or within their
domains is not something the IETF can dictate.
...
> >(But anyway, why
> > would it matter if they are mutable, since they aren't covered
> > by checksum? I'm not aware of a law of nature against mutable bits.)
>
> Speak to your co-author who keeps insisting that they are
> mutable.
Yes, and I think I disagree with him :-)
> In any case, the point is that for diffserv to work there
> has to be a visible set of bits that are immutable end-to-end
> with well-known semantics. Currently that is the protocol/port,
> simply because ESP wasn't in widespread use. In IPv6 we assume
> it will be, so diffserv needs another set of bits that have an
> immutable well-known end-to-end semantic.
Well, Alex is correct to the extent that "immutable" is not an
absolute requirement; "globally defined" is necessary and sufficient.
But as just stated, I prefer immutable.
>
> > No, that is in fact what we did, but at the specific insistence
> > of the ISPs active in the design of diffserv, we made all of
> > the mappings SHOULD instead of MUST. You want to ding the WG
> > for meeting a clearly stated key requirement of the principal
> > customer set?
>
> In this case yes, because that requirement results in an
> inoperable state when security is applied.
Not really. It is quite operable if the SLA in place at each
domain boundary recognises the upstream DSCP value (see my
first comment in this message). The case that isn't covered
is ESP packets with no such SLA, and the result will be
that those packets get default QOS. If we don't find a solution
for that case, it doesn't break diffserv.
...
> > Immutablity isn't the problem. Encryption of the port and protocol
> > numbers is the problem. I could equally well say that IPSEC should
> > go back and fix the invisibility problem they created.
>
> That is a specific feature. There are many times when you don't
> want traffic analysis done on the ports in use and number or sequence
> of packets between them.
I agree. Traffic analysis concerns could be a show stopper for paranoid
users.
Alex Conta wrote:
>
...
> Let's say flow label value 50, is RT traffic between A and B.
>
> C, D, and E are routers between A, and B. Between A, and C, the RT
> traffic to B, has flow
> label 50. At router C, the value of 50 changes to 60, and it stays that
> way, to E, where it is changed back from 60 to 50.
>
> Between C and E, the meaning was the same, as between A, and C, and E,
> and B, that is
> the RT traffic between A and B.
>
> The flow label bits were mutable, the meaning was immutable.
Yes, it *could* work that way but I would argue against it - I'd much rather
keep it simple and have the flow label immutable.
[EMAIL PROTECTED] wrote:
...
> > That's an interesting thought, but I think it doesn't work.
> > The egress router
> > has to *know* that the flow label is in diffserv format, and
> > I think that
> > requires some magic.
> >
>
> Wouldn't the absence of intserv state for the flow at the domain egress be
> the magic for this determination?
That's an interesting thought.
if flow label != 0
and there is no intserv state
then try diffserv classification
This needs a little thought but it looks hopeful to me.
>
> A related question: Flow label field is presumably end-to-end, i.e.
> non-mutable. How can some random diffserv domain egress router know if the
> flow label value should be honored or not (even if it had a specific format
> for the PHB-ID)?
All diffserv classifiers require configuration. This would mean configuring
a classifier to look for (say)
Destination IP = Big Customer X
Source IP = *
Flow Label = 12345
This is a new form of diffserv classifier. Alex has a draft ready to ship
on this, but we decided to wait. Since "12345" would be a globally defined,
well known value, it is just built into the QOS policy repository of any
ISP that wants to support it. (This is what Tony thinks should be done
with the DSCP values.)
...
>
> I thought the current definition of the MF-classifier in intserv would allow
> usage of the flow label field for classification.
Yes, except that RFC 2460 does not describe this in normative text.
...
> My precise point was that *between domains* PHB-ID carries 6 bits of
> information only (the standardized DSCP values). Any *local use* values
> would not be used inter-domain, and any *experimental* value usage would
> need bilateral agreements (perhaps as part of the SLAs), so for this info
> (mapping from an *experimental* PHB-ID to the actual behavior definition) an
> out-of-band signaling method (online or offline) exists already.
Correct. This is the point that Tony argues right at the top of this message,
with my reply. There is some non-IETF work on signalling for this, but
the real world solution today is off-line SLAs.
...
> Hopefully the SLAs specify what treatment should be given to which packets.
> It is not up to IETF to standardize redundant technologies just because a
> "business decision says so".
I really don't understand that comment. We have to aim for simplicity,
but we also have to solve real world problems. Telling the ISPs what
they are allowed to put in theirs SLAs isn't an option.
>
> In my opinion, you have not yet shown a convincing scenario, where the
> proposed behavior aggregate usage of the IPv6 flow label field actually
> provides something we don't already have. You should provide a concrete
> example showing the relationships between the operators, who marks what
> (end-to-end/hop-by-hop), how the traffic is policed etc.
There is no new scenario here; the scenario is an absolutely standard
diffserv scenario with multiple ISPs on the path, with traffic conditioning
at every ISP boundary. What we don't have (with ESP) is the ability
to perform full traffic conditioning at those boundaries.
Michael Thomas wrote:
>
> Sorry if this is redundant; it's been a hard thread
> to keep up with.
Oh really? :-)
...
> I've got what may be a pertinent question: do the re-classifiers
> require actual knowledge of the contents of the encrypted headers,
> or do they just require the ability to differentiate the unique
> flows associated with a particular DSCP?
It's the former; if an ISP chooses to disbelieve the upstream ISP,
and re-classify the traffic, the semantics of the transport
header are exactly the information of interest.
>
> If it's the former, I think I object to requiring a node to
> _have_ to reveal information (quite valuable information, if
> you consider it) in order to obtain QoS.
Indeed, I think this is a basic trade-off: to ask for QOS in the
absence of both signalling and SLAs, you have to reveal something.
The security question is whether revealing a PHB ID is acceptable.
It would allow an intruder to figure out how much traffic of
which kind Bob is sending to Mary, but there is less detail
than port/protocol numbers would give.
Or to put it another way, if your level of paranoia prevents you
from revealing a PHB ID, then you have three choices:
a) accept default QOS
b) use IntServ
c) ensure that all ISPs on the path have the right kind of SLA
> At the very least,
> how is a non-signaled diffserv host to know whether it
> should or should not insert the revealing information into
> the flow label? If the answer is that it always has to do
> that, you have effectively defeated one of the useful
> protections of ESP. This would be very bad.
I think this would have to be configured by local policy
(an interesting blend of security and QOS policy).
> > > The set of packets identified as a
> > > flow will be the same with either QoS mechansim, so why is there
> > > a need to have distinct semantics unless someone in the middle wants
> > > to interpret them?
> >
> > Diffserv is blind to microflows; there is no flow identification.
> > However, diffserv classifiers in the middle *do* need to (re)interpret
> > packet headers. That is how diffserv works.
>
> I'm afraid that this makes no sense at all.
The point is that the diffserv low level scheduling mechanisms are
driven entirely by the 6-bit DSCP field and that is the only
thing that core routers look at. That's what we mean when we
say diffserv is blind to microflows. The edge classifiers are
also very unlikely to be microflow based; although they use 5-tuple
classifiers, we expect the addresses and ports to be ranges or wild
cards in most cases. In fact it would be quite unusual for a
diffserv classifier to look for a specific microflow rather
than a large class of microflows.
...
> > Indeed, and since I don't quite see how IPSEC and NAT-PT are going to
> > work together, the need that triggered this discussion (the need to
> > classify ESP packets in the middle of the Internet) really doesn't arise
> > in the case of translated packets. The concern is for a native IPv6 environment.
>
> The current proposed lossage involves ESP over UDP.
> In fact, that would probably provide you with what
> you need for both v4 and v6.
Only in a limited sense, because the actual port and protocol values
will be hidden. Diffserv would work just fine, but all ESP/UDP packets
would be treated the same.
[EMAIL PROTECTED] wrote:
...
> For the proposed diffserv usage the flow label should be mutable to enable
> policing and aggregation. The point is that the flow label should NOT be
> locally mappable, it MUST always contain a standardized value, or it's
> semantics must be signaled (�la intserv).
As I noted above, that is a sufficient solution, but I don't think
mutability is necessary; when a domain wants to aggregate it can use
the diffserv code point to do that.
...
> It may be that diffserv cannot be changed NOT to allow local mapping any
> more, but where are these ISPs NOW?
They went away when RFC 2474 was published, literally saying "we got what
we want." Just recently we have got some ISP people back in diffserv,
but I haven't seen any attempt to rediscuss the mapping issue, which is
of course very deep in all implementations and in the MIB.
...
> Another problem is the MF-classification defined by the diffserv: How long
> you think it takes for the SLAs to be updated end-to-end (or more precisely,
> hop-by-hop), when two consenting hosts switch to SCTP instead of TCP?
The SLAs and local policies are database and human driven. They need to anticipate
all ports etc to be used in advance.
...
> I hope that if we'll have the flow label support for what Brian is asking
> (standard, non-mappable behavior aggregates), he'll promise to remove the
> MF-classifiers peeking into transport headers from the diffserv specs :-)
> (also from the non-ESP case).
That's not going to happen.
...
> I might be wrong, but it seems that a downstream (operator) router CANNOT
> use end-to-end immutable information. If the policer in the 1st operators
> domain concludes that the customer is not paying enough for the treatment
> he's asking, the "treatment indicator" needs to be downgraded. If that is
> not allowed, the only other option would be to drop the packet altogether.
This can be done at the DSCP level (mark the packet for best effort). There
really is no need to change anything else.
Tony Hain wrote:
...
> The operators are finding that making
> the DSCP completely random has resulted in a useless technology.
It isn't random, come on. It's locally configured. If operators
want values that cross domain boundaries, they either use the
recommended values, write an SLA, or both. This isn't hard.
...
> I was being very careful not to use the 5-tuple
> because the src/dst addresses are mutable thanks
> to NAT. The only end-to-end consistent bits are
> the protocol & port, and the flow label.
In this case I don't think NATted addresses are a problem at all.
The addresses (both source and destination) are both meaningful
within a given domain - even Net 10 addresses are meaningful within
their own domain - and MF classifiers are configured within a given
domain too. Mutable addresses seem to be a problem for intserv since
they are signalled in FlowSpecs, but not for diffserv.
Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
