Subject: [Int-area] Fwd: I-D Action: draft-shen-traceroute-ping-ext-04.txt

From: Naiming Shen <[email-masked]>
Date: Fri, 2 Mar 2012 11:54:33 -0800

Hi all,

this is a new version of traneroute-ping-ext(-04) draft posted.
there were many discussions of this draft(-03) on this list, and the main
concern was the scalability of the extension on the Internet and I think
we got that.

this new version has a couple of major changes:

 - a well-known UDP/TCP port and ID for icmp is added for this extension
 - the extension structure now starts at a fixed location in data field
 - added discussion section for design/impl/config part of this extension

please review and comment.

thanks.
- Naiming

Begin forwarded message:

> From: [email-masked]
> Date: February 27, 2012 1:39:38 PM PST
> To: [email-masked]
> Subject: I-D Action: draft-shen-traceroute-ping-ext-04.txt
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Traceroute and Ping Message Extension
> 	Author(s)       : Naiming Shen
>                          Carlos Pignataro
>                          Rajiv Asati
>                          Enke Chen
>                          Alia K. Atlas
> 	Filename        : draft-shen-traceroute-ping-ext-04.txt
> 	Pages           : 12
> 	Date            : 2012-02-27
> 
>   This document specifies extensions to traceroute and ping techniques
>   to convey additional application information to be carried in UDP,
>   TCP and ICMP traceroute probe messages and ICMP echo request and
>   reply messages.  The extensions are backward compatible.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-shen-traceroute-ping-ext-04.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-shen-traceroute-ping-ext-04.txt
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 3 Mar 2012 08:55:45 +0000

Hi,

> 8.  IANA Considerations
> 
>    The IANA is requested to assign a well-known port number, Trace-Ping
>    Port, for the UDP and TCP of this Trace-Ping extensions.

I'm curious why you think you need a port number for this ping extension. Ping is a diagnostic procedure that can be used with any port, and placing payload into the packet sent to elicit the ICMP response doesn't change that.

In other words, ping isn't a protocol.

Also, with regards to TCP ping, do you envision your payload data to be placed inside the SYN?

Lars

---

From: Naiming Shen <[email-masked]>
Date: Mon, 5 Mar 2012 14:31:45 -0800

Hi Lars,

> I'm curious why you think you need a port number for this ping extension. Ping is a diagnostic procedure that can be used with any port, and placing payload into the packet sent to elicit the ICMP…

Yes, I understand Ping can use any port(or Identifier as in this draft). But it's rate-limited
also randomly by routers on the Internet. This well-known port/id can signal a new service
for the network, and can be subject to different filtering profile.

> Also, with regards to TCP ping, do you envision your payload data to be placed inside the SYN?

Yes for syn or ack. The tcp server should not care about the length being zero or not though.

thanks.
- Naiming

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 6 Mar 2012 06:50:57 +0000

Hi,

> for the network, and can be subject to different filtering profile.

Clarification: you mean that the *generation* of ICMP messages at routers is rate-limited, correct? And the hope is that if the packets eliciting ICMP responses contained a transport packet with a certain source or destination port, the router would apply a more lenient rate limit when generating ICMP responses for those packets.

Is this realistic? I'm not a router guy, but I thought routers rate-limit the generation of ICMP messages because it involves slow-path processing. In your scheme, a router would need to further DPI packets that may cause ICMP responses in order to determine what rate limit to apply, requiring even more processing. Doesn't that kind of defeat the purpose?

In addition, eyeball ISPs would need to filter that port at the boundary to prevent the clients from using it, too, which again complicates things. Because once you set up more lenient rate limits for ICMPs for a given port, you can be sure that clients would start using that port, too.

> Yes for syn or ack. The tcp server should not care about the length being zero or not though.

I don't understand what you mean by "length being zero." Could you elaborate?

Thanks,
Lars

---

From: Naiming Shen <[email-masked]>
Date: Mon, 5 Mar 2012 23:46:30 -0800

Hi Lars,

> Clarification: you mean that the *generation* of ICMP messages at routers is rate-limited, correct? And the hope is that if the packets eliciting ICMP responses contained a transport packet with a…

The previous version of this draft didn't have this well-known port defined, and we got
many comments on how to distinguish the packets with new features from the general
traceroute/ping packets on the Internet, as you mentioned below, it needs more deeper
packet inspection. With this well-known port, a provider's internal use of certain feature with
this extension can be more easily sort out from normal trace/ping packets (before the deeper
packet inspection).

> Is this realistic? I'm not a router guy, but I thought routers rate-limit the generation of ICMP messages because it involves slow-path processing. In your scheme, a router would need to further DP…

It requires more processing since if there is a new service using this extension, then the packets need more processing.
But those extra processing will not be imposed on the "normal" trace/ping packets. The well-known port here is
to distinguish those two types.

rate-limit is just an example of implementation related to this. icmp or trace ratelimit is to protect the slow path,
or even when the replies are done on the LC(fast path), they are normally rate-limited. If this extension for
example, at the router inbound it detects the packet with this well-known port, it can hand it to that feature processing
to run through an ACL (e.g. the configure requires the features only be allowed from their mgmt station
subnets), if all is well, then punt the packet to the feature handling(the slow path) with its own rate-limit.

> In addition, eyeball ISPs would need to filter that port at the boundary to prevent the clients from using it, too, which again complicates things. Because once you set up more lenient rate limits…

I agree. This draft also has a section on the scalability of implementation and configuration.
Usually the features should be enabled with configuration and also filtering along with it.

> I don't understand what you mean by "length being zero." Could you elaborate?

I meant the TCP payload length of the SYN packet doesn't have to be zero.

thanks.
- Naiming

---

From: Joe Touch <[email-masked]>
Date: Wed, 07 Mar 2012 17:29:59 -0800

Hi, all,

On 3/5/2012 11:46 PM, Naiming Shen wrote:
...
> this extension can be more easily sort out from normal trace/ping packets (before the deeper

A ping (ICMP echo request) message has no port. It has an Identifier 
field that is used "like a port in TCP or UDP to identify a session" 
[RFC792], but it identifies a session not a protocol. I.e., it should 
change for subsequent echo requests, so this should not be fixed at a 
specific value.

Traceroute uses ICMP with varying TTLs, so a port number is equally 
meaningless there.

Sec 5 of this doc redefines how ping works - when it reaches the valid 
destination, an echo response is sent back. That's how ping knows it 
works, and how traceroute knows to stop.

If you intend on using these inside UDP or TCP segments, you need to be 
much more specific about what you mean by 'traceroute/ping' - notably, 
citing an RFC or other spec on the variant you're using. However, it 
would be important to first make the case that this information is 
relevant for those protocols.

However, why would you then want to limit those protocols to a specific 
UDP or TCP port number? their value is in being used to test various 
port numbers that are blocked (or not) along various paths - e.g., to 
find out that HTTP isn't blocked all the way to a destination, or if so 
on what hop.

Joe

---

From: Naiming Shen <[email-masked]>
Date: Thu, 8 Mar 2012 16:04:00 -0800

Hi Joe,

some replies inline,

On Mar 7, 2012, at 5:29 PM, Joe Touch wrote:

> A ping (ICMP echo request) message has no port. It has an Identifier field that is used "like a port in TCP or UDP to identify a session" [RFC792], but it identifies a session not a protocol. I.e., it should change for subsequent echo requests, so this should not be fixed at a specific value.

Actually the current implementations I have looked, this ID of ICMP echo request
is used to identify a ping process in a multi-threaded system such as linux/bsd. It
is fixed during the session, which the "Sequence number" field changes with each
packet. In this draft, we suggest if the implementation uses this fixed ID in the
ICMP echo-request, the multi-thread process-id information can be moved to the
firest 64 octets, which is reserved for private use.

> 
> Traceroute uses ICMP with varying TTLs, so a port number is equally meaningless there.

For traceroute application, it's the same usage for the ID field as above.

> 
> Sec 5 of this doc redefines how ping works - when it reaches the valid destination, an echo response is sent back. That's how ping knows it works, and how traceroute knows to stop.

That is true. But for udp traceroute stops or udp ping reaches the destination,
it uses the property of either the destination port is not open, or the port is open
but the source address of the udp packet does not match with any of the socket.
Here in this draft is a little different, the port is a well-known, and is intended to
receive this ping or traceroute packet, thus we just emphasis that so there is no
confusion.

> 
> If you intend on using these inside UDP or TCP segments, you need to be much more specific about what you mean by 'traceroute/ping' - notably, citing an RFC or other spec on the variant you're using. However, it would be important to first make the case that this information is relevant for those protocols.

This is only applied to traceroute/ping type of the applications. Although there is no
specific RFCs to cover those applications, we can certainly add more text to describe
them more clearly.

> 
> However, why would you then want to limit those protocols to a specific UDP or TCP port number? their value is in being used to test various port numbers that are blocked (or not) along various paths - e.g., to find out that HTTP isn't blocked all the way to a destination, or if so on what hop.

It's just an option offered by this extension, it's not a must. As mentioned above,
this is for providers to distinguish new services using this extension from the trace
and ping packets of legacy usage.

thanks.
- Naiming

---

From: Joe Touch <[email-masked]>
Date: Thu, 08 Mar 2012 16:10:11 -0800

I remain confused.

ICMP doesn't use ports; it uses IDs, and the ID space is not registered 
by IANA, so there's no meaning to a reserved ICMP echo ID value.

As I noted, there is a specific value - not legacy, but current utility 
- in sending TCP or UDP packets to specific ports to test reachability.

I don't see any value in reserving a port here.

Joe

---

From: Naiming Shen <[email-masked]>
Date: Thu, 8 Mar 2012 19:04:08 -0800

Ok, if IANA does not reserve non-"port" items, we'll remove this from the IANA consideration
section then. By legacy I only meant the default or everyday usage of traceroute or ping.

thanks for the note.

- Naiming

On Mar 8, 2012, at 4:10 PM, Joe Touch wrote:

> I remain confused.
> 
> ICMP doesn't use ports; it uses IDs, and the ID space is not registered by IANA, so there's no meaning to a reserved ICMP echo ID value.
> 
> As I noted, there is a specific value - not legacy, but current utility - in sending TCP or UDP packets to specific ports to test reachability.
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 8 Mar 2012 22:12:24 -0800

IANA reserves many things besides ports, just not ICMP IDs, FYI. 

"Legacy" usually means an old use that may be supported but is no longer common, too. 

Joe