On Jul 25, 2007, at 11:51 AM, Mark Townsley wrote:
>
> Please also give us feedback on whether or not this document should
> be published, and on what track. I am considering the Standards
> Track, shepherded directly by either me or Jari.
I also believe Standards Track is appropriate.
I do have a couple of comments rather random comments
for the Alia and the rest of the authors.
I like random comments. Thanks!
-danny
-------
Section 4.1: Interface Role Value 2-3 : "Undefined by this memo and
to be assigned by IANA" I think you mean "Reserved"?
yes - fixed
Bits 4 & 5 of the Interface Information Object you say they MUST
be set to zero. Why not SHOULD be, this will provide more flexibility
with deployment of new functions that might employ those bits?
This wants to be MUST, but I will add the MUST be ignored on receipt as well.
In section 4 item "4." you say an interface name string of no more
than 31 bytes may be included. In section 4.2 you say the interface
name Sub-Object must have a length that is a multiple of 4 bytes and
MUST NOT exceed 32 bytes. Clarifying that a one octet "charset
type" is required, and that the entire field be aligned on 32-bit
boundaries, with trailing zero padding if necessary, would perhaps
remove any confusion.
Sure - changed to
"The Interface Name Sub-Object MUST have a length that is a multiple of 4 bytes and MUST
NOT exceed 32 octets. A one octet "charset type" is required and the
interface name can be at most 31 octets long. The sub-object MUST be
aligned on 32-bit boundaries; the string should be padded with zeroes
as necessary."
Also, your use of "An interface name string" may introduce
confusion, you might consider rewording section 4 bullet
4. to something like this:
4. An Interface Name Sub-Object, a string of no more than
31 bytes, MAY be included
yes - changed to
" An Interface Name Sub-Object, containing a string of no more
than 31 octets, MAY be included."
"Figure 3" is the only diagram you seem to have labeled and
referenced. Consistency with the others would be useful.
fixed
In the Security Considerations section tightening up the use
of "destination IP address" is important. You should be very
clear about the ICMP message destination IP address versus
the triggering packets destination IP address. Also, I think the
example should be that interface names and ifIndex values
should NOT be available outside of the local administrative
domain, while the IPv4 addresses may be.
Ok - do you think the policy should be based upon the triggering packet's
destination address or on the ICMP message's destination address? I was assuming
that they were the same; if not, then shouldn't it be based on where the information
is being sent?
I can certainly use help thinking through the security concerns.
By default, you are suggesting that the example not provide more information
than is currently available? I'm ok with that, given it is policy knobs. Done
Also, the fact that this could be used to identify egress
interfaces that may have drop by policy on ingress
(e.g., Dest Unreah, Admin Prohibit) should be strongly
considered, both from a descriptive and IP address
perspective. I could see this information being exploit
for reconnaissance and other activities.
Ok - what would you suggest doing here? Should some
policy be explicitly recommended? I believe it's already clear
in the draft that policy can override providing information as
desired.
Providing a few tables for each object in the IANA
considerations section might make things more clear.
I'd tighten up the wording around the Interface Name
Sub-Object bits 4 & 5 as well, as mentioned above.
Same for values 2 & 3 if Interface role.
Changed to lists - as for tightening up the wording, I'll
address that in response to the rest of that thread
Given that this is Standards Track, perhaps something
besides FCFS for charset type allocation worthwhile?
Ok - I've divided it into two ranges - up through 127 requires
standards action and 128-255 is FCFS.
I also have some concerns about there only being two
RSVD bits for included information, I suspect we could
very quickly exhaust that. Any thoughts there? I realize
we're bounded by C-Type Object subtype bit some other
encoding might be useful here?
With Carlos's change, we have 3 RSVD bits now. If/when it
becomes necessary, one of those bits could indicate the presence
of a sub-object with more bit indicators. What other pieces of
information do you think might want to be included?
I'm not sure why you have a reference to RFC 2328 in
the references section?
That's old and removed now - it was to indicate that an ifIndex is
used in IP protocols to indicate an unnumbered interface.
A general application of this as well may be to identify which
egress interface triggered a given function for the original
datagram. For example, if an ACL drops the packet and
Dest Unreac/Admin Pro denies the packet, being able to
identify that might be useful.. Another example there would
be that of P MTU, to identify which egress interface can't
support a given MTU size - or to obtain a bit of intelligence
data from a given router on that front. If you thought of
such an implementation on a firewall, for example, you
might drop and even provide corresponding policy numbers
on a trusted side, and nothing on an untrusted side, etc..
Oh - those are interesting uses - and completely orthogonal to
what I've been thinking about.
Do you mind if I move some of this text into the draft? Would you like
to draft up something more organized/defined?
It sounds like the ability to report back the MTU might be useful -
as well, potentially, as policy numbers or opaque-ish data.
A question is whether anyone would use those abilities now or whether
that should be handled later when there is interest.
Your text here:
Included Information: This 6-bit field [0:5] indicates what
information is included in the object. The
information must be included in the same order
as the bits (from highest to lowest).
Might be better clarified by either using highest-order or
"leftmost", as opposed to "from highest to lowest". Also,
why do you have this constraint?
I have this constraint because the Interface Name Sub-Object
doesn't have a length field. It is terminated by the end of the packet.
It also gives a defined order, which may be easier for parsing.
I have changed this to:
" Included Information: This 6-bit field [0:5] indicates what
information is included in the object. The
information must be included in the same order
as the bits (leftmost, from highest, 5, to
lowest, 0,)."
Why is the interface name Sub-Object limited to 32 octets
total length?
