Jeffrey and Christian,
Thanks for your comments and discussion. To summarize the email
exchange on this document, I propose to make the following changes:
1. Section 3.1.2 Mobility Overview
Old: "This UPDATE packet is acknowledged by the peer, and is
protected by retransmission."
New: "This UPDATE packet is acknowledged by the peer. For reliability
in
the presence of packet loss, the UPDATE packet is retransmitted as
defined in the HIP protocol specification [2]."
(note to Jeffrey-- yes, these are exponentially backed off)
Along these lines, as Christian pointed out, the phrase "protected by
retransmission" should probably be clarified in section 5.2:
Old: "The UPDATE also contains a SEQ parameter as usual
and is protected by retransmission."
New: "The UPDATE also contains a SEQ parameter as usual.
The packet is retransmitted as defined in the HIP
protocol specification [2]."
2. Section 3.3.2: Credit-Based Authorization
Old: "2. An attacker can always cause unamplified flooding by sending
packets to its victim directly."
New:
"2. An attacker can often cause unamplified flooding by sending
packets to its victim, either by directly addressing the
victim in the packets, or by guiding the packets along a
specific
path by means of an IPv6 Routing Header, if Routing Headers
are
not filtered by firewalls."
3. 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?
>
I agree with your point that it is probably useful to define some error
behavior to distinguish between unsupported Locator Types and dropped
packets.
There is a HIP NOTIFY mechanism defined in the base spec which could be
reused for this purpose. I would suggest that we define a new Notify
Message Type in the range 31-50 for "LOCATOR_TYPE_UNSUPPORTED", with the
Notification Data field
containing the Locator(s) that the receiver failed to process.
The following rules seem appropriate:
- a HIP host SHOULD send a NOTIFY error if an unsupported Locator Type
is received in a LOCATOR parameter, when such Locator is also declared
to be the Preferred locator for the peer
- otherwise, a HIP host MAY send a NOTIFY error if an unsupported
Locator Type is received in a LOCATOR parameter
4. Section 5.2: Sending LOCATORs
Old: "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."
New:
"Link-local addresses MAY be announced to peers that are known to
be
neighbors on the same link, such as when the IP destination
address of a peer is also link-local. 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."
(and I think I will split up that paragraph which is now becoming
long...)
-Tom
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf