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

Mikael Olsson wrote:
> 
> 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.
>
I'm not utterly-wedded to the existing format.  What do others think?
 
> 
> 2. Item 2.5 lists complete packet header as >=24 octets.
>    Shouldn't it be >=20 octets?
>
Yup, I think that's a typo.
 
> 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.
>
No harm in adding some explicit constraints.
 
> 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.)
>
I like globally-unique tags, because it means that you can figure out what's going
  on with casual inspection in TCPDUMP.  Certainly, we'll need some words about
  processing procedures, particularly for "out of scope" tags.  But again, I'm not
  religious about the formats--if people who are actually going to IMPLEMENT this
  find problems in the existing formats, then I have no problem tweaking them to
  be more implementation friendly/efficient.
 
> 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.
>
Having explicit wording here is important, so spelling it out like you suggest
  is a MUST.  I think that we can assume that in most cases, the ID field will
  not be mutable.  We should likely take our cue from AH.
 
> 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)
>
I think that we were going to re-use the IPSEC registry for HMAC values.  No reason
  not to.  The current document sets this to two bytes, which is almost certainly
  excessive.  I'll note that the current ipsec registry (pointed to in our
  -03 draft) doesn't set HMAC residue sizes in the registry.  We might want to
  see what IPSEC does here, with the new version of IKE, and use whatever
  registry they establish.


> 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?
>
I think that copying the ToS bits is the only sane thing we can do, given that
  such things are highly subject to local administrative practice.
 
> 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?)
>
We definitely need to define this, and noone has yet stepped up to the plate.
  I think the assumption was that it would be some XML wrapped around an
  X.509 cert, but I'm not an XML guy.
 
> 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.
> 
>   (?)
>
That would be fine with me.
 
> 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 :)
> 
Examples good.  But clearly we have to wait until the spec has settled...

-- 
----------------------------------------------------------------------
Marcus Leech                             Mail:   Dept 8M70, MS 012, FITZ
Advisor                                  Phone: (ESN) 393-9145  +1 613 763 9145
Security Architecture and Planning       Fax:   (ESN) 393-9435  +1 613 763 9435
Nortel Networks                          [email protected]
-----------------Expressed opinions are my own, not my employer's------