New Issue Of The ITrace Document

I've sent in draft-ietf-itrace-04.txt.  It contains the following changes:

1.  Based on the thread "Coding Of Public Signature Algorithm Identifier", and
Marcus's suggestion that we can get the algorithm from the site pointed to by the
URL, I've deleted the public key algorithm identifier from the (HMAC) Key Disclosure
element.

This affects the text and figure in section 2.8.3 "Key Disclosure (TYPE=0x86)"
describing the public key identifier.

2.  From the thread "Suggestions for changes to draft-ietf-itrace-03.txt", point 1:
  original point was about placement of the captured packet information, mutated to
suggestion on wording on how much data is to be captured.  Section 2.5 has been
rewritten to use similar wording to RFC 2463 (ICMPv6) sec. 2.4 (c).  While I was at
it, I added references to IPv6 and ICMPv6.

Open issue: is the applicable minimum MTU size dependent on which version of IP the
ICMP Traceback is sent out on, or should we use the more restrictive value (576 octets)?

3.  From the thread "Suggestions for changes to draft-ietf-itrace-03.txt", point 2:
corrected packet header size in section 2.5 to >=20 from >= 24 octets.

4. From the thread "Suggestions for changes to draft-ietf-itrace-03.txt", point 3
(proposal to set a limit on total packet size): covered by the change made as
described in point 2 of this note.

5. From the thread "Suggestions for changes to draft-ietf-itrace-03.txt", point 4
(separate tag sequences for sub-fields instead of globally unique tags): .  I
suggest and have implemented a compromise: tags are globally unique, but
   -- top-level tags occupy the range 0x01 to 0x7f
   -- sub-field tag numbers range from 0x81 to 0xff.
This affects text in section 2.2 as well as tag numbers throughout section 2.

The following text has been added in section 3.3 when speaking of preliminary
validation: "Malformed messages SHOULD be silently discarded."

6. From the thread "Suggestions for changes to draft-ietf-itrace-03.txt", point 5: a
reference has been provided to the RFC 2402 (IPSEC AH) list of mutable fields to be
masked in HMAC hashing.  Minor issue: the rationale for masking fragment offset in
IPv4 doesn't apply to ITrace, but it seems reasonable to mask it out anyway.

7. From the thread "Suggestions for changes to draft-ietf-itrace-03.txt", point 6
(HMAC algorithm identification): no action yet.  If people really want to set up a
new registry to save a byte on HMAC algorithm identification I'll do it.  If the
issue is really the restriction of eligible algorithms, we should probably do that
explicitly in the text.

8. From the thread "Suggestions for changes to draft-ietf-itrace-03.txt", point 7
(TOS for the traceback packets): added text to section 3.1 indicating that the TOS
field should be copied from the traced packet.

9. From the thread "Suggestions for changes to draft-ietf-itrace-03.txt", point 8
(XML page for public key disclosure): reference to XML page modified to point to
draft-ietf-pkix-certstore-http-04.txt, which talks about retrieving certificates
with HTTP GETs.  We can change this back if something significant comes out of Don
Eastlake's presentation at the meeting.  This point was also discussed in Mikael
Olsson's note "Re: comments on draft-ietf-itrace-03", 2/9/2003, where he made
reference to certificates and usage restrictions.  Looking at RFC 3280, the
reference seems to be to section 4.2.1.13 "Extended Key Usage".  It doesn't really
seem necessary to define an OID for Itrace, since there is already one for "any" use
in addition to the limited set of specific ones shown.

10. From the thread "Suggestions for changes to draft-ietf-itrace-03.txt", point 9
(ability to configure receiving host to limit accepted message volume): proposed
text added to section 3.1.2.

11. From the thread "Suggestions for changes to draft-ietf-itrace-03.txt", final
point: examples later.

12. Added a note in section 5 that we have not concluded discussion on the matter of
  question of how quickly a key gets disclosed, and the possibility of flooding
itrace buffers with fake packets that lead nowhere.

13. Added an editor's note to section 2.8.2 pointing out the need to indicate how
many keys have to be disclosed.  This is probably a function of the itrace packet
generation rate and the key change rate.  A reasonable objective is to give a
reference host some probability (e.g. 80%) that if it receives an itrace pacvket it
will also receive a successor disclosing the key.  Working out the reference model
to resolve this may take some discussion.  It may actually turn out to be
impractible, in which case we have to fall back on the schemes people have suggested
for the receiving host to interrogate to learn the key.

14. Removed the second timestamp from the key disclosure.  I assume that there was 
good reason for putting the timestamp at the top level, so that's where I left it. 
Added text in that section making it clear that the timestamp is related to the 
interval of validity of the hash key.

15. Moved the signature out of the individual Key Disclosures into the Public Key 
Information element, which I've renamed "Disclosure Signature".

Re-reading Pekka Savola's original note ("comments on draft-ietf-itrace-03",
1/22/2003), I realized that I confused it with "Suggestions...".  We (or maybe I)
have real work to do to address his comments properly.  Maybe in the next iteration
of the draft.  Just to take the easy stuff, I've fixed the introduction.  I've also
changed all the "tag" instances to "type".  I'd swear I've seen "tag" used, but I 
can't find any examples.

Tom Taylor