Hi Joe, Thanks for the feedback. Responses are in-line.
On 10/17/07, Joe Touch <[EMAIL PROTECTED]> wrote: > > 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. Done the abstraction should indicate that this document specifies a > particular format using ICMP multi-part messages. Ok - added "using ICMP multi-part messages [RFC4884]" into the abstract. Sec 2 > should indicate that this document specifies a particular format using > the extensions described in RFC4884, and hint at the backward > compatibility issue I've added the ref to RFC4884 - I don't think there's a need to discuss the backward compatibility issue again here. That is nicely covered in RFC4884. 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. I'll change to may send instead of sends. I don't think it is necessary to clarify the cases when ICMP messages may not be received. Those are well-known cases & outside the scope of this draft. It's not promising any more reliability. 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. The cases where the extensions are useful are the cases where the conventional ICMPs have problems. What part of this is not clear in the draft? Where do you have questions? 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. Without these extensions, the receivers won't get the information anyway. I've added a reference to RFC4884 about the backward compatibility issues. "The extensions defined herein use the ICMP multi-part message framework defined in [RFC4884]. The same backward compatibility issues that apply to [RFC4884] apply to these extensions." Sec 3 > replace "support enhancements" to "require enhacements, and provide > additional capability" OK 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) I hear that you are concerned about that. I feel it is quite adequately addressed in RFC4884 and don't think we need to repeat the issues here. I've added several references back to RFC4884, including specifically about the backwards compatibility already. 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. I already refer to RFC4884 at the end of that paragraph. That is where ICMP extension objects are defined. What is obscure here? 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). Why? Why is it necessary to have a MUST? Also, I strongly disagree that if only an IPv4 or IPv6 address is included that a conventional reply MUST be sent. That will not provide the desired information in the case of multiple paths and a different outgoing vs. incoming interface, as is described in the Introduction. 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 ;-) Why is this desirable? Someone who is implementing this will read RFC4884 as well to get the format. I don't see the point in this redundancy. 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) Yes - added. Bits 4 and 5 MUST also be ignored on receipt I have that in the description for the reserved bits. 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). yes - added Are bits 0-5 defined for all values of bits 4-5, or only for values of > 00 and 01? I'm not sure what you mean? Do you mean for bits 7-6? 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. I'm not sure what is confusing about this. It adds the ability to specify additional future interface roles (well, 1 now that I've added the incoming interface - sub-ip member role). 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. The meaning of the bits don't change based on teh interface role. 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. added for the MIB 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... I got rid of the 4-octet alignment in the updated version. I've also changed the limit to 62-bytes. You were the one who suggested a small limit on the length of the ifName. Would you care to supply the reasoning for the draft? I know you were concerned about using up all the space in the min (576) MTU packet. I would be perfectly happy to have it go up to 253 octets. 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). Just because I am defining only these 2 alternatives now doesn't mean that there may not be others in the future. Given that this is human-readable information, having some flexibility for additional languages/charsets seems important. A whole octet does seem like overkill, I agree, but 2 bits isn't quite enough to give real options (and the newly added length must be at least 6 bits). Given that the string wants to start on an octet boundary, 1 octet seems good. Sec 4.3 > show an entire ICMP packet if you can, to put your extension in the > proper context Good idea - done 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. Yes, reduced 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 Cleaned that up so that there is better text " If this extension is included, then an Interface Information Object MUST be included. If the interface in question is unnumbered, then the Interface Information Object SHOULD include the ifIndex and SHOULD NOT include an IP address. If the interface in question is numbered, then the Interface Information Object SHOULD include the IP address. Other fields MAY be included in the Interface Information Object. In an ICMP message, more than one Interface Information Object with a given interface role MUST NOT be included. Multiple Interface Information Objects, each with a different interface role, MAY be included." 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 But not everyone is given access to the MIB or OSPF. That is the issue. - 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 could use suggestions about what the attacks are. This does allow more topology information to be obtained than would otherwise be available. The ifName might indicate details about the types of interfaces, maybe even the vendor. 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. I've improved it and added the rules for when to give out values. Thanks, Alia --- > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/int-area > > >
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
