Suggestions for changes to draft-ietf-itrace-03.txt

Tom-PT Taylor wrote:
> 
> Could people please look through this and see what else has to be done
> besides changing the signature algorithm codepoints as agreed yesterday.

1. Two years ago, there seemed to be consensus on building the message
   more according to common ICMP message layout, e.g.:
   - Transport IP header
   - ICMP itrace header
   - IP header of previous datagram, plus 8 IP data octets
   - Tag-length-value scheme, possibly including even more 
     of the original datagram

  The specification now shows the TLV scheme beginning right after
  the ICMP header. - Why? It makes it harder for state tracking
  firewalls to figure out which stream the ICMP message belongs to.
  
  (Yes, I _can_ see the counter argument: firewalls admins are likely
   to simply want to drop these messages and do collection/generation
   outside the firewall... in most cases.)

2. Item 2.5 lists complete packet header as >=24 octets.
   Shouldn't it be >=20 octets?

3. I don't see a note about total message size constraints.
   Has this been dropped, or do we assume that people will understand
   that the default ICMP message size constraints apply?
   
   I think the size should be constrained, and that it should be 
   explicitly mentioned.  For IPv4, this constraint would be 
   576 bytes total (including outer IP header).  I don't know
   if there is a corresponding "natural" value in IPv6.


4. As a programmer, I don't like the fact that the tag numbers are
   globally unique, even though some of them must occur inside
   other tags.  This creates confusion.  What if I find a 0x03,
   "Interface name" at the top level?  Should I attempt to parse 
   it, or should I simply ignore it?

   I can see how some people would find it tempting to write a 
   single tag identifier/parser function and apply it to _all_
   tag parsing, regardless of it parsing the top level or inside
   another tag. This is not a good thing.
 
   I'd like to see separate lists of tag numbers, which begin anew
   at 0x01 inside tags.

   (Yes, I know that this is "implementation", not "specification", a 
    distinction that designers tend to point out as soon as debates 
    like these crop up.  However, I would again like to draw your 
    attention to the ASN.1 parsing global fiasco.)


5. Item 2.8.1: "HMAC Authentication Data".
   This item talks very vaguely about "mutable fields" without 
   specifying what these fields are.
   I submit that we need to specifically identify these fields.

   I suggest we copy IPsec AH's list:
   - Entire Type of Service octet; this can get changed by 
     traffic shapers en route (and ECN too, right?)
   - Time to live
   - Flags/frag offset: both octets
     There is ONE reserved bit here, which we have no way of knowing
     how it will be used. We mute it.
   - Header checksum (obviously)

   However, we may also want to mute the ID field, in case something
   along the lines of [SWKA00] is ever put into operation - maybe for
   an entirely different purpose than packet tracing.

   No, this doesn't leave much of the header intact. Maybe one would
   just be better off including a TCP/UDP pseudo header in the HMAC
   and stay clear of the actual IP header :)

   Note that I have no idea what needs to be muted in IPv6. Maybe
   copying IPsec AH's mutable lists is simply the way to go.


6. Item 2.8.1 again.
   I assume that the HMAC codepoint spec will also use a separate 
   registry, and be a single octet in size?

   My personal preference of a registry:
   0x00 HMAC-SHA1-128
        (Output truncated. Why? See section 5, "Truncated output" 
         of http://www.ietf.org/rfc/rfc2104.txt)

   But I guess I could live with also having
   0x01 HMAC-MD5
   even though MD5 has been shown to be weaker than originally
   believed. (This is also discussed in depth in rfc2104)


7. What ToS/precedence do we use for the generated tracebacks?
   It's tempting to set it to one higher than the traced packet, but
   with the fuzzy wording about diffserv codepoints being admin-
   defined inside an administrative domain, this may or may not be 
   a good idea. (Most people tend to assume that higher value == 
   higher precedence, though?)

   I don't think we ever reached consencus on this last time it 
   came up.  Maybe we should just copy the ToS octet from the
   original datagram and be done with it?


8. Item 2.8.4: "Public-key Information"
   "This element contains a URL, pointing to an XML page that contains
    the public key used to sign key-disclosure elements."
   How would this XML page be constructed?  (Is there some standard
   for this that I'm simply not aware of?)

9. Item 3.1.2: "Implementation Requirements -- Message Reception"
   Maybe we should add something like:
     Hosts SHOULD also be designed so that the operator can limit the
     rate at which the host accepts ICMP TRACEBACK messages.  
     Messages exceeding this rate would be silently dropped.
     If such functionality is implemented, the host SHOULD provide
     a counter displaying how many messages have been dropped.

  (?)

10. Finally, a few example tracebacks wouldn't hurt, but I can see
    how you might want to put that off until the spec has stabilized :)


-- 
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com