In the interest of getting debate started...
On Thu, 4 Aug 2005, Ron Bonica wrote:
The first is a syntactic question. That is, "Do we want to define a
syntax that allows us to extend ICMP messages?" This syntax
must allow us to extend any ICMP message, including those that currently
end in a variable length field that lacks a length attribute.
I don't see why we couldn't define such a syntax, though I have doubts
about the proposal in draft-ietf-mpls-icmp-03.txt.
The second question is architectural. In the future, do we want to
extend ICMP so that it will contain information that might be useful for
debugging, even if that information is not strictly IP information
(i.e., even if it constitutes a small layer violation).
I don't see this as a big problem, though this could open a can of
worms -- e.g., would we want to include the "description" field of the
interface as well, some layer 1 info (if available), etc.
The third question is specific to draft-ietf-mpls-icmp. That is, do we
want to extend ICMP to include MPLS information.
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). 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. 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.
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.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
