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

[Jeffrey Hutzelman <jhutz at cmu.edu>]

On Tuesday, January 30, 2007 08:26:01 PM +0100 Christian Vogt 
<chvogt at tm.uka.de> 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+ at cmu.edu>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf