Subject: [Int-area] draft-shen-udp-traceroute-ext - Discussion

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 24 Nov 2008 19:05:54 -0500

When this draft-shen-udp-traceroute-ext was presented last week during
the int-area meeting, there seems to be a consensus about the problem
that the draft was solving, however, there was a minor concern about the
solution.

	Specifically, the concern was that using last 4 bits in the
	UDP src port# will result in varying the src port#, hence, 
	traceroute probe may not really test the actual path (if 
	multiple paths exist) that the application traffic may take.

Well, this concern shouldn't really exist wrt the proposal, since the
current UDP traceroute implementation mandates varying the UDP source
port# (as well as dest port#) with every probe anyway. In other words,
the path that the UDP traceroute packet takes will vary with every probe
anyway. 

	So, the port hashing, NAT etc. related points should not be 
	related to this proposal.  

So, this proposal preseves the current UDP traceroute behavior and
doesn't make it any better or worse from the forwarding perspective. Of
course, the proposal is advantageous since it makes the delivery of ICMP
related info selective and a bit secured.
	
Would welcome your feedback.

Cheers,
Rajiv
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Naiming Shen <[email-masked]>
Date: Mon, 24 Nov 2008 17:00:44 -0800

> 	multiple paths exist) that the application traffic may take.

If the application, uses this draft, assuming the higher than 4 bits
is the PID of the process, and last 4 bits is the offset. Then both
numbers don't change, thus the hashing results will still stay the same.
No difference from using just the PID in src port# in the current scheme.

If we are talking about trace from two different routers/hosts, then
even the PID might be different in the current scheme. So basically
there is no change in this regard(multipath).

thanks.
- Naiming

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 24 Nov 2008 21:48:50 -0500

Thanks, Rajiv ! To add to this, from listening to the int-area session
on streaming:

As background, existing udp-based traceroute uses the source udp port to
identify the traceroute invocation instance (by using the process ID
plus high bit set ((getpid() & 0xffff) | 0x8000)) to allow for multiple
simultaneous traceroutes from the same host), and the destination port
increasing per-probe to identify the probe.
Existing traceroute, as well udp-based application traffic expiring
mid-stream can (currently) trigger generation of ICMP timeexceeded
containing ICMP extensions.

One design goal of the proposal in draft-shen-udp-traceroute-ext is to
have minimum incremental additions/differences (to maximize backwards
compatibility) from Van Jacobson's traceroute, and to allow for easy
host implementations over traceroute-nanog/tracesroute/etc.

Regarding the (paraphrased) comments:

	what if a real UDP-based app time-exceeds in transit?

That's what happens now, and it's actually one of the concerns the I-D
tries to solve. Current rules regarding what icmp multipart extension to
include (e.g., unnumbered interface info, incoming MPLS header or IP NH)
can be dependent upon policies based on addresses (source address, etc)
and not based on info contained on the probe as an authenticated request.

	What about ECMP hashing on source UDP port? Is this UDP probes
	being sent all over?

Unchanged from the current udp-based traceroute. What changes is that
routers can check the probe for auth and extension requests.

	What about using the Ident field in the IP header instead of
	source port?

I think it's a nice idea ! It makes for a solution for all transports,
but the implication of using only df=1 probes might be too constraining?

Thanks,

--Carlos.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Naiming Shen <[email-masked]>
Date: Mon, 24 Nov 2008 20:11:11 -0800

Hi Carlos,

One comment about the using IP header ID field suggestion.
I think this draft uses this src port# of udp for a couple of reasons,

- this is not a routing problem as such, it's a traceroute  
application issue,
    so the udp header would be more appropriate in this case. the  
application
    is only stuff the udp header and relies on the underline ip  
infrastructure to
    handle the ip portion, better for layering. we don't violate the  
layering.
    we want to keep the traceroute mechanism the same.
- this is not just for ipv4, and it would be for ipv6 too.
- this issue is only for UDP, the most popular traceroute  
implementation.
   the others, such as ICMP, TCP can easily extend things. But not  
UDP. UDP
   header is not extensible. The other transport can also use the same
   traceroute structures, TLVs, but they have little to do with this  
ori-len
   mechanism described here. They can easily develop their own schemes.

thanks.
- Naiming

---

From: "Alia Atlas" <[email-masked]>
Date: Mon, 24 Nov 2008 23:27:53 -0500

Hi Rajiv, Naiming, Carlos,

As I said in the meeting, I agree that it would be desirable to have a
mechanism that allows for easier
verification of the triggering packet's source as acceptable to receive the
desired set of information.

However, this draft suggests doing it in such a way that doesn't really work
well for determining what's
happening on a particular application's path of interest.

A large point of the extensions being proposed is to help identify the
particular path (when unnumbered,
LAG, ECMP, etc.) can apply.  By having the authentication tied into the UDP
port, there are now paths
that are harder to trace - and it doesn't fully solve the authentication
problem - it just provides another
mechanism to implement also.

I'd prefer to see something that can provide authentication for the
traceroute TCP case and, if possible,
for the UDP case without touching hashed fields as well.

If there is going to be a standard mechanism to indicate authorization,
let's get it defined as a common one
and one that can be used to trace what path a given application will take,
understanding that an application
could be TCP, UDP, etc.

Alia

On Mon, Nov 24, 2008 at 11:11 PM, Naiming Shen <[email-masked]> wrote:

> - this is not a routing problem as such, it's a traceroute application
> issue,
>   so the udp header would be more appropriate in this case. the application
> - this issue is only for UDP, the most popular traceroute implementation.
>  the others, such as ICMP, TCP can easily extend things. But not UDP. UDP
>  traceroute structures, TLVs, but they have little to do with this ori-len

---

From: Naiming Shen <[email-masked]>
Date: Mon, 24 Nov 2008 21:07:28 -0800

Hi Alia,

thanks for the comments.

On Nov 24, 2008, at 8:27 PM, Alia Atlas wrote:

> As I said in the meeting, I agree that it would be desirable to  
> have a mechanism that allows for easier
> verification of the triggering packet's source as acceptable to  
> receive the desired set of information.
>
> However, this draft suggests doing it in such a way that doesn't  
> really work well for determining what's

This mechanism does not change any path of interest attributes.

>
>
> A large point of the extensions being proposed is to help identify  
> the particular path (when unnumbered,
> LAG, ECMP, etc.) can apply.  By having the authentication tied into  
> the UDP port, there are now paths
> that are harder to trace - and it doesn't fully solve the  
> authentication problem - it just provides another

Authentication problem is orthogonal to the multiple path trace issue.

Unlike MPLS traceroute, which uses the complicated DSMAP to direct  
the 127.x.x.x packet to specific
path, normal IP/IPv6 traceroute does not have such a mechanism, and  
this draft does not try to fix this
problem.

As I mentioned in my previous email, before,  the UDP source port is  
mainly a PID#, with this extension,
it's now (PID# | offset), and both numbers are fixed on a router.  
Thus the source port# is a fixed value.
It will not change during the traceroute operation. So there is no  
difference between the current scheme
and the proposed scheme. Actually for traceroute, the UDP dest port#  
keeps changing, so if you are
worrying about hashing to a different path, the current mechanism  
will give you the random paths
during traceroute operation already. Again this draft does not  
attempt to fix this issue.

> for the UDP case without touching hashed fields as well.

UDP based is the most popular implementation. If we want to have TCP,  
we can extend TCP to use the
same traceroute structure defined in this draft. But mainly this  
draft is to define a mechanism for UDP
probes, and since UDP header is not extensible, thus it needs special  
scheme. TCP or ICMP probe can
be easily developed base on this draft.

>
>
> If there is going to be a standard mechanism to indicate  
> authorization, let's get it defined as a common one
> and one that can be used to trace what path a given application  
> will take, understanding that an application
> could be TCP, UDP, etc.

We can clearly define a transport independent port of the traceroute  
structure in next version of this draft,
and also define the UDP scheme in this draft as a separate section.  
Will that work?

thanks.
- Naiming

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 25 Nov 2008 08:32:24 +0100

Rajiv,

> 	multiple paths exist) that the application traffic may take.

The solution used for Paris traceroute (changing the checksum instead of
changing the last 4 bits of the src port) could be applicable as well.
See http://www.paris-traceroute.net/ and
http://www.imconf.net/imc-2006/papers/p15-augustin.pdf

Olivier

-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Naiming Shen <[email-masked]>
Date: Mon, 24 Nov 2008 23:42:51 -0800

Olivier,

> http://www.imconf.net/imc-2006/papers/p15-augustin.pdf

That was only applied to ICMP type probe and hoping the router  
hashing algorithm
was blindly taking the 32bits "port" value for hashing. And this is  
only used for
changing the alternative paths(hoping to). This draft uses this 4bits  
of src-port#
with a different purpose, which is to use as a new structure offset  
in the packet.

thanks.
- Naiming

---

From: Joe Touch <[email-masked]>
Date: Tue, 25 Nov 2008 09:09:36 -0800

Carlos Pignataro wrote:
...
> but the implication of using only df=1 probes might be too constraining?

There are numerous problems with this approach.

1) the ID field cannot be assumed for IPv6

2) under current rules, the ID field cannot be repeated for 2MSL (RFC791)
	how do you ensure that your fragment ID generator avoids
	values used for UDP traceroutes?

3) there is a proposed change to 791 that would deprecate the use of the
ID field if the packet cannot fragment
(draft-touch-intarea-ipv4-unique-id-00)

Can we please stop overloading the value of header fields?

Jo

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 25 Nov 2008 14:47:39 -0500

Hi Olivier,

The paris traceroute implementation is intersting. 

However, to use the UDP checksum field (instead of src port) to convey
the offset value (per our proposal) may consideriably increase the
complexity. The reason is that it will require reverse engineering
(after all, checksum is calculated after the payload is in place, not
the other way around) and require stuffing/padding data in the UDP
payload. 

Wrt TCPtraceroute, using a TCP option for conveying the offset value is
much easier than reusing the seq# (as it is done in paris traceroute)
for our purpose. 

Cheers,
Rajiv

> -----Original Message-----
> From: Olivier Bonaventure [mailto:[email-masked]]
> Sent: Tuesday, November 25, 2008 2:32 AM
> To: Rajiv Asati (rajiva)
> Cc: [email-masked]; Enke Chen (enkechen)
> Subject: Re: [Int-area] draft-shen-udp-traceroute-ext - Discussion
> 
> Rajiv,
>