Hi, Alia (et al.), Alia Atlas wrote: > Hi Joe, > > Thanks for the feedback. Responses are in-line.
I've replied only to those asking questions... ... > 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? It's an organization issue; you already provide a list of where conventional ICMPs are sent (arguably not necessary, as it's already in 1812 and 1122); it'd be very useful to provide a very compact list of the conditions where your extension is needed as a test, i.e., "match this list, and use this extension". > 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. That's assumed. The problem is that with these extensions, senders can't assume receivers will get the right info either. > 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." I'm suggesting highlighting that this is a two-party problem. ... > 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. 1122 and 1812 also list existing ICMPs. You summarized them in your draft to highlight the list. For similar reasons, there are portions of 4884 that bear repeating in this doc, not just assuming the reader will know because the doc is cited. > 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? maybe replace "described" with "defined"; described implies that you're defining a derivative, where you're really instantiating it (if that makes sense). I think it's clear enough if you say 'defined'. > 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? Because if you don't include any, you don't have a new format. > 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. Ahh - sorry, I missed that point. > 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. Again, it's similar to the reason you're redundant elsewhere. Just because you cite 4884 doesn't mean this shouldn't be reasonably stand-alone to read at first-pass. > 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? Yes. > 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). I noticed that, but don't understand why it's not using a bit elsewhere (i.e., why couldn't that apply to outgoing interfaces too?) > 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. The fields seem even more scrambled. It doesn't make sense to define unused bits in gaps; if you decide to have the bits gather to make a larger field, they'll be unnecessarily obscure. > 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. Is there a limit to ifNames? If so, that's the reason. If not, then the reason is to impinge less on the space used for sending back as much of the packet that caused the problem as possible. > 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. Thinking on it further, the fact that different interfaces could be encoded in different languages seems a good reason to leave this a separate octet, FWIW. ... > 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. And what would you do with that info even if you had it? (see below)... > - 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. Good points to note. Thanks, Joe
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
