Hi, Alia, et al., Below is some feedback to your current draft. Overall, it seems OK, but I have a few areas of suggestions:
- presentation/discussion clarity
especially in relation to RFC4884
and impact on legacy ICMP use
- clarity on when/how to use it
especially what combination of info
requires it, and when not to use it
- some questions/suggestions on bit assignments
including bit format, pattern use,
and IANA instructions
I hope they are useful.
Joe
---------------------------------
Abstract:
at end of "and/or address", it would be useful to add "as already used
in MIBs and by OSPF" -- i.e., you're not creating new, non-IP address
identifiers.
the abstraction should indicate that this document specifies a
particular format using ICMP multi-part messages.
Sec 2
should indicate that this document specifies a particular format using
the extensions described in RFC4884, and hint at the backward
compatibility issue
Sec 2, paragraph 1
replace "it sends" with "it may (and in some cases must) send", and
replace "diagnose network issues" with "diagnose network issues, when
they are not suppressed by rate limiting at routers, blocked by
firewalls, or lost". i.e., it's worth noting that not all messages are
required or may ever show up.
Sec 2 after paragraph with "However..."
The previous paragraphs provide itemized lists of the conditions when
conventional ICMPs are sent. It would be useful to follow this paragraph
with a similar, bulletted list of the conditions when your extension is
needed.
Sec 2 end
be careful with this recommendation - that you can send any/all of
these. your signal relies on an extension that not all receivers will
parse, and when they don't, they won't get the information needed. it's
useful to put that caveat somewhere in here - i.e., this isn't just a
superset of current signalling, due to backward compatibility issues.
Sec 3
replace "support enhancements" to "require enhacements, and provide
additional capability"
add a sentence to this section describing the impact of this extension
on legacy traceroute implementations (I know I asked for that above;
it's worth noting in several specific places)
Sec 4 first paragraph
this paragraph should say "using the ICMP multi-part message extension,
as described in RFC4884"; right now, it's a bit obscure, and implies
that you're creating a new format rather than specifying a value for an
existing format.
Sec 4, list
You have 4 MAYs. You need a sentence that says that at least one of
these MUST be included, and (IMO) that if only one of the first 2 are
included, ICMP MUST send a conventional reply (i.e., MUST NOT send in
your Interface Information Object format).
Sec 4.1
this section jumps in describing a c-type, but you didn't say what it
was yet. it would be useful to put a section before 4.1 (and call it
4.1) that reviews what an ICMP multi-part consists of ;-)
You need to specify current behavior for Interface Role values of 2 and
3 (i.e., MUST NOT be set to those until IANA assigns them, and MUST be
ignored on receipt until IANA assigns them)
Bits 4 and 5 MUST also be ignored on receipt
Is it valid to receive a c-type with bits 0-3 all zero? I'd suggest YES,
and that this MUST NOT generate an error or warning (since, after IANA
assigns the higher bits, all zeroes here may be OK).
Are bits 0-5 defined for all values of bits 4-5, or only for values of
00 and 01?
I'd actually suggest just leaving the Interface Role as bit 4 = input
and bit 5 = output. 00 ought to mean "the router" if desired, and 11
ought to be used for bidirectional interfaces. I don't see why you would
leave undefined values that aren't bit-delineated.
Also, I'd suggest swapping the sub-fields, i.e., make the interface rle
bits 0-1 and let 6-7 be reserved. That allows you to examine MSB and its
neighbor and redefine the entire remainder of the field more easily (it
can be done with bits in the middle, but then you might end up with a
discontiguous field). We can talk on the phone about this more easily
than my writing more on it here, if needed.
Sec 4.2
this should explain why you want to use a MIB-II ifName - i.e., to
cross-correlate with other MIB info, OSPF, etc.
this should also explain why you are doing 4-byte alignment and 32-byte
limits - i.e., is that in 4884 or MIB-II, or did you add that as a new
requirement...
why are you using an entire byte here to indicate the format of the
string? why not use one of your reserved bits, e.g.,:
IF bit 0 is set, then bit 4 indicates whether to use ASCII (b4=0) or
UTF-8 (b4=1).
Sec 4.3
show an entire ICMP packet if you can, to put your extension in the
proper context
I don't think you need 9 examples to get across the point that fields
are optional. Show that in one figure with all fields shown as optional,
and give one example with both adjacent and non-adjacent fields present,
e.g., ifIndex, IPv6, and Interface Name.
Sec 4.4
it would be useful to show how you derived the c-type numbers, i.e, to
list what fields are present in each corresponding valuel
Sec 5
This section needs to be rewritten. The key questions:
- what information might you expose that would be useful to an attacker
I can't see much, and you can explain that this info is already
exposed in MIB-II or OSPF
- what capability might an attacker use against the alleged sender or
intended receiver of the ICMP?
An attacker could effectively disable traffic to an interface
without knowing the IP address of that interface, e.g.
i.e., that's what should be there, vs. what's there right now.
Sec 6
I don't think this section is written as required.
IMO, it should say:
- IANA is requested to allocate a class type for this purpose. (you
should use "IANA-ASSIGNED-CLASS" in the doc where that value will be
used, and ask that it be replaced on assignment)
I don't think IANA is interested in allocating undefined values. They
want a field and rules to decide when to give out a value for that
field, i.e., vendor codes, protocol types, etc. You don't have any of
those here.
---
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
