Hi Mary,
Responses inline. I've edited out sections that I think we have
closure on.
On Jun 8, 2009, at 1:55 PM, Mary Barnes wrote:
[...]
-- Section 6.2, value list:
-- In my previous review, I was confused as to the relationship
between
the geodetic/civic and LoBV/LoBR choices. I think it's worth some
clarification in this section that geodetic and civic imply LoBV.
[MB] Okay, how about the following:
OLD:
geodetic: The LIS SHOULD return a geodetic location for the Target.
civic: The LIS SHOULD return a civic address for the Target.
NEW:
geodetic: The LIS SHOULD return a location by value in the form
of a
geodetic location for the Target.
civic: The LIS SHOULD return a location by value in the form of
a civic address for the Target.
Thanks, that helps.
-- section 9.3, 5th paragraph: "A temporary spoofing of IP address
could
mean that a device could request a Location Object or Location URI
that
would result in another Device's location."
It might be worth clarifying that (if I understand correctly) that
this
is more than a spoofing attack, in that the attacker must not only
spoof
its source address, but must be able to receive packets sent to the
spoofed address?
[MB] That statement was intended to include both those items, I'd
propose to clarify as follows:
NEW:
A temporary spoofing of IP address could mean that a device could
request a Location Object or Location URI that would result in
receiving
another Device's location if the attacker is able to receive packets
sent to the spoofed address.
Thanks, that helps.
-- same paragraph: "... re-use of the Device's
IP address could result in another Device receiving the original
Device's location rather than its own location."
It seems like this problem is pretty unlikely to occur by _accident_
when HELD is used over TCP (the only binding right now), right? And
certain not to happen over TLS? Might be worth a "mitigating" mention.
[MB] Certainly, it is fairly unlikely (if not impossible in most
situations), but the recommendations in the bullet points further
reduce
the potential for problems in the off chance that this occurs. It's
not
entirely clear to me why you suggest this is certain not to happen
over
TLS since this is talking about a device that has dropped and thus the
connection would drop and it would seem there's a window for another
device (although quite unlikely) to use that same IP address. But,
perhaps, qualifying the statement as follows would address your
concern:
OLD:
These exposures are limited by the following:
NEW:
While these situations are fairly unlikely to occur (in particular
with the use of TCP/TLS), the exposures can be further limited by the
following:
On reflection, it's probably better to err on the side of caution
here, rather than try to dilute the warning. I withdraw my comment,
and think the original text is fine here. Sorry for the flip-flop.
Thanks!
Ben.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf