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