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

Jeffrey,

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

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

Ok.

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

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.

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

Alright.

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

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

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

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

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

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