Brian Carpenter wrote:
> This is a very unfair comment. Diffserv is just fine in the
> case of unencrypted traffic. It has a problem (and so does
> intserv I suspect) with tunnel or transport mode ESP.
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.
> No it doesn't. They should be set at source. (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. 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.
> 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. RFC 2475 starts the
discussion about IPsec interactions, but only from the perspective
of protecting the DSCP. It misses the point that when ESP is in
use there is no visible set of bits to base decisions on for
each domain to set the DSCP. The only set of bits there is left
to work with is the SPI, and the semantics of that are only
known between the endpoints unless signalled via RSVP.
> Products work just fine the way things are.
In fact that is a false statement because those products can't
work today if one tries to use an encrypted channel.
> 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.
> What I am actually
> saying is that this WG should go back and fix the ambiguity problem
> created by the Appendix to RFC 2460.
No argument, but the only ambiguity I see is the comment about
control protocols. The rest of the text is very clear.
Tony
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
