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

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

Hi,
Caching up  - still within the deadline :-)

|  -----Mensaje original-----
|  De: [e-mail] [mailto:[e-mail]] En nombre de
|  Jean-Michel Combes
|  Enviado el: jueves, 18 de agosto de 2011 19:51
|  Para: SAVI Mailing List
|  Asunto: Re: [savi] Potential issue for all SAVI mechanisms?
|  
|  Hi,
|  
|  I would like to come back on this point and find a consensus.
|  Here is the text I propose to be added in the Security Considerations

I agree that the issue must be considered, although I think that the
corresponding text should not appear in the Security Considerations, but in
the specification of the mechanism. In my opinion, it is not a security side
effect of the deployment of a SAVI mechanism, but part of the functional
specification to address the fragmentation case (and the case in which there
are other headers before). In addition, I don't like very much to have
'behaviors' being specified in many different sections. The security
considerations should just consider the case in which this fragmentation
processing is used by a malicious user to perform a DoS attack.

I have made the exercise of try to adapt this to SEND SAVI, and I ended up
with the text I include below (based on Jean-Michel initial text). The main
differences with Jean-Michel's text are
- the approach is to address the general case in which IPv6 extension
headers appear: I think we need to state what should it be done in this case
(for which fragmentation is a particular case). My opinion is that SAVI
devices should jump over the possible headers looking for ND information
(SEND is heavy in terms of processing, so just adding this processing does
not seem to be awkward - may other scenarios should be dealt with
differently). However, for the fragmentation particular case, I adhere to
the idea of only processing if the next header to the fragmentation header
is ICMPv6 (because I think the cost of reassembling is heavier than just
inspecting many headers of a packet). 
- I have tried to clarify which does 'process the packets' (for the
fragmented packet) mean in this context (whether the fragments should be
forwarded or not, how/when...)
- security considerations deals with DoS attacks exploiting this behavior

What do you think?

----
<TEXT: tailored for SEND, can be easily adapted to ND, possibly to DHCP>
"4.4 Processing messages containing IPv6 extension headers
It may occur that SEND messages relevant for SEND SAVI operation contain
IPv6 extension headers located before the SEND information. To ensure that
these messages are processed, the SEND SAVI device SHOULD inspect any packet
containing IPv6 extension headers until it could determine whether it
includes relevant SEND information for SEND SAVI operation or not. 

A particular case of this inspection occurs if the SEND message is
fragmented. In order to process fragmented SEND messages, the SEND SAVI
device SHOULD proceed as follows:
When a SEND SAVI device receives a fragmented packet, it SHOULD inspect the
Next Header value inside the Fragment header to check if it is an ICMPv6
message. If the Fragment header does not point to an ICMPv6 message, then
the packet MUST be treated as a data packet by the SEND SAVI device. 
Fragment packets pointing to ICMPv6 messages SHOULD be reassembled by the
SEND SAVI device according to [RFC2460]. The fragments MUST NOT be forwarded
until the packet is reassembled and processed according to the SEND SAVI
specification (the SEND SAVI specification will ultimately determine if the
message should be forwarded or not, and to which ports). When the SEND SAVI
specification indicates that the message should be forwarded, the SEND SAVI
device MAY forward the fragments as received originally, or it MAY forward
the message fragmented in a different way, or it MAY forward the reassembled
message in a single packet.

Note that fragmented packets in which the fragment header does not point to
an ICMPv6 message are processed as data packets by the SEND SAVI device,
i.e. they are forwarded if the state associated to the source address is
VALID,  TENTATIVE_DAD, TESTING_VP and TESTING_VP', and discarded otherwise.
These packets are not further processed by the SEND SAVI device to update
the SAVI state; this would be the case, for example, for a fragmented packet
containing a Destination option and then a ND message. The reason for not
reassembling such packets is to avoid incurring in the cost for reassembling
packets that are unlikely to contain SEND messages."
----
[Next paragraph to be added to Security considerations, in the '5.2.
Protection Against Denial of Service Attacks' subsection]
The inclusion of extension headers in any packet, or the fragmentation of
packets containing SEND messages, can be used to stress the SAVI device by
requiring large amount of resources to inspect packets and reassemble the
fragments. A SEND SAVI device MUST limit the amount of resources used to
store and process these packets, for example by rate-limiting the processing
of packets containing extension headers (or fragmented packets pointing to
ICMPv6 message), in a per-port basis.
<END OF TEXT>

Regards,
Alberto


|  section of any SAVI solution document (i.e., FCFS, DHCP, SEND and MIX
|  documents) as residential threats:
|  
|  <TEXT: only keep ND for FCFS/SEND SAVI and only keep UDP(DHCP) for DHCP
|  SAVI> o SAVI limitations In some cases, the SAVI device could not be able
to
|  process IP packets and so to update correctly the Binding Table. For
|  example, this could be the case for encrypted packets (i.e., with
IPsec/ESP)
|  or fragmented packets. To mitigate this last case, the SAVI device SHOULD
|  proceed as
|  follows:
|  - If the Next Header value inside the Fragment header is ND/UDP(DHCP),
the
|  packet is processed by the SAVI device,
|  - If the Next Header value inside the Fragment header is not
|  ND/UDP(DHCP) but there is a binding, the packet is processed by the SAVI
|  device,
|  - Else the packet is dropped and the incident is logged.
|  </TEXT>
|  
|  Comments/alternative text (deadline: 8-september-2011) are welcome!
|  
|  Thanks in advance.
|  
|  Best regards.
|  
|  JMC.
|  
|  2011/6/28 Jean-Michel Combes <[e-mail]>:
|  > Hi Joel,
|  >
|  > 2011/6/28 Joel M. Halpern <[e-mail]>:
|  >> I don't think this works.
|  >> The question is not how often ND packets have that structure, but
|  >> whether
|  >> 1) Hosts will accept ND packets with that structure and
|  >> 2) Other protocols will use that structure.
|  >>
|  >> If both of those are true, which they currently are, then a SAVI
|  >> device can not detect an ND packet which is fragmented and hiding
|  >> behind destination options.
|  >> But, contrary to your resolution below, since other protocols use
|  >> that construct, SAVI devices can not simply drop all packets that are
|  >> fragmented and where the only visible next header is destination
|  >> options (or AH, or ESP.)  they would be dropping legitimate data
packets.
|  >
|  > Yep, I missed this ... So, a new proposal:
|  > - if the Next Header value inside the Fragment header is ND/UDP(DHCP),
|  > the packet is processed by the SAVI device
|  > - if the Next Header value inside the Fragment header is not
|  > ND/UDP(DHCP) and there is a binding, the packet is processed by the
|  > SAVI device
|  > - else the packet is dropped and the incident is logged
|  >
|  >>
|  >> It does not matter whether any legitimate sender of ND messages would
|  >> ever use that construct.
|  >>
|  >> As far as I can tell, the only path to sanity here is for the hosts
|  >> not to accept such packets.
|  >> And that is a matter for 6man, not for SAVI.  We should simply
|  >> document this as a residual threat.
|  >
|  > IMHO, this is a matter for SAVI too, because, if the SAVI device is
|  > not able to process fragmented ND/DHCP packets from a node to
|  > correctly update the Binding Table, by default, any packet from this
|  > node will be dropped by the SAVI device even if hosts accept such
|  > packets.
|  >
|  > Cheers.
|  >
|  > JMC.
|  >
|  >>
|  >> Yours,
|  >> Joel
|  >>
|  >>
|  >> On 6/28/2011 1:26 PM, Jean-Michel Combes wrote:
|  >>> Based on RFC 2460:
|  >>> (1) the Next Header value inside the Fragment header identifies the
|  >>> first header of the Fragmentable Part of the original packet
|  >>> (2) The Unfragmentable Part consists of the IPv6 header plus any
|  >>> extension headers that must be processed by nodes en route to the
|  >>> destination, that is, all headers up to and including the Routing
|  >>> header if present, else the Hop-by-Hop Options header if present,
|  >>> else no extension headers.
|  >>> (3) Extension header order is: IPv6 header, Hop-by-Hop Options
|  >>> header, Destination Options header, Routing header, Fragment header,
|  >>> Authentication header, Encapsulating Security Payload header,
|  >>> Destination Options header, upper-layer header
|  >>>
|  >>> So, as far as I can see, there are only 3 scenarios where the Next
|  >>> Header value inside the Fragment header is not ND(including SEND, as
|  >>> this is just ND options)/DHCP:
|  >>> (a) AH
|  >>> (b) ESP
|  >>> (c) Destination Option
|  >>>
|  >>> IMHO, ND/DHCP messages with such extension headers are not
|  common ...
|  >>>
|  >>>
|  >>>> >
|  >>>> >  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.
|  >>> Indeed, we could assume for each SAVI mechanism that:
|  >>> - if the Next Header value inside the Fragment header is
|  >>> ND/UDP(DHCP), the packet is processed
|  >>> - else the packet is dropped and the incident is logged
|  >>>
|  >>> As SAVI has a site/link scope, with the logs, IMHO, it should be
|  >>> easier for the SAVI admin to understand/solve the issue.
|  >>>
|  >>> Best regards.
|  >>>
|  >>> JMC.
|  >>>
|  >>>
|  >>>
|  >>
|  >
|  _______________________________________________
|  savi mailing list
|  [e-mail]
|  https://www.ietf.org/mailman/listinfo/savi