Tunnel Trace Draft Comments

[Black_David@emc.com]

Brian Carpenter asked me to take a look at
draft-bonica-tunneltrace-00.txt from a diffserv
standpoint, as I seem the be the designated tunnel
"expert" (or is that "stuckee" :-) ) for diffserv
(see RFC 2983).  I noticed a couple of concerns:

(1) Section 7.7 talks about construction of IP headers
at the head-end of the path, and implicitly about
construction of the IP header for the response message.
A general reference to diffserv (RFC 2474 and 2475)
is in order to point out that the diffserv rules for
use of DSCPs apply and are not changed by anything here.
This shouldn't be a big deal, because I would imagine that
most of the envisioned uses of traceroute would be best
effort, but ...

(2) Diffserv and tunnels is a long story - RFC 2983
contains the details for the curious.  For tunnel
traceroute, there's an important issue lurking in
Section 4.2 of that RFC; the DSCP (Differentiated
Services Code Point) may be involved in tunnel selection.
Typically the tunnels selected among would be in
parallel (same source and destination, different
protocol instances), but that may not always be the
case, and failures that take out part of a set of
parallel tunnels are always possible.

At the moment, I think this DSCP-based tunnel selection
is still in the realm of the hypothetical, but I believe
that both the IPsec and L2TP folks accept using the DSCP as
part of tunnel selection in order to address a desire
for QoS differentiation via reordering of packets within
a tunnel that doesn't like reordering (when suitably
configured, IPsec will complain, and L2TP will undo
the reordering).  In any case, I'll defer to others on
the importance (or lack thereof) of dealing with this.

The concern here is that it may be necessary to tell
the head-end device not only the destination of the
trace packet but also what DSCP should be used in the
header in order to make sure that it goes down the
"right" tunnel.  The usual diffserv approach to this
sort of situation is to signal PHBIDs (see RFC 2836)
in order to deal with the fact that the application
and the head-end device may be in different diffserv
domains.  Given the use of traceroute for operational
diagnostics, I think it's an exception in which it is
ok to signal DSCPs in some circumstances (e.g. to keep
the PHBID to DSCP mapping logic out of the way of
the harried netadmin trying to figure out what on earth
the network did this time).

When DSCPs are signaled, the assumption would be that
the user of the application understands exactly what
s/he is doing (including how DSCPs are used in the
head-end device's diffserv domain).  DSCP signaling
should probably be provided in addition to PHBID
signaling rather than instead of.  Some sort of
identity information will need to be communicated in
both cases in order to determine whether the user
of the application is authorized to launch a
traceroute with the specified DSCP (either provided
or mapped from the provided PHBID) from that head-end
device to avoid some truly nasty DoS attacks.

Just to be clear - I think it could be a reasonable
engineering decision to not address this in the
first go-around (it should be noted as something to
be addressed in the future in that case), but I
want to make sure that the decision to do so
is made consciously and deliberately.  I'm working
with Danny on PHBID signaling for L2TP, which has
a similar need, so some of that text may be reusable.

I also noticed a few non-diffserv concerns:

- In addition to Danny's catch of L2TP, the list of
tunnels in RFC 2667 (IP Tunnel MIB) could be checked
for other candidates to support.

- FWIW, IP in PPP in L2TP in IPsec transport mode is an
example of a complex multi-level tunnel that's in use.
Making sure the design works in this case (notice that
there are 3 protocol headers between the IP headers)
is probably a useful check.

- IPsec's ability to control traffic source and destination
will impact what responses get through when tracing through
an IPsec tunnel.  My impression is that ICMP interaction
with/behavior under IPsec is not all that clean at the moment,
and the same sort of issues will arise here.  I'm not sure
what to do here, but it's at least worth a sentence in
the requirements draft.

- Is there some useful interaction with SNMP security that
would make it easy for an implementation to poke around
in MIBs to figure out whether there's a tunnel and its
configuration?  This may help avoid having the same
configuration information in more than one place.

- I wonder how realistic the round trip delay per component
(6.4) is, given that TTL expiration tends not to be processed
in the fast path of IP routers/switches, and the time consumed
by the slow path may vary greatly from box to box.  Maybe just
note that precise measurement is not a goal, as opposed to
coarse information (e.g., good grief, why'd it take that
long to get from there to there?) to direct further
diagnostic efforts.

- 7.4 Routing Requirements should probably note that consistent
results are not required in the presence of routing instability
because different trace packets may take different routes.
Should anything be done about this?  A cute trick would be
to write the IP address, etc. of the node where the first TTL
expiry occurs into the packet, reset its TTL to 1 and forward.
On second expiry, copy this info into the response along with
info about the node where the second expiry occurred.  The
result is that the response contains the previous IP node
and can be checked against the IP node that sent the previous
response arrived.


Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------