RE: secdir review of draft-ietf-hip-mm-04.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]