[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: TOS copying considered harmful
See draft-ietf-diffserv-tunnels-02.txt (IESG-approved
to be issued as an informational RFC) for more discussion
of this and related issues. Forcing the DS codepoint
to a known value such as 0 is one way to deal with this
sort of situation, but not the only one, and could
be very wrong in some situations.
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA 01748
+1 (508) 435-1000 x75140 FAX: +1 (508) 497-8500
black_david@emc.com Mobile: +1 (978) 394-7754
---------------------------------------------------
> -----Original Message-----
> From: Henry Spencer [SMTP:henry@spsystems.net]
> Sent: Wednesday, September 13, 2000 12:29 PM
> To: IP Security List
> Subject: TOS copying considered harmful
>
> RFC 2401's discussion of how to prepare the outer headers in tunnel mode
> (5.1.2.1) is quite explicit that the TOS field is copied from the inner
> header to the outer header. In the grand tradition of IPsec RFCs, there
> is no rationale -- no explanation or discussion of tradeoffs.
>
> I suggest that this copying is a mistake -- that the TOS of the outer
> header should be forced to a specific value, probably 0 -- unless,
> perhaps, all traffic carried by the tunnel has the same TOS. (How that
> would be known is less clear, although conceivably one could copy TOS
> for the first packet and just use that value for all subsequent packets.)
> At the very least, the spec should allow implementations to do this if
> they wish.
>
> Why? Two reasons.
>
> First, copying TOS is a security leak: it permits an eavesdropper to
> categorize packets, which may aid traffic analysis or cryptanalysis. One
> major reason for routing different types of traffic through the same
> tunnel is specifically to *interfere* with such analysis, but the gain
> from doing so is compromised by this information leak.
>
> Second, as noted in recent work by the diffserv WG, packets with different
> TOS values may be re-ordered en route, and "slow" packets on a busy path
> can end up outside the AH/ESP anti-replay window.
>
> Henry Spencer
> henry@spsystems.net
>