Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt

["Rajiv Asati (rajiva)" <[e-mail]>]

> > False assumption. The reason why *any* packet (i.e., any src/dest
> > address) would be used is precisely to debug problems related to
> > traffic between a particular src/dest pair, and that src/dest pair
may
> > not even belong to the ISP that gets a help desk call.

Is it really possible? 
I am not aware of any implementation that allows the source address of
the ping/traceroute packet to be any arbitrary number.
In fact, Most implementations limit the source address to be one of
those assigned to the device itself.

The point here is that if the helpdesk needs additional information from
their network devices during troubleshooting, then this proposal could
be useful.

Cheers,
Rajiv

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
Behalf
> Of Naiming Shen (naiming)
> Sent: Thursday, January 05, 2012 12:36 AM
> To: Thomas Narten
> Cc: Carlos Pignataro (cpignata); [e-mail]; Ronald Bonica
> Subject: Re: [Int-area] I-D Action:
draft-shen-traceroute-ping-ext-03.txt
> 
> 
> On Jan 4, 2012, at 4:24 PM, Thomas Narten wrote:
> 
> > Naiming Shen <[e-mail]> writes:
> >>> Consequently, use of this technique may actually cause collateral
> >>> damage to existing, deployed applications. Maybe not a big risk,
but a
> >>> risk nonetheless.
> >
> >> This draft actually does not change those attributes. The current
> >> traceroute/ping application has already picked up those high port
> >> numbers, and already has used the source port and id field for some
> >> private number no one else cares. Let's say if this draft is using
a
> >> fixed location scheme, then there is no change to any of that.
> >
> > This draft doesn't introduce the problem, but it will likely make it
> > worse. I.e., if this draft is successful (which presumably is the
> > goal), more collateral damage may result. I.e, the more such packets
> > are generated, the more likely some will cause problems.
> 
> But the popular traceroute application is using a > 32K port#, so
those
> are not well-known ports, not used by well-known applications. In the
case
> of someone is using those ports (by destination), then the socket
addresses will
> not match,
> the receiver will send an different icmp error code back(instead of
port
> unreachable),
> those are the existing implementations, and works fine. this draft
does not
> change
> any of those, and unlikely causing problems.
> 
> 
> >
> >> Let's say if I'm using this extension in an particular ISP only
meant to get
> >> some private info for our management stations. First I think the
operator
> >> usually specify the destination to be within the range of the
network they
> >> want;
> >
> > False assumption. The reason why *any* packet (i.e., any src/dest
> > address) would be used is precisely to debug problems related to
> > traffic between a particular src/dest pair, and that src/dest pair
may
> > not even belong to the ISP that gets a help desk call.
> >
> 
> But we are just using exact the same traceroute/ping packets, only
with
> payload
> change with addition information. it's not going to affect any
> source/destination
> address or layer4 ports (those layer 4 ports are designed to be
incremented
> each
> additional ttl packets and they are random anyway) comparing to the
existing
> way.
> 
> > I.e., if you get a help desk call about some sort of packet loss or
> > unreachability for certain flows, you then generate trace packets
that
> > mimic those flows. If we could just use regular packets to debug
such
> > problems, we wouldn't need the proposed mechanism at all.
> >
> >> secondly, even if not, the packet actually goes off the network,
there
> >> is not much harm done, those off-net stations should not supply
those
> >> private information or they probably don't care.
> >
> > My concern isn't about the *response* messages leaking outside of
the
> > site, it's that the *probe* packets will leak. Those are the ones
that
> > could be delivered to a destination incorrectly, causing problems
for
> > the receiving application.
> 
> what I'm saying is, saying the probe is going outside the
network(off-net),
> it's just a ping packet, or a traceroute packet. yes it has some
request in the
> payload, but the receiver does not have to reply. it's like when I
send a SNMP
> query, but typed the host address wrong, the host can either not send
me back
> anything, or it can reply also if it does not really care who query
this
> information.
> but that is not a problem.
> 
> thanks.
> - Naiming
> 
> 
> >
> > Thomas
> >
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area