below... On 2011-05-07 07:50, George, Wes E [NTK] wrote: > -----Original Message----- > From: Thomas Narten [mailto:[email protected]] > Sent: Friday, May 06, 2011 9:27 AM > Subject: Re: Flow label drafts updated > > Is the UDP port number mutable? Is the TCP sequence number immutable? > [WEG] I think both are immutable because there's a checksum to detect > changes. That doesn't make it impossible to change it in the > middle, as you mention, but it makes it much less likely that it will be. > > There are ways of modifying them that are undetecable. Does that make them > mutable? > [WEG] Would you write similar language into the TCP and UDP spec like this > that claims immutable but that implementers should assume > that it'll be changed along the way? By my interpretation, it comes down to > level of risk for modification. IMO the checksum is a > significant difference and means that there is a reasonable assumption that > things won't be changed along the way. At the very least > it'll detect changes due to data corruption, which you can't say for the IPv6 > header. > > The intention is that the Flow Label not get modified. Doing so can impact > its usefulness. This is true of most fields in packets. > If random actors start tweaking various fields in a packet, that tends to not > be helpful (or worse). > [WEG] Absolutely agree, but I don't think that calling it immutable is the > only way to say it, especially if you bracket it with a > qualifier that says it's likely to get changed anyway. > > I do think the document needs to say something about covert channels and > border routers zeroing out the field (and not just stick > its head in the sand and try to have it both ways, which the wording Wes > quoted effectively does). > But that doesn't mean we are declaring that the field is "mutable", implying > that anyone can start doing with it what they want. > [WEG] fair enough, but I think this is sort of like the line between MUST NOT > and SHOULD NOT. > What you're saying here is you SHOULD NOT change the value, while > acknowledging that it's likely to happen in certain applications.
It's the first I've heard of it. You MUST NOT change addresses and port numbers in a packet; not that RFC 791 and 793 bother to mention it, because it was unimaginable in 1981 that anyone except an attacker would do such a thing. I'm hard over on a MUST NOT. What we've been arguing with Thomas is really about how to express the warning that the flow label might get undetectably changed by an on-path device, even though that is against the standard. A node downstream from the change can't tell that it was changed, whether maliciously or by a misguided firewall. Brian > To me, Immutable implies MUST NOT be changed, and while people may still > ignore MUSTs it's less likely. > To me, "anyone can start doing what they want" implies a MAY be changed > > Wes George > > > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
