Pekka,
Thanks for your thughtful comments. Responses are below:
I don't see why MPLS information could not be sent, though as said I
have doubts about draft-ietf-mpls-icmp. The main concern here is
obviously that some folks seem to treat the label information as, well,
secret (e.g., arguing that packet injection to the MPLS network is
harder because you need to know the label as well).
MPLS label information should not be treated as secret because, even
without these extensions to ICMP, MPLS labels are _very_ easy to guess.
But that said, if a provider wants to hide the MPLS core from
TRACEROUTE, he can do so by configuring his routers so that the ingress
LSR does not copy the TTL value from the IP header to the MPLS header.
Alternatively, the ingress LSR sets the TTL value in the MPLS header to
some arbitrarily large value (like 255) so that the entire MPLS LSP
appears as a single hop to TRACEROUTE.
> For a general
observer, the MPLS label information is useless (AFAICS) except as a
sign that MPLS is being used (which may be a contract violation or
whatever). It has more value for the network operator.
Agree. It is mostly useful to operators.
So, the
question becomes whether this mechanism is making implicit assumption
that the MPLS network operators would not be allowing (IP) traceroute
except from their network management workstations, which I would not be
comfortable supporting.
These extensions to ICMP should not affect an operator's decision as to
whether he permits TRACEROUTE from outside of his network. While it is
true that these extensions might provide information that is not
particularly interesting to the outside, general observer, it does not
compromise the operator's security posture to reveal this information.
And furthermore, this information is very useful to the operator.
So, I think the main issue here is the usefulness of the information,
the target audience of that information, and the implied or explicit
security model for sharing that information.
- split the draft into two parts. The first part addresses question
#1, while the second addresses question #2
Yes, if we want to extend ICMP, we'll definitely need to figure out how
(and how to deal with ICMPv6 as well). The current proposal of
arbitrarily limiting the size of the message seems a bit questionable to
me though.
However, the current proposal does not arbitrariy limit the size of the
final field. There is is an object designed to carry octets 129 and beyond.
Ron
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
