On Tuesday, January 30, 2007 08:26:01 PM +0100 Christian Vogt
<chvogt@xxxxxxxxx> wrote:
This should probably be rephrased to:
This UPDATE packet is acknowledged by the peer. For reliability in
the presence of packet loss, the UPDATE packet is retransmitted in
case
no acknowledgment is received within the period of a retransmission
timeout.
Ah, OK. Yes, that makes sense.
=====
Section 3.3.2: Credit-Based Authorization
2. An attacker can always cause unamplified flooding by sending
packets to its victim directly.
This is frequently untrue. The network may be configured such that the
attacker does not have direct connectivity to a victim, such as when the
victim is inside a firewall and the attack is carried out via a host
within within a "DMZ".
I assume that you mean the attacker itself is located somewhere in the
Internet, the correspondent node being tricked into sending flooding
packets sits inside the DMZ, and the flooding packets are directed to a
victim in the internal network -- is this correct?
Yes.
In this case, wouldn't the flooding packets be dropped by the firewall
between the DMZ and the internal network because a node in the DMZ is not
allowed to contact a node in the intranet?
firewall firewall
| |
intranet | DMZ | Internet
~~~~~~~~ | ~~~ | ~~~~~~~~
| |
victim |X<-- correspondent <----- attacker
| node |
No. In one common configuration, the difference between the DMZ and the
internet at large is that nodes in the DMZ _are_ allowed to contact nodes
in the intranet.
On the other hand, if no firewall exists between the correspondent node
and the victim, then the attacker could trick the correspondent node into
flooding the victim with unrequested packets. Yet in this case,
unamplified flooding would also be possible for the attacker without HIP
because the attacker could send flooding packets with an IPv6 Routing
header, directing the packets to the correspondent node first, and from
there to the victim. To prevent this attack, the firewall would have to
look into the flooding packets' extension headers since the IPv6 header
would (legitimately) include the correspondent node's IP address.
Hrm. That assumes the correspondent node is willing to route the traffic,
and that the firewall doesn't inspect extension headers. I don't know how
realistic those assumptions are, but I'm not sure it matters. The key
thing is that avenues for unamplified flooding are common enough that
adding one more isn't going to make much difference.
In any case, the above statement from the draft, which you are referring
to, should be rephrased to the following:
2. An attacker can always cause unamplified flooding by sending
itself packets to its victim, either directly addressing the
victim in the packets, or guiding the packets along a specific
path by means of an IPv6 Routing header.
s/can always/can often/ ?
=====
Section 4.2: Locator Type and Locator
Are locator types critical? What happens when a host tries to add or
move to a locator which is not supported by its peer?
We chose to limit this protocol specification to locators of type 1 (ESP
SPI plus IPv6 or IPv4-in-IPv6 address) at this point, and to leave
locators of type 0 for further study. This is briefly mentioned at the
end of section 5.2, but I think you are right that this should also be
mentioned at a more prominent position. I suggest adding the following
text to the end of section 4.2:
This protocol specification limits the use of locators to those with
Locator Type 1. Future extensions to this protocol may specify the
use of locators with Locator Type 0. One example where locators with
Locator Type 0 would be useful is the inclusion of a LOCATOR parameter
in an R1 packet. This requires the use of type-0 locators since no
ESP
SAs are set up at that point.
Ok, but what actually happens if someone tells you they are moving to a
locator with type 2, which you can't handle? If you drop the update on the
floor, they will just keep retransmitting it (BTW, I assume HIP specifies
exponential backoff).
=====
Section 5.2: Sending LOCATORs
The announcement of link-local addresses is a policy decision; such
addresses used as Preferred locators will create reachability
problems when the host moves to another link.
In fact, even a host which is not mobile should be careful to avoid
advertising link-local addresses to peers not on the same link.
Yes, that's true. We could extend the above sentence to the following:
Link-local addresses MAY be announced to peers that are known to be
neighbors on the same link, for example, when the IP destination
address of a peer is link-local, too. The announcement of link-local
addresses in this case is a policy decision; link-local addresses used
as Preferred locators will create reachability problems when the host
moves to another link. In any case, link-local addresses MUST NOT
be announced to a peer unless that peer is known to be on the same
link.
I think that would be a good change. But maybe there are people reading
this thread with more layer-3 expertise than I who can comment...
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@xxxxxxx>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf