Hi Guy, point 3 and probably point 4, are too risky. If we go against the best current practice (RFC 4928, BCP 128) we need a very-very strong indication that the following data is not IP. I agree on everything else.
thanks ciao fra On Sun, Jan 8, 2017 at 2:31 AM, Guy Harris <[email protected]> wrote: > On Jan 7, 2017, at 9:39 AM, Jaap Keuter <[email protected]> wrote: > >> There has been a steady stream of MPLS PW related comments and bugs over >> time, >> and things haven't improved enough, apparently. This text tries to give some >> insight in the issues so that possible solutions cover all cases involved. > > I'll start here with a broader discussion of how a protocol specifies the > protocol running above it, and how the dissector for the first protocol > selects the dissector for the next protocol. > > Some protocols have a "next protocol" field or fields (Ethernet, IEEE 802.2, > SNAP, IPv4, IPv6, anything with an IANA media type string, ...). For those, > it's easy - use a dissector table, and it will handle 99.99999999999999999% > of the cases correctly. "Decode As" would be necessary only in cases where > two protocols are using the same value, either because the old protocol's > assignment was revoked and a new protocol given the assignment (which doesn't > sound like good practice, unless you have a *really* small set of possible > values) or because somebody's not playing by the rules. Heuristics should > only be necessary in cases where the field is optional, such as IANA media > type strings. > > Some protocols have a field or fields that indicate a source or destination > port, or a circuit number, which might be usable *hint* for identifying the > next protocol, but which is not sufficient to indicate it (TCP and UDP are > the canonical examples of this; ATM's VPI/VCI are another example). For > those, you use a dissector table with dissectors that do checks and reject > packets, heuristics, mechanisms for other dissectors to make port-to-protocol > assignments if that can be done(e.g., SDP and RTCP setting up RTP sessions), > and, when all else fails - which could be fairly common - Decode As. > > For the latter category of protocols, the fewer "well known" field values > there are, the more you depend on heuristics to avoid Decode As. MPLS is a > protocol with *very* few "well known" label values. > > MPLS is a very good example of the last category of protocols; RFC 3032 gives > only 16 reserved label values. That's the problem here; at least with TCP > ports, for example, a lot of the well-known ports help. > > The protocols we support atop MPLS are: > > I-TDM (Internal TDM) > Y.1711 (has a reserved label) > ATM pseudo-wires of various sorts (RFC 4717) > CESoPSN pseudo-wire (RFC 5086) > Ethernet pseudo-wire (RFC 4448) > Frame Relay pseudo-wire (RFC 4619) > PPP/HDLC pseudo-wires (RFC 4618) > SAToP (RFC 4553) > IPv4 > IPv6 > Pseudo-wire Associated Channel Header dissection (RFC 4385) > > For most of these, we require Decode As. > > The exceptions are: > > IPv4, IPv6, Associated Channel Header, Ethernet > > for which, for frames with no explicit binding to a label, we use the > first-nibble heuristic, possibly combined with other heuristics. > > In addition, the Ethernet pseudo-wire dissector also uses heuristics to > determine whether there's a control word or not. It *looks* as if the ATM > pseudo-wire dissector always assumes a control work, even though RFC 4717 says > > The features that the control word provides may not be needed for a > given ATM PW. For example, ECMP may not be present or active on a > given MPLS network, strict frame sequencing may not be required, etc. > If this is the case, and the control word is not REQUIRED by the > encapsulation mode for other functions (such as length or the > transport of ATM protocol specific information), the control word > provides little value and is therefore OPTIONAL. Early ATM PW > implementations have been deployed that do not include a control word > or the ability to process one if present. To aid in backwards > compatibility, future implementations MUST be able to send and > receive frames without a control word present. > > If the control word were *always* present, we wouldn't be having these > problems, and people wouldn't be filing bugs. Thus, the bugs demonstrate > that, at least for Ethernet, the control word isn't always present. > > Bug 11849 was due to an "is this Ethernet?" heuristic being too strong, by > accepting only a small number of Ethertypes; it was fixed by weakening the > heuristic not to look at the type/length field at all. > > Bug 13039 is due to the "is this Ethernet?" heuristic being too strong, by > not accepting frames with local MAC addresses. > > Bug 13295 is due to the "is this Ethernet?" heuristic being too weak, by > accepting frames with unknown Ethernet types. > > Bug 13301 is due to the "is this IPv4? and "is this IPv6?" heuristics being > too strong, by accepting, respectively, every frame with 4 in the first > nibble as IPv4 and every frame with 6 in the first nibble as IPv6. > > There are a number of ways to solve this: > > 1) Make the Ethernet dissector like the other pseudo-wire dissectors, > and require "Decode As". > > Presumably this was not done because Ethernet pseudo-wires are > popular enough that this would require too much "Decode As". (And, > presumably, the other pseudo-wires are *not* popular enough for this to be an > issue.) > > 2) Fix the heuristics for Ethernet-without-control-word. > > This would address bugs 13039 and 13295, by weakening the > heuristic where it needs to be weaker and strengthening where it needs to be > stronger (the latter also makes the former less likely to break things). > > It doesn't address bug 13301, however. > > 3) Fix the heuristics for Ethernet-without-control-word and even hand > frames with a first nibble of 4 or 6 to an "is this Ethernet without a > control word?" heuristic dissector - if that dissector says "no", dissect the > packets as IPv4 or IPv6. > > That would also fix 13301, but would run the risk of > mis-dissecting some IPv4 or IPv6 frames as Ethernet-without-control-word. > > 4) Fix the heuristics for Ethernet-without-control-word and > strengthen the first-nibble checks for IPv4 and IPv6 to also check some other > fields, such as the "protocol" and "next header" fields. > > That would also fix 13301, but would run the risk of > mis-dissecting some IPv4 or IPv6 frames as Ethernet-without-control-word, > although that risk might be lower than with 3). > > We might also want to have a preference to deal with the "first nibble of the > MAC address is 4 or 6" issue. > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
