Hi Alia,
thanks for the comments.
On Nov 24, 2008, at 8:27 PM, Alia Atlas wrote:
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.
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
mechanism to implement also.
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.
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.
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
Alia
On Mon, Nov 24, 2008 at 11:11 PM, Naiming Shen <[EMAIL PROTECTED]>
wrote:
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
On Nov 24, 2008, at 6:48 PM, Carlos Pignataro wrote:
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.
On 11/24/2008 7:05 PM, Rajiv Asati (rajiva) said the following:
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
--
--Carlos Pignataro.
Escalation RTP - cisco Systems
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
