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]
--------------------------------------------------------------------
