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

From: Jean-Michel Combes <[email-masked]>
Date: Tue, 21 Jun 2011 15:37:36 +0200

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.

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 21 Jun 2011 21:56:34 +0800

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,

Knowing that:

Best regards.

JMC.
_______________________________________________
savi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/savi

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 21 Jun 2011 20:17:06 -0400

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:
> 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),
> The SAVI switch has been really implmented and deployed, so I did really
> see any problem in real network.
> -----原始邮件----- From: Jean-Michel Combes

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 22 Jun 2011 12:35:48 +0800

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?

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Jun 2011 01:11:58 -0400

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 22 Jun 2011 07:26:35 +0200

Right, the question is how comon is for legitimate users to send 
NDP/DHCP/SEND fragmented packets? IS there any concrete real useful 
situacion where this happens?

If not, maybe we could simply say that SAVI will ignore the fragmented 
packets.
If yes, then it seems we may have a problem.

Regards, marcelo

El 22/06/11 06:35, Jun Bi escribió:
> 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: marcelo bagnulo braun <[email-masked]>
Date: Wed, 22 Jun 2011 07:32:32 +0200

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

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 22 Jun 2011 14:13:06 +0800

For DHCP reply, it is the samilar case at RA turst port, it can be handled 
only at DHCP-TRUST port.

thanks,
Jun

-----原始邮件----- 
From: marcelo bagnulo braun
Sent: Wednesday, June 22, 2011 1:32 PM
To: [email-masked]
Subject: Re: [savi] Potential issue for all SAVI mechanisms?

Regards, marcelo

El 22/06/11 07:11, Joel M. Halpern escribió:
> There is no rule that prevents a legitimate host from choosing to fragment 
> the packets.
> 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
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 22 Jun 2011 08:27:41 +0200 (CEST)

> If not, maybe we could simply say that SAVI will ignore the fragmented 

What do you mean by "ignore", do you mean drop?

It's my firm belief that any security measure needs to take into account 
these corner cases and properly handle them (with the same security), 
allowing anyone to send RA just because they're sending them fragmented is 
not ok. It's better to drop these packets than to allow them.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 22 Jun 2011 14:36:56 +0800

Hi Joel,

I meant, in my first eamil I said, in theory, the savi switch can process 
the fragmentation. This is common function in network device.
(and the switch can only process dhcp-reply at dhcp-trust port).

In my last email, I meant, in practical, it won't be a big issue.

thanks,
Jun Bi
-----原始邮件----- 
From: Joel M. Halpern
Sent: Wednesday, June 22, 2011 1:11 PM
To: Jun Bi
Cc: SAVI Mailing List
Subject: Re: [savi] Potential issue for all SAVI mechanisms?

yours,
Joel

---

From: Alberto García <[email-masked]>
Date: Wed, 22 Jun 2011 12:39:23 +0200

Hi,
For the SEND case, the validation mechanism requires cryptographic processing from the switches, which should be very likely performed by the CPU of the switch. IMHO, the increased cost and burden of requiring fragmentation processing just for the specific messages being used by SEND SAVI should not be high compared to the cost of implementing the SEND SAVI mechanism. 

For this case, the 'Security Considerations' section could include some comment to rate-limit this processing to counter a possible DoS attack using fragmented packets (although, again, it would very likely be more effective an attack forcing the switch to perform the validation for invalid SEND messages - as it is currently discussed in the 'Security Considerations')

Regards,
Alberto

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de
|  Jun Bi
|  Enviado el: miércoles, 22 de junio de 2011 8:37
|  Para: Joel M. Halpern
|  CC: SAVI Mailing List
|  Asunto: Re: [savi] Potential issue for all SAVI mechanisms?
|  
|  Hi Joel,
|  
|  I meant, in my first eamil I said, in theory, the savi switch can process the
|  fragmentation. This is common function in network device.
|  (and the switch can only process dhcp-reply at dhcp-trust port).
|  
|  In my last email, I meant, in practical, it won't be a big issue.
|  
|  thanks,
|  Jun Bi
|  -----原始邮件-----
|  From: Joel M. Halpern
|  Sent: Wednesday, June 22, 2011 1:11 PM
|  To: Jun Bi
|  Cc: SAVI Mailing List
|  Subject: Re: [savi] Potential issue for all SAVI mechanisms?
|  
|  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
|  >> [email-masked]
|  >> https://www.ietf.org/mailman/listinfo/savi
|  >> _______________________________________________
|  >> savi mailing list
|  >> [email-masked]
|  >> https://www.ietf.org/mailman/listinfo/savi
|  >
|  >
|  
|  _______________________________________________
|  savi mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 22 Jun 2011 10:37:27 -0400

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 22 Jun 2011 06:39:15 -0700

> situacion where this happens?

The way I read RFC 4861's
    The size of an ND packet including the IP header is limited to the
    link MTU.  When adding options to an ND packet, a node MUST NOT
    exceed the link MTU.
is that ND packets should not be fragmented. But the spec doesn't have 
an explicit MUST NOT fragment.

I haven't looked at the DHCP and SEND RFCs.

> If yes, then it seems we may have a problem.

I don't think we can just ignore them, since that would assume that the 
receivers would explicitly drop fragmented ND/DHCP/SEND packets, which 
they are not required to do.

Can we always tell whether a packet, which might in theory have 2K of 
Destination options, is a ND/DHCP/SEND packet? Clearly not unless RFC 
2460 requires that some bytes of the ULP (TCP, UDP, ICMP, etc) header is 
always in the first fragment. In practice it would be reasonable to 
expect that. But it seems to be a protocol change to IPv6 to require 
that senders must put the ULP header in the first fragment.

Then the SAVI devices can assume and require that the known ULP is 
contained in the first fragment, thus they can determine whether a 
packet is ND/DHCP/SEND, and reject any such packets that include a 
fragment header.

    Erik

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Fri, 24 Jun 2011 10:37:03 +0200

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?

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

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 24 Jun 2011 07:26:46 -0700

> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 24 Jun 2011 10:46:35 -0400

There is an interesting interaction between fake RAs / DHCPs and SAVI.

As we have noted in other documents, RA-guard /DHCP-Guard complement 
SAVI, and help the SAVI mechanisms provide the right controls.

The interesting effect therefore is that messages which slip past teh 
guards, and therefore are not recognized by SAVI, will mislead hosts 
without misleading the SAVI devices.  This means that the honest hosts 
will be unable to communicate.  That is probably an improvement over 
having them communicate using the wrong addresses, but it still causes 
difficulties.

 From conversation with Ran, and some analysis, it seems to me that the 
right answer to the problem is otuside of SAVI's scope.  I think that 
the right answer is for hsots to ignore any such messages which are 
fragmented.

Yours,
Joel