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

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 29 Jan 2007 20:49:53 -0500

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Overall, I found this document to be fairly straightforward and easy to
understand, even without a deep background in HIP.  It does introduce
new security considerations associated with the ability to cause traffic
destined for a host to be redirected to a new location.  However, these
are discussed and, provided HIP itself behaves as advertised, they are
adequately addressed.  I have a few comments and questions, but nothing
to indicate this document should not be published as Experimental.

Section 3.1.2: Mobility Overview

>  This UPDATE packet is acknowledged by the peer, and is
>  protected by retransmission.

What does "protected by retransmission" mean here?

=====

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".  Or, an attacker may attempt to create congestion on the
link between two victims, where the attacher has better connectivity to
both victims than they do to each other.

IMHO this is not a show-stopper -- the hypothesis quoted above is true in a
large number of cases, and it does appear to me that the credit-based
authorization scheme described here will have a positive erffect in those
cases without otherwise being harmful.  However, it is worth pointing out
that this is not a cure-all.

=====

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?

=====

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.

=====

6.  Security Considerations

>  The HIP mobility mechanism provides a secure means of updating a
>  host's IP address via HIP UPDATE packets.  Upon receipt, a HIP host
>  cryptographically verifies the sender of an UPDATE, so forging or
>  replaying a HIP UPDATE packet is very difficult (see [2]).
>  Therefore, security issues reside in other attack domains.

I believe this is an accurate assessment.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Christian Vogt <[email-masked]>
Date: Tue, 30 Jan 2007 20:42:47 +0100

Hi Jeffrey,

thank you for reviewing this document.

I am responding to your comments because I have worked on the parts of the
document that address Credit-Based Authorization and the related security
considerations, which you are referring to in your review.

>> This UPDATE packet is acknowledged by the peer, and is protected by
>> retransmission.
> 

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.

Along this line, the following should probably be changed in section 5.2,
5th paragraph:

    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 until acknowledged by the peer.

>  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?

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         |

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.

> Or, an attacker may attempt to create congestion on the link between
> two victims, where the attacher has better connectivity to both victims
> than they do to each other.

In this case, too, the attacker could use an IPv6 Routing header to guide
its flooding packets to victim A first, and from there to victim B,
effectively flooding the link between A and B.

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.

> IMHO this is not a show-stopper -- the hypothesis quoted above is true
> in a large number of cases, and it does appear to me that the
> credit-based authorization scheme described here will have a positive
> erffect in those cases without otherwise being harmful.  However, it is
> worth pointing out that this is not a cure-all.

I agree there should be some clarifying text.  But let me wait for your
response until suggest some.

> 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.

> 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.

>> replaying a HIP UPDATE packet is very difficult (see [2]). Therefore,
>> security issues reside in other attack domains.
> 

Thanks again, Jeffrey.  Appreciate the review.

Regards,
- Christian

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 30 Jan 2007 16:07:21 -0500

>     no acknowledgment is received within the period of a retransmission

Ah, OK.  Yes, that makes sense.

>> victim is inside a firewall and the attack is carried out via a host
>> within within a "DMZ".
>

Yes.

>    intranet   |         DMZ          |   Internet

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.

> 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.

>         path by means of an IPv6 Routing header.

s/can always/can often/  ?

>     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).

>     be announced to a peer unless that peer is known to be on the same

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...

---

From: Christian Vogt <[email-masked]>
Date: Tue, 30 Jan 2007 23:04:37 +0100

Jeffrey,

my replies in-line below, removing the parts that we agreed upon...

> internet at large is that nodes in the DMZ _are_ allowed to contact 
> nodes in the intranet.

Ok.

> 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.

That's true, but RFC 4294 (IPv6 Node Requirements) requires IPv6 nodes
in general -- i.e., not just routers -- to be able to process Routing
extension headers of type 0.

Note that the RFC also points to Pekka's
draft-savola-ipv6-rh-ha-security, where exactly the above-mentioned
problem is being described in section 2.1.

And yes, you are right that the problem goes away if the firewall
inspects IPv6 Routing headers or drops any packets that contain them.

>           The key thing is that avenues for unamplified flooding are 
> common enough that adding one more isn't going to make much difference.

Yes, I agree.

> s/can always/can often/  ?

Alright.

> 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).

Given that the protocol right now only allows type-1 locators, do you
think that the handling of different locator types could be left to
those protocol extensions that specify them?  After all, a mobile node
using a locator of a type other than 1 would not comply to the current
protocol specification, and hence it would be legitimate for the peer to
drop the mobile node's UPDATEs.

On the other hand, the draft could certainly state in section 5.3
(Handling Received Locators) that "A host MUST drop any received UPDATE
packets that include a locator with a Locator Type other than 1."

> this thread with more layer-3 expertise than I who can comment...

A mobile node could inspect its IPv6 Neighbor Cache to find whether a
particular peer is on-link, even if that peer is known by a global IP
address.  The mobile node would de-register the link-local address with
the peer when movement detection indicates that the mobile node has
moved to a different link.  The mobile node could further rely on
Neighbor Unreachability Detection to find out when that neighbor has
moved away.

Regards,
- Christian

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 30 Jan 2007 18:13:44 -0500

On Tuesday, January 30, 2007 11:04:37 PM +0100 Christian Vogt 
<[email-masked]> wrote:

> those protocol extensions that specify them?

I think you need to specify what happens if you see a type you don't 
understand, so that when you do specify a new locator type, existing 
implementations will have a behavior you can depend on.  Otherwise, you're 
painting yourself into a corner with respect to protocol updates.

>  After all, a mobile node

Sure, but the question is whether you _want_ that to be legitimate 
behavior.  If you allow this, then hosts using a new locator type will be 
unable to probe to discover whether other hosts also support that type, 
because a negative response is indistinguishable from a dropped packet.  I 
had trouble last week designing a negotiation mechanism for another 
(non-IETF) protocol with exactly this problem.  I recommend against it, but 
I won't push.

> packets that include a locator with a Locator Type other than 1."

I think even that is preferable to leaving the behavior unspecified.

>>>     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.
>>

Yes, those all sound reasonable to me.  But I am not an IPv6 expert.

-- Jeff

---

From: Christian Vogt <[email-masked]>
Date: Wed, 31 Jan 2007 00:36:33 +0100

Jeffrey,

I see your point and agree.  The draft should be precise with respect to
handling locator types other than 1.

Thanks,
- Christian

---

From: Sam Hartman <[email-masked]>
Date: Tue, 30 Jan 2007 18:57:26 -0500

>>>>> "Christian" == Christian Vogt <[email-masked]> writes:
    Christian> unamplified flooding would also be possible for the
    Christian> attacker without HIP because the attacker could send
    Christian> flooding packets with an IPv6 Routing header, directing
    Christian> the packets to the correspondent node first, and from
    Christian> there to the victim.  To prevent this attack, the
    Christian> firewall would have to look into the flooding packets'
    Christian> extension headers since the IPv6 header would
    Christian> (legitimately) include the correspondent node's IP
    Christian> address.

Take a look at the v6ops IPV6 security overvew document.  It
recommends dropping most routing headers to avoid this sort of attack.

---

From: Christian Vogt <[email-masked]>
Date: Wed, 31 Jan 2007 09:25:50 +0100

Ah, very good!  Thanks for the pointer, Sam.

- Christian