On 07/11/2008 02:34 PM, Dan Wing wrote:
On 7/11/08 1:58 PM, Dan Wing wrote:
It is the conundrum for the entire Internet -- TCP 'protocol
scrubbers' exist, TCP options get dropped, DSCP bits get changed,
ECN bits are mangled, and Router Alert Option gets dropped.
Such is the reality. I wish it weren't the reality, too.
So... are groups within TSV proposing new extension header fields to
carry things like "orginal diffserv codepoint" with the hope that TCP
protocol scrubbers won't mess them up?
http://tools.ietf.org/html/rfc3168#section-8
This section considers the issues when a router is operating,
possibly maliciously, to modify either of the bits in the ECN field.
We note that in IPv4, the IP header is protected from bit errors by a
header checksum; this is not the case in IPv6. Thus for IPv6 the
ECN field can be accidentally modified by bit errors on links or in
routers without being detected by an IP header checksum.
By tampering with the bits in the ECN field, an adversary (or a
broken router) could do one or more of the following: falsely report
congestion, disable ECN-Capability for an individual packet, erase
the ECN congestion indication, or falsely indicate ECN-Capability.
Section 18 systematically examines the various cases by which the ECN
field could be modified. The important criterion considered in
determining the consequences of such modifications is whether it is
likely to lead to poorer behavior in any dimension (throughput,
delay, fairness or functionality) than if a router were to drop a
packet.
...
Yes, the authors of RFC 3168 analyze what happens when a router is
acting outside of specification, potentially with malice. But is TSV
actively engaged in specifying how to duplicate information in a
different part of the message in the hope that these non-conformant,
potentially malicious intermediaries won't find it?
No, they aren't. Because that would be patently ridiculous. Recognizing
the potential for an attack doesn't necessarily force the definition of
comically[1] ill-conceived and easily defeated countermeasures.
Assume the draft on the table is published and implemented. How long
before someone decides that their SBC "needs" to modify the
"P-Original-To" header field? And when they do, will we just define
another header field to squirrel away yet another copy of this
information? (Should we go ahead and define "P-Original-P-Original-To"
right now?)
/a
[1] I'm not using this word lightly -- when I presented the proposed
solution of "signing P-Asserted-Identity" to a room full of engineers
familiar with the SIP protocol, they broke out in spontaneous laughter.
Without the frog-boiling that led us here as a working group, this idea
is clearly humorous.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
