Subject: [Int-area] feedback on draft-atlas-icmp-unnumbered-03

From: Joe Touch <[email-masked]>
Date: Wed, 17 Oct 2007 08:22:27 -0700

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.

---

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: "Alia Atlas" <[email-masked]>
Date: Wed, 31 Oct 2007 13:31:34 -0400

Hi Joe,

Thanks for the feedback.  Responses are in-line.

>                 including bit format, pattern use,

Done

> particular format using ICMP multi-part messages.

Ok - added "using ICMP multi-part messages [RFC4884]" into the abstract.

Sec 2
> the extensions described in RFC4884, and hint at the backward

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
> 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.

> with a similar, bulletted list of the conditions when your extension is

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
> 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

OK

> 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
> that you're creating a new format rather than specifying a value for an

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
> 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
> 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.

> ignored on receipt until IANA assigns them)

Yes - added.

I have that in the description for the reserved bits.

> assigns the higher bits, all zeroes here may be OK).

yes - added

> 00 and 01?

I'm not sure what you mean?  Do you mean for bits 7-6?

> 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).

> 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
> cross-correlate with other MIB info, OSPF, etc.

added for the MIB

> limits - i.e., is that in 4884 or MIB-II, or did you add that as a new

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.

> IF bit 0 is set, then bit 4 indicates whether to use ASCII (b4=0) or

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

Good idea - done

> e.g., ifIndex, IPv6, and Interface Name.

Yes, reduced

Sec 4.4
> 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
>         exposed in MIB-II or OSPF

But not everyone is given access to the MIB or OSPF.   That is the issue.

>         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.

> field, i.e., vendor codes, protocol types, etc. You don't have any of

I've improved it and added the rules for when to give out values.

Thanks,
Alia

---