Re: [savi] Potential issue for all SAVI mechanisms?

[Erik Nordmark <[e-mail]>]

On 6/24/11 1:37 AM, Eric Levy-Abegnoli wrote:
> A couple of comments on the topic:
>
> - I don't see that it is in any way easier to poison the binding table
> using fragmented packets. So fragmented packets are more a problem for
> features like RA-guard ( that intend to block RA at the switch) or
> DHCP-guard (same for DHCP replies) when they are received from an
> untrusted device. However this is not within the scope of SAVI, is it?

It isn't only the binding table that matters - it is also the Neighbor 
Caches on the attached nodes.

If a SAVI device lets a NA or NS through, because it was fragmented in a 
way that made the SAVI device not see it as a NA or NS, then that can be 
used to corrupt the NC on the attached nodes.

I guess that wouldn't be a SAVI problem; the node might think it has its 
IP address stolen, or send packets to the wrong MAC address, but the 
source addresses would still be enforced by SAVI based on its bindings.

Thus worst SAVI case, for some node that fragments their NS or NA, is 
that the node's addresses would never be entered in the binding table 
and hence the node can not use the network. But that is the node's own 
problem - it can stop with such silly fragmentation.

    Erik

> - Fragmented DHCP messages (or RAs) are causing the savi device a
> different problem: we might miss some bindings (if they are not in the
> first fragment). I don't see that as a big problem if these fragmented
> messages are anomalies (then the SAVI device will block traffic from the
> missed sources). It _is_ a problem however if the fragmented messages
> are not anomalies. And obviously, with DHCP at least, they might not be.
>
> - As far as the switch doing the "police" for hosts (RA-guard, etc.) the
> problem is very hard to solve on the switch, because it might be
> impossible to identify the Upper Layer (ICMP/RA, UDP/DHCP/REPLY) in the
> first fragment. A (smart) attacker would push the ULP into the second
> fragment. In addition, attackers use overlapping fragments, which most
> stacks accept today, and that allow to rewrite the ULP in the second
> fragment. So the switch simply cannot identify the real nature of such
> packets, unless it performs reassembly.
> Eric
>
> Le 22/06/2011 16:37, Joel M. Halpern a écrit :
>> I considered whether we could "drop" short DHCP /RA packets.
>> The problem is that the threat is precisely using fragmentation such
>> that one can not identify the packet from one fragment.
>>
>> That is why I raised the straw man of declaring that first fragments
>> for any packets in a SAVI network can not be that short.
>>
>> If we can drop the first fragment, we don't have to worry about what
>> happens with the rest.
>> But, that is a major change to the base IPv6 spec, and therefore is
>> not, as far as I can tell, within the SAVI charter.
>>
>> Yours,
>> Joel
>>
>> On 6/22/2011 1:32 AM, marcelo bagnulo braun wrote:
>>> Right, for the SLAAC case we should differentiate two cases:
>>> the case of RA and the case of NS and NA.
>>>
>>> The case of RA i think it is easy to solve. Only RA coming from trusted
>>> ports should be processed and if you have an attacker there you have
>>> bigger problems than the possibility of receiving fragmented RAs. The
>>> current SLAAC draft doesn states that a SAVI device must only process RA
>>> coming from trusted ports, but i think we should add text about this.
>>>
>>> The case of NA and NS is much more difficult to handle since they are
>>> the main messages used by non trusted hosts/ports.
>>> In this case, i still think that it would be importnat to understnad if
>>> there is reasonable cases where a legitimate user needs to send
>>> fragmented NA and NS.
>>>
>>> Regards, marcelo
>>>
>>>
>>>
>>> El 22/06/11 07:11, Joel M. Halpern escribió:
>>>> You are missing the point.
>>>> There is no rule that prevents a legitimate host from choosing to
>>>> fragment the packets.
>>>> Therefore, we can not simply drop short fragments.
>>>> This means that a malicious device can choose to generate short
>>>> fragments in order to mislead the filters. It can not mislead the
>>>> filters about the IP address. But it can create false DHCP replies or
>>>> RAs.
>>>>
>>>> The net effect would be to cause hosts to be unable to communicate,
>>>> since they would be using improper addresses.
>>>>
>>>> yours,
>>>> Joel
>>>>
>>>> On 6/22/2011 12:35 AM, Jun Bi wrote:
>>>>> In the Ethernet environment, the MTU is 1500, DHCP reply is not a
>>>>> large
>>>>> packet and it won't be fragmented.
>>>>> Maybe the packet size of RA is large and might be fragmented, but
>>>>> it is
>>>>> not processed in SAVI.
>>>>>
>>>>> thanks,
>>>>> Jun Bi
>>>>>
>>>>> -----原始邮件----- From: Joel M. Halpern
>>>>> Sent: Wednesday, June 22, 2011 8:17 AM
>>>>> To: Jun Bi
>>>>> Cc: Jean-Michel Combes ; SAVI Mailing List
>>>>> Subject: Re: [savi] Potential issue for all SAVI mechanisms?
>>>>>
>>>>> I do not think this is a sufficient answer. Whether the device is a
>>>>> switch or a router, reassembling or maintaining packet state across
>>>>> fragements is a non-trivial undertaking.
>>>>>
>>>>> I can imagine some kludges to get around this, but they have broader
>>>>> impact than just SAVI. (For example, rejecting first packets that do
>>>>> not have enough information to determine whether or not they are
>>>>> claiming to be RAs or DHCP replies.)
>>>>>
>>>>> Yours,
>>>>> Joel
>>>>>
>>>>> On 6/21/2011 9:56 AM, Jun Bi wrote:
>>>>>> Hi Jean-Michel,
>>>>>>
>>>>>> What we are talking about "savi switch" is a 2.5 layer switch
>>>>>> (layer 2
>>>>>> switch in data plan with layer 3-aware in controll/management plan).
>>>>>> So what I know from switch vendor is that the 2.5 layer switch
>>>>>> chip or
>>>>>> the stronger CPU can handel it.
>>>>>> For example, the chip can recongnize the Protocol ID field of IP
>>>>>> packets
>>>>>> to recongznie HDCP or NDP packets (even in fragments),
>>>>>> then copy them to switch CPU. The CPU can handle it.
>>>>>>
>>>>>> The SAVI switch has been really implmented and deployed, so I did
>>>>>> really
>>>>>> see any problem in real network.
>>>>>> BTW, it seems that SAVI switch doesn't snoop and process RA
>>>>>> packets for
>>>>>> binding, so maybe RA packet is different.
>>>>>>
>>>>>> thanks,
>>>>>> Jun Bi
>>>>>>
>>>>>> -----原始邮件----- From: Jean-Michel Combes
>>>>>> Sent: Tuesday, June 21, 2011 9:37 PM
>>>>>> To: SAVI Mailing List
>>>>>> Subject: [savi] Potential issue for all SAVI mechanisms?
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Maybe you already know that there is a discussion on v6ops/6man MLs
>>>>>> about RA Guard evasion (cf.
>>>>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html).
>>>>>> One of the methods to perform this evasion is fragmentation: it seems
>>>>>> that a L2 device would not be able to re-assemble all the fragments
>>>>>> without an important extra-cost and so would not be able to determine
>>>>>> whether or not the message is a Router Advertisement (cf.
>>>>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html).
>>>>>>
>>>>>> Knowing that:
>>>>>> (1) In common use-case, SAVI device is a L2 device
>>>>>> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection
>>>>>>
>>>>>> I am wondering whether or not fragmentation would not impact strongly
>>>>>> SAVI specifications too: any fragmented NDP/SEND/DHCP message could
>>>>>> not update correctly the Binding Table and so what would be the
>>>>>> consequences?
>>>>>>
>>>>>> I would appreciate comments from WG members, especially
>>>>>> implementors/manufacturers, about this.
>>>>>>
>>>>>> Thanks in advance for your replies.
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>>> JMC.
>>>>>> _______________________________________________
>>>>>> savi mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/savi
>>>>>> _______________________________________________
>>>>>> savi mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/savi
>>>>>
>>>>>
>>>> _______________________________________________
>>>> savi mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/savi
>>>
>>> _______________________________________________
>>> savi mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/savi
>> _______________________________________________
>> savi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/savi
>
> _______________________________________________
> savi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/savi
>