RE: tuneltrace

[Ron Bonica <rbonica@mci.net>]

Dave,

I agree about retaining the functionality. I also agree about adding
security.

The question is, do we want to provide this functionality using IP Options,
or do we want to build it into the application layer?

Comments?

                            Ron


> -----Original Message-----
> From: David Meyer [mailto:dmm@cisco.com]
> Sent: Friday, December 29, 2000 4:43 PM
> To: Randy Bush
> Cc: Ron Bonica; tun-trace@ops.ietf.org
> Subject: Re: tuneltrace
>
>
>
> 	Ron,
>
> 	Randy is correct on lsr traceroute. It would
> 	be desirable to retain this functionality if
> 	possible (better would be to enhance it by
> 	providing some form of weak security if possible).
>
> 	Dave
>
> According to Randy Bush:
> >
> > >> Section 5, doesn't loose source trace allow you to do
> > >> third party traces, or am I missing something?
> > > You have a point. I will strike the last two paragraphs
> > > from section five, but replace them with two paragraphs that
> > > point out the problems that loose source routing introduce.
> > >
> > > Will also add a new protocol requirement that prevents us from
> > > using loose source route, strict source route, or record route
> > > IP Options in our protocol design.
> >
> > fyi, in the non-tunneled world, operators like lsr traceroute a
> > lot, sufficiently so that some of us require on at least the
> > borders it in peering contracts.
> >
> > essentially, it allows my noc to diagnose a problem with a peer's
> > routing toward us without having to coordinate with the peer's noc.
> > it provides a simple keyboard check in place of a complex inter-
> > organizational negotiated transaction.
> >
> > randy
> >
> >
>
>