Subject: [Int-area] ICMP-MPLS

From: Ron Bonica <[email-masked]>
Date: Thu, 04 Aug 2005 10:40:37 -0400

Folks,

Thank you for permitting me to present draft-ietf-mpls-icmp to the
Internet Area. From your comments, I gather that we have three distinct
questions before us:

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.

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).

The third question is specific to draft-ietf-mpls-icmp. That is, do we
want to extend ICMP to include MPLS information.

The three questions are somewhat, but not entirely orthogonal to one
another. Therefore, there are 2**3 possible responses to these questions
with some combinations making more sense than others.

Also, there is a question to how we should proceed. Those who answer 
"no" to all of the questions above suggest that the draft should be 
scrapped. However, those who answer "yes" to questions 1 or 3 might 
suggest either of the following:

- split the draft into two parts. The first part addresses question #1, 
while the second addresses question #2
- publish the draft as a BCP or an informational RFC.

Comments?

                                     Ron

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Aug 2005 08:30:26 +0300 (EEST)

In the interest of getting debate started...

> 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.

> (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.

> 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

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 10 Aug 2005 14:43:31 +0200

Some half baked thoughts:

>> 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.

In principle, we already have such a mechanism: introducing new  
message Types with new message contents.  That may even work in  
practise for ICMPv6 due to most implementations still being fairly  
new and flexible.  On the other hand, it may be quite hard for many  
IPv4 environments.

>> 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).

As long as those messages would be informational, I don't see much  
problems.

Including such data in error messages appears more problematic to me:
- new error messages may not be a good idea since the upper layer may  
not know how to handle it
- error messages are expected to include as much of the IP packet as  
possible, as per Section 2.4.c of
   RFC2463 and Section 4.3.2.3 of RFC 1812.
- adding new data to existing error messages is problematic due to  
the current syntax

The only exceptions might be Destination Unreachable and Time  
Exceeded, where the Unused field could possibly be used to encode  
something useful, like where the IP layer data ends and lower layer  
data begins.

Personally, and without thinking too much, adding a new Informational  
message type to convey lower layer related informational error data  
appears like one possible way to go forward.

> arbitrarily limiting the size of the message seems a bit  
> questionable to me though.

Here I completely agree with the other Pekka.

--Pekka Nikander

---

From: Ron Bonica <[email-masked]>
Date: Wed, 10 Aug 2005 10:29:00 -0400

Pekka,

Thanks for your thughtful comments. Responses are below:

> 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
> whatever).  It has more value for the network operator.

Agree. It is mostly useful to operators.

   So, the
> 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.

>> - 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

---

From: Ron Bonica <[email-masked]>
Date: Wed, 10 Aug 2005 16:45:10 -0400

Pekka,

Thanks for these comments. Response below:

Pekka Nikander wrote:
>>> syntax that allows us to extend ICMP messages?" This syntax must  
>>> allow us to extend any ICMP message, including those that  currently 
> In principle, we already have such a mechanism: introducing new  message 
> Types with new message contents.  That may even work in  practise for 
> ICMPv6 due to most implementations still being fairly  new and 
> flexible.  On the other hand, it may be quite hard for many  IPv4 
> environments.

I considered this and decided that it was impractical for IPv4. In order 
to be backwards compatible, an LSR would have to emit two ICMP messages 
for each undeliverable datagram. One old-style and one new-style.

>>> extend ICMP so that it will contain information that might be  useful 
>>> for debugging, even if that information is not strictly IP  
> - adding new data to existing error messages is problematic due to  the 
> current syntax
> 

Most legacy ICMP implementations send only the IP header plus the first 
eight octets of the original datagram. I am only aware of one vendor who 
sends more.

Because most implementations send only 28 octets, I think that it is 
unlikely that any legacy applications rely on the integrity of anything 
beyond the 128th octet. (The current proposal requires that the first 
128 octets are send in tact.)

Your point is well-taken and we did consider it at first. However, these 
extentions have been widely deployed for several years and I am not 
aware of any legacy applications having broken.

                                  Ron

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 11 Aug 2005 08:12:23 +0200

Ron,

>>>> The first is a syntactic question. That is, "Do we want to  
>>>> define  a syntax that allows us to extend ICMP messages?" ...
>>>>
>> message Types with new message contents.  ...
>
> I considered this and decided that it was impractical for IPv4. ...
>
>>>> 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).
>>>>
>> As long as those messages would be informational, I don't see  
>> much  problems....
>
> ...

> Your point is well-taken and we did consider it at first. However,  
> these extentions have been widely deployed for several years and I  
> am not aware of any legacy applications having broken.

So, publish the current draft as Informational with a suitable note  
saying that this is the currently deployed practise, stating that  
there are architectural problems in the way it is done, and that the  
practise should not be extended?  And at the same time, try to do the  
right thing for IPv6, and possible future IPv4 extensions?

--Pekka Nikander

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 11 Aug 2005 09:00:54 -0500

> right thing for IPv6, and possible future IPv4 extensions?

I'm having a hard time seeing why this would be wrong :-)

Spencer

---

From: Ron Bonica <[email-masked]>
Date: Thu, 11 Aug 2005 15:46:49 -0400

> saying that this is the currently deployed practise, stating that  there 
> are architectural problems in the way it is done, and that the  practise 
> should not be extended?  And at the same time, try to do the  right 
> thing for IPv6, and possible future IPv4 extensions?
> 
> --Pekka Nikander
> 

Pekka,

On one hand, I would be happy to do this because it solves the problem
for MPLS. Let's keep this in mind in case we don't reach a more
satisfying solution.

One the other hand, the solution is not altogether satisfying because it
leaves ICMP inextensible. Let's discuss the issue for a little while,
while it is fresh in our minds, to see if we can come up with a solution
to the more general problem of ICMPv4 extensibility.

The following ICMP messages are currently defined:

- Destination Unreachable
- Redirect
- Source Quench
- Time Exceeded
- Parameter Problem
- Echo Request/Reply
- Information Request/Reply
- Timestamp and Timestamp Reply
- Address Mask Request/Reply
- Router Advertisement and Solicitations

At the time of their definition, the Redirect and Echo Request/Reply
messages were unique in that they could not be extended. They were
inextensible because a) the final field in the message was of variable
length and b) that field did not have an associated length attribute.
So, you had a problem parsing the message if you added another field at
the end of it.

RFC 1812 added Destination Unreachable, Source Quench, Time Exceeded and
  Parameter Problem to this category by converting their final fields,
which had been of fixed length, to variable length. The final field in
these messages represented as much as possible of the original datagram
to which the ICMP message was a response. The IP header plus first 8
octets of the original datagram were required. As many subsequent bytes
as possible were desirable.

Now we are faced with the following problem: "How do we make
non-extensible messages extensible without breaking any legacy
applications, including existing implementations of MPLS-aware TRACEROUTE."

The following is a proposal:

The following ICMPv4 message types are extensible because they do not
end in a variable length field:

- Information Request/Reply
- Timestamp and Timestamp Reply
- Address Mask Request/Reply
- Router Advertisement and Solicitations

The ICMPv4 messages can be made extensible:

- Destination Unreachable
- Source Quench
- Time Exceeded
- Parameter Problem

In order to make them extensible, allocate 8 bits of the UNUSED field to
indicate the length of the final field. If these 8 bits are clear, we
can assume that we are looking at an older version of ICMP. So, the
application is on its own to determine whether the ICMP message contains
any extensions.

In order to achieve backward compatibility with existing MPLS-aware
TRACEROUTE applications, if extensions are specified, the variable
length field (containing the original datagram) must be 128 octets or
more. The original datagram may be zero padded to 128 bytes if the
device originating the message cannot send 128 bytes of the original
datagram.

This way existing mpls-aware TRACEROUTE applications should continue to
work, unless the router generating the ICMP message sends _more_ than
128 bytes of the original datagram.

Unfortunately, the following ICMP messages do not have any UNUSED bits,
so they cannot be made extensible:

- Redirect
- Echo Request/Reply

                               Ron

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 12 Aug 2005 10:40:48 +0200

>> So, publish the current draft as Informational with a suitable  
>> note  saying that this is the currently deployed practise, stating  
>> that  there are architectural problems in the way it is done, and  
>> that the  practise should not be extended?  And at the same time,  
>> try to do the  right thing for IPv6, and possible future IPv4  
>> extensions?
>

Good.

> leaves ICMP inextensible.

I see your motivation.

[Skipping the very good and sensible introduction for the sake of  
brevity.]

> In order to make [four ICMPv4 messages] extensible, allocate 8 bits
> of the UNUSED field to indicate the length of the final field. If
> these 8 bits are clear, we can assume that we are looking at an
> older version of ICMP. So, the application is on its own to
> determine whether the ICMP message contains any extensions.

 From the syntactic and practical point of view this seems to work
fine.

What I am worried about is whether this is the right thing to do
from an architectural point of view.  As I said, I don't see any
problems with new informational messages; for traceroute purposes
the right thing to me seems to define a new informational message
that carries the MPLS related information.

My current rough approximation is that we should try to keep ICMP
error messages for IP-related errors.  Hence, the question seems
to boil down to what to do if the protocol beneath IP, such as
MPLS, generates an IP-related error.

Now I must admit that I do not properly understand the
interactions between MPLS and IP, but based on my casual
reading of 2.4 of RFC3032 it seems to be that if MPLS TTL=0
and IP TTL!=0, the right thing to do is NOT to send ICMP Time
Exceeded but a new *informational* ICMP message stating that
the MPLS TTL exceeded.  In my perhaps seriously flawed
understanding, the case is equal to e.g. bridged Ethernet
dropping a packet due a link layer error, and the right
thing to me seems to handle it at the IP layer as a silently
dropped packet.

Section 2.4.3 of RFC3032 (copying back TTL from MPLS to IP)
certainly complicates the situation, and I must admit that I
don't understand it.  To me seems like a layer violation.  I
am sure you discussed it to death when writing RFC 3032; I'd
appreciate a pointer to the relevant discussion in the ML
archive.

If the general perception is that the TTL copyback is indeed a
layer violation (with good reasons, no doubt), then I think my
previous argumentation holds:

   - document the current practise as information with caveats
   - recommend using new informational messages for reporting
     back link layer errors, when possible and appropriate

On the other hand, if the general perception is that it is a
common case for the layer beneath to generate IP-related error
conditions, then it makes more sense to make (some of) the
current ICMP error messages extensible, as you suggested.

Does this make any sense to you or am I just muddling the waters?

--Pekka

---

From: Ron Bonica <[email-masked]>
Date: Fri, 12 Aug 2005 11:10:14 -0400

Pekka,

Thanks again for these very thoughtful comments. It appears that we have 
converged on a solution regarding syntax. However, the architectural 
questions is still before us.

I think that the architectural question can be decomposed as follows:

a) What information should ICMP messages carry?
b) Is the MPLS label stack part of that information?

Although RFC 792 is not specific regarding the first question, I think 
that we can assume the authors' intent. That is, they meant to restrict 
ICMP to layer 3 information, excluding layers 1 and 2.

So, in order to answer part b of the architectural question, we must 
determine whether MPLS belongs strictly to layer 2, strictly to layer 3, 
or some intermediate layer that overlaps both layers 2 and 3.

If MPLS belongs strictly to layer 2 (like Ethernet), MPLS information 
should be excluded from ICMP messages. However, if one were to argue 
that MPLS belongs strictly to layer 2, one would also have to argue that 
the relationship between IP and MPLS is already fraught with multiple 
layer violations. For example:

- MPLS signaling protocols (LDP and RSVP) rely upon IP
- TTL values are copied between the IP and MPLS headers
- LSRs emit ICMP messages when the MPLS TTL expires

So, we might want to allow MPLS information in ICMP messages for no 
reason other than to be internally consistent with the otherwise 
intermingled relationship between IP and MPLS.

So, I would like to propose the following:

We split draft-ietf-mpls-icmp into two drafts. The first draft describes 
a syntactic mechanism for extending ICMP messages. It talks about the 
new length attribute, a common header and a common object header. 
However, it doesn't define any objects. The Internet Area owns this 
draft and it is intended for publication as PS.

The second draft references the first and will describes the MPLS Stack 
Entry Object. The MPLS WG owns this draft and it is intended for 
publication as INFORMATIONAL. It contains an architectural statement 
explaining that layer 2 information is not included in ICMP messages, 
but MPLS information is allowed in order to be internally consistent 
with the otherwise intermingled relationship between MPLS and  IP.

                                  Ron

---

From: Ron Bonica <[email-masked]>
Date: Tue, 16 Aug 2005 10:50:31 -0400

All,

I haven't heard anything on this thread for a few days. So I will assume 
that one of the following statements is true:

- we have reached consensus on the proposal below
- we haven't reached consensus, but people don't object strongly enough 
to speak up

So, if I don't hear anything in the next few days I will assume that we 
have reached consensus, split the draft into two parts and submit them both.

                                 Ron

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 16 Aug 2005 17:10:55 +0200

Personally, I am happy enough as long as you limit it to IPv4, and  
state that
a similar practise SHOULD NOT be adopted for IPv6.  I'd also  
appreciate if the
first document would include some of the architectural considerations  
that we've
came up during this discussion.

--Pekka Nikander

> I haven't heard anything on this thread for a few days. So I will  
> assume that one of the following statements is true:
>
> - we haven't reached consensus, but people don't object strongly  
> enough to speak up
>
> So, if I don't hear anything in the next few days I will assume  
> that we have reached consensus, split the draft into two parts and  
> submit them both.
>
>                                 Ron
>
>
>
>
>
>> We split draft-ietf-mpls-icmp into two drafts. The first draft  
>> describes a syntactic mechanism for extending ICMP messages. It  
>> talks about the new length attribute, a common header and a common  
>> object header. However, it doesn't define any objects. The  
>> Internet Area owns this draft and it is intended for publication  
>> as PS.
>> The second draft references the first and will describes the MPLS  
>> Stack Entry Object. The MPLS WG owns this draft and it is intended  
>> for publication as INFORMATIONAL. It contains an architectural  
>> statement explaining that layer 2 information is not included in  
>> ICMP messages, but MPLS information is allowed in order to be  
>> internally consistent with the otherwise intermingled relationship  
>> between MPLS and  IP.
>>
>
>