Tony Hain wrote:
>
> > [...] (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.
I do insist on the distinction between the bits in the field, and the
meaning carried by the bits. So let me clarify this once more, for the
last time.
The bits in the field are mutable, they are "read/write". Checksum, and
authentication
skip them. It was very wise that the WG decided and did it so.
The meaning of the Diffserv flow label bits is immutable.
There seem to be a mixing of the two, and an insisting on the
immutability of the bits, on your side. But I think in reality, you care
about the immutability of the meaning of the bits. That is the essence,
and one should not care of what happens with the bits, as long as the
meaning is preserved, which is the point I am trying to get across,
perhaps not clearly enough. I hope it is clearer now.
> [...]
. 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.
>
You are pointing to tunnel mode ESP, and not transport mode ESP.
> > 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.
>
Brian refers to transport mode ESP.
> [...]
> Tony
Alex
S/MIME Cryptographic Signature
