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

[Alberto García <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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
|  >> [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