comments on draft-ietf-itrace-03

Hello,

A few quickie comments on the draft.

10,000ft view:

* Is it possible to implement iTrace without any cryptographic parts at
all (except perhaps on packets selection using e.g. LCPRNG's)?  If so, is
the approach feasible and should the spec be split in two?

My worry is that cryptography support seems to add a lot of weight and
complexity to the protocol, for questionable benefit.  TTL in itself 
should provide quite a bit of useful, not-so-easy-to-spoof information for 
victims listening to iTrace.

I would like to see something like iTrace deployed soon .. the simpler the 
better .. and I don't think the cryptography parts would be useful for 
more than a tiny fragment of people (at least at first).

* a few different prosals (draft-savola-ipv6-rh-ha-sec-03, 
draft-savola-v6ops-6to4-security-01, particularly the latter) has flashed 
out a possibility to enhance (or use a simpler version of) iTrace to make 
it able to cope with certain kinds of reflector attacks, like abusing 6to4 
relays or 6to4 routers.  In those scenarios, possibly specialized 
backward/forward link elements would be needed as such automatic tunneling 
mechanisms do not necessarily have a backward/forward peer of the same 
address family.

I wonder whether others have given any thought to ideas like this.

...

Substantial:

           * the source and destination IP addresses of the Generator and
              its peer.   These are encoded in an IPv4 or IPv6 Address
              Pair element.

==> typically it is not possible to obtain the IP address of one's peer, 
unless the links are explicitly configured as point-to-point and you use 
2*/32 or 2*/128 (IPv6) addressing.


              On LANs, the association string is constructed by
              concatenating the source and destination MAC addresses of
              the two interfaces to the link, and is encoded in a MAC
              Address Pair element.  If there are no such addresses (say,
              for a point-to-point link), a suitable string MUST be
              provisioned in both routers; this is encoded in an Operator-
              Defined Link Identifier element.


==> I believe some more types, besides Ethernet, should also be defined 
before shipping the spec, because this is typically usable in backbone 
where *Ethernet is not that commonplace.

   2.3.4 IPV4 address pair (TAG=0x04)

      This element contains two 4-octet IPV4 addresses of the ends of the
      corresponding link; hence the LENGTH field is always 0x0008.  As
      noted above, the addresses MUST always be presented in the order of
      their traversal by the traced packet.

==> what about unnumbered interfaces, which have no address?  (Or in IPv6, 
have only a limited-scope address.)

   2.5 Traced packet (TAG=0x09)

      This element provides the contents of the traced packet, as much as
      can reasonably fit, subject to link and router resource constraints.
      This element MUST be present at the top level within the TRACEBACK
      message, and MUST contain at least the IP header and the first 64
      bits of the body of the traced packet.

==> a lot of problems e.g. for PMTUD are caused by the fact that many 
vendors have (or still do) send only 8 additional bytes of data, as that 
is not usually enough to distinguish the traced packet.  This 
recommendation could perhaps be raised (with a caveat that if packet is 
short, no extra data would be returned :-).

   2.8 Authentication data

==> this section does not seem to take a stance whether this 
MAY/SHOULD/... be included.

           * timestamp of the time at which the hash was taken, NTP
              format (eight octets)

==> is the time difference between receiving the packet (another NTP 
timestamp!) and hashing the packet expected to be significant enough to 
justify this?  I guess there could be "manual iTracing" where so, but I 
fail to see the usability of that approach.

     The public-key information element can be used to discover the
      appropriate public keys, and other related information.
      This element contains a URL, pointing to an XML page that contains
      the public key used to sign key-disclosure elements.

==> is this kind of XML referral commonplace in security architectures?  
I've never come across that myself..

Editorial:

      We propose an ICMP [RFC792] Traceback message to help solve this
      problem.  When forwarding packets, routers can, with a low
      probability, generate a Traceback message that is sent along to the
      destination.

==> s/destination/destination or source/ (the introduction was not 
updated, it seems)

   1.2 Definitions

      Element: a component of the proposed message which is explicitly
      identified by a tag, and is encoded using a Tag-Length-Value (TLV)

==> I've always seen it spelled out Type-Length-Value, but I guess that's 
ok too..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings