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.
-danny
-------
Section 4.1: Interface Role Value 2-3 : "Undefined by this memo and
to be assigned by IANA" I think you mean "Reserved"?
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?
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.
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
"Figure 3" is the only diagram you seem to have labeled and
referenced. Consistency with the others would be useful.
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.
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.
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.
Given that this is Standards Track, perhaps something
besides FCFS for charset type allocation worthwhile?
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?
I'm not sure why you have a reference to RFC 2328 in
the references section?
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..
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?
Why is the interface name Sub-Object limited to 32 octets
total length?
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
