On Oct 2, 2007, at 1:03 PM, Alia Atlas wrote:
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?
Yes, I think that's my biggest concern.
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
Yes.
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.
I was referring as much to another use case where detailed
information may be provided to ICMP destinations within the
local administrative domain, while only traditional information
be provided to 'external' or untrusted ICMP destinations.
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?
This is fine with me.
Do you mind if I move some of this text into the draft?
Feel free to use whatever you like there.
I am certainly happy to make it larger, but I think some bound is
desirable.
What do you think?
Perhaps some text guiding the sending application around
this area is important. E.g., the sending device might need to
truncate XYZ in order to include other bits in the message. Is
there a way to simply leave this up to the sender? Encode a
length field, or something?
-danny
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
