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

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 5 Feb 2007 10:00:59 -0800

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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Christian Vogt <[email-masked]>
Date: Mon, 05 Feb 2007 21:53:25 +0100

Hi Thomas,

I am fine with your suggestions.  Just the following nit:

>> Are locator types critical?  What happens when a host tries to add or
>> move to a locator which is not supported by its peer?
> 
> 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.
> 
 > - 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

Shouldn't the transmission of the NOTIFY be a "MUST" in the special case 
where the LOCATOR parameter contains /only/ locators of unsupported type? 
  The preferred locator would in this case remain the same as before, 
meaning that it would be in DEPRECATED status.

Best,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 5 Feb 2007 13:41:17 -0800

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Monday, February 05, 2007 12:53 PM
> To: Henderson, Thomas R
> Cc: Jeffrey Hutzelman; [email-masked]; [email-masked]; David 
> Ward; Gonzalo Camarillo
> Subject: Re: secdir review of draft-ietf-hip-mm-04.txt
> > 

The main problem in using NOTIFY as a MUST is that the NOTIFY parameter
is defined as being optional in the base spec.  I think that if we agree
that we want a MUST, we will have to define a more explicit and reliable
way to reject the locator, such as a LOCATOR_FAILURE parameter in the
UPDATE.

Tom

---

From: Christian Vogt <[email-masked]>
Date: Tue, 06 Feb 2007 08:18:02 +0100

Thomas,

yes, you're right.  I'm fine with the SHOULD, in particular because the
MM spec does not preclude the Preferred locator to be in DEPRECATED
state.  Although this would be the case in corner cases only, of course.

Regards,
- Christian