On 9/30/07, Danny McPherson <[EMAIL PROTECTED]> wrote:
>
>
> 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?
>
In the first versions, I didn't have this constraint. I heard concern from
Joe Touch that
the extension would use up too many of the bytes in the ICMP message,
which is constrainted to be no more than 576 bytes.
I am certainly happy to make it larger, but I think some bound is desirable.
What do you think?
Thanks for the helpful comments,
Alia
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
