Bill,
You describe accurately what we get by changing nothing: encrypted traffic
will be subject to a less rich set of QOS policy options than
unencrypted traffic.
Brian
Bill Sommerfeld wrote:
>
> I haven't seen a convincing case why even inter-ISP classifiers need
> to know the inner port numbers or inner ip addresses for encrypted
> traffic.
>
> If I were implementing the hypothetical extension header, I'd have to
> provide policy knobs which determine whether it gets added to outbound
> traffic; while i'm there, in the interests of reducing traffic
> analysis, I might as well add a knob which lets the policy rule
> specify what goes in the extension header (independant of the actual
> inner traffic), and naturally, in the interest of interoperability,
> there's no way that the receiver would enforce a relationship between
> the extension header and the actual packet traffic (because it doesn't
> actually matter to the end system and flies in the face of the "be
> liberal in what you accept" principle).
>
> Given that, I don't see what the extension header actually buys you..
>
> The inter-ISP classifier can still reclassify based on a 3-tuple
> (outer-src,outer-dst,outer-proto=ESP), and at the ISP boundary can
> still deliver differentiated services to customers who want (and pay
> for) priority handling of encrypted traffic based on the destination
> address of a packet received from a peer using an unknown diffserv
> tagging scheme; and, even if you do know the tagging scheme, you still
> likely have to use the inbound tag in conjunction with other selectors
> to determine the tag used within your network..
>
> If there's demand for multiple classes of handling for encrypted
> traffic between a single pair of hosts, then both customers will be in
> a position to pressure their ISP's to play nice together and agree how
> to label traffic on the inter-ISP link.
>
> - Bill
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
