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

[Jean-Michel Combes <[e-mail]>]

Hi Joel,


2011/9/6 Joel M. Halpern <[e-mail]>:

[snip]

>
> It seems to me much better to note this vulnerability in SAVI, and leave it
> there.

Just a clarification: from your point of view, we have just to mention
the issue without adding a potential solution (e.g.,
http://www.ietf.org/mail-archive/web/savi/current/msg01675.html) to
mitigate it, correct?

Thanks.

Yours,

JMC.

> If we want it fixed, 6man should simply instruct hosts not to accept RAs or
> DHCPs in fragmented packets.
>
> Yours,
> Joel
>
> On 9/6/2011 1:05 PM, Alberto García wrote:
>>
>> Hi Joel,
>>
>> |  -----Mensaje original-----
>> |  De: Joel M. Halpern [mailto:[e-mail]]
>> |  Enviado el: martes, 06 de septiembre de 2011 16:23
>> |  Para: Alberto García; SAVI Mailing List
>> |  Asunto: Re: [savi] Potential issue for all SAVI mechanisms?
>> |
>> |  There seems to be an assumption in the fragment processing text that
>> the
>> |  next header that points to the ICMP will be in the first packet.
>>
>> I think the assumption is that the first header after the Fragmentation
>> header is ICMP.
>> Every fragment has its fragmentation header, and as I have understood from
>> RFC 2460, on each of these fragments, the Next header of the Fragmentation
>> header will very likely contain the value of the first header after the
>> fragmentation one, i.e. ICMP. That is, it is not relevant if the fragments
>> are received in order or not, because all will probably have the ICMP
>> 'next
>> header' value, being this an indication that they have to be reassembled.
>> So
>> being the first packet does not seem to be relevant.
>> Although I think it is very unlikely to expect so, it may be a problem if
>> the fragments arrive disordered to the SAVI device and the ICMP header is
>> not the first, because the first received fragment (but not the first
>> fragment in the fragmentation sequence) would not be identified as
>> containing ICMP information. So it is not enough to have the header in the
>> first packet, but to have the ICMP header immediately after the
>> Fragmentation header.
>> Does this make sense?
>>
>> Do you think that we should process also packets containing ICMP messages
>> which are not immediately after the Fragmentation header?
>> If so, I think that every fragmented packet should be reassembled, and
>> then
>> checked, which would be overkill for the SAVI device.
>>
>> |
>> |  The reason there is a security threat is that an attacker can carefully
>> |  compose a packet such that the ICMP header is not in the first packet,
>> and
>> |  even the next-hezader type pointing to the ICMP is not in the first
>> |  fragment.
>>
>> If I understand properly, the problem you are stating is that the SAVI
>> devices could forward the packet as 'data', with a source address that is
>> valid for the sender at the port at which it is validated, but the message
>> can convey 'false' ND information (I assume that for a different [source]
>> address of that used to send the packet) which may influence in the ND
>> caches of the destination nodes, isn’t it?
>>
>> If this is the case, I still don't figure out which is the security
>> problem,
>> at least for SEND and ND. First, it seems that it does not affect to the
>> Source Address Validation function, which is the main reason for SAVI,
>> since
>> the packet sent is valid from this point of view (the sender should have
>> been able to prove its address ownership before sending this data). SAVI
>> is
>> now not intended to validate other information, such as the validity of
>> the
>> contents of ND information. Besides, for SEND deployments, the destination
>> is going to check that the message received has been signed with the key
>> associated to the address for which the message declares something,
>> according to the SEND specification.
>> However, I have the feeling that there is something I have not understood,
>> sorry.
>>
>> |
>> |  That needs to be identified.  That is what needs to be identified in
>> the
>> |  security considerations section.
>> |
>> |  As a separate matter, given the complexity of SEND it may be reasonable
>> |  for SAVI SEND to require parsing all the headers in the first fragment,
>> where
>> |  other SAVI cases probably can not do so.  That is up to the WG.
>>
>> The problem with this is that the first fragment may not arrive in the
>> first
>> place (as I said before), and other fragments arriving before may not be
>> available for reassembling.
>>
>> Regards,
>> Alberto
>>
>> |
>> |  Yours,
>> |  Joel
>> |
>> |  On 9/6/2011 7:46 AM, Alberto García wrote:
>> |>  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
>> |>
>> |>  _______________________________________________
>> |>  savi mailing list
>> |>  [e-mail]
>> |>  https://www.ietf.org/mailman/listinfo/savi
>> |>
>>
>>
> _______________________________________________
> savi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/savi
>