DSCP is mutable enroute. The numbers are from a palette of actions. It is explicite in the DS architecture that ISPs may and SHOULD remark it across boundaries. (I recall the diffserv WG 23 some years ago.. and I've been an operator of b2b VoIP, and we had to make sure we did not allow packets to enter with marks we did not trust in order to protect our VoIP network against outside attack)
The recent situation where certain DSCP values have become "constant" is peculiar. (the palette has ossified) I think that there are recent documents that may make this peculiar situation more permanent, but I can't speak for what's going on there. IPsec receivers MUST NOT check what's on the outside DSCP, and probably SHOULD NOT care whats on the inside, although remarking makes sense. I don't understand this part of the discussion... it is totally outside of what the document is about: Tero quotes RFC4301, and it's totally a concern that if packets in the same IPsec flow get marked (or remarked) differently then that could delay them, and replay windows might close. Tough... the network probably remarked them for a reason, and the alternative was probably dropping the packet. I have read through ipsecme-ts-dscp, twice, to be sure I got it. I understand that the problem is distinguishing between different DCSP values that will be allowed into a single IPsec SA. There is perceived to be a need to communicate this in the IKE negotiation for the SA. So, it doesn't matter if the gateways have twenty IPsec SAs for the twenty classes of services that they want to support, there could yet be more DSCP that do not fit into any SA (and that traffic should be dropped, or maybe should cause an ACQUIRE, or maybe not encrypted, or...). Each of the twenty SAs need to distinguish what goes into each SA. [What goes on the DSCP on the outside is entirely a different question. Copy DSCP is only one possible action, yes, with consequences noted in 4301] (The argument about limited number of SAs does not really ring that well for me, but I'll accept it in the scale of hundreds of thousands of tunnels. Prioritizing voip flows for remote users over HTTP downloads sounds reasonable, particularly for enterprises that insist all traffic go through HQ) Where I have a problem with this document is that in the remote-access situation, there is no value in the laptop system telling the gateway which kinds of DSCP it wants, because the laptop system has NO IDEA what the DSCP markings are at HQ. The gateway SHOULD just be configured correctly. In the case of gateway to gateway situations, it would assume that gateways are each in the same DSCP namespace. So it's a site to site VPN for a single enterprise, and so AGAIN, it can also be configured correctly. In the unlikely case that this is a VPN tunnel between two different enterprises (it does happen, but it's unfortunately rare, maybe Ben will fix that), then the DSCP code spaces are completely different, and it ALSO makes no sense to negotiate DSCP as a traffic selector. I see Joel Halpern as a co-author. Perhaps Joel can better articulate what real world problem this is really trying to solve. -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
