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

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

Hi Joel,

|  -----Mensaje original-----
|  De: Joel M. Halpern [mailto:[e-mail]]
|  Enviado el: martes, 06 de septiembre de 2011 19:37
|  Para: Alberto García
|  CC: 'SAVI Mailing List'
|  Asunto: Re: [savi] Potential issue for all SAVI mechanisms?
|  
|  Your reading and mine of the fragment spec do not match.
|  Start with an ICMP packet.
|  Add a number of next headers before the ICMP header.
|  Now the packet is too long.  (Make it MUCH too long.) So it has to be
|  fragmented.
|  The next header field in the fragmentation header will point to the
header
|  which is next in the reassembled packet.
|  
|  Note that in fragments after the first, the bytes following the fragment
|  header are not even the start of a header.  They are whatever bytes come
|  next in the packet.
|  
|  So, if the ICMP does not fit in the first packet, the only way to find it
is to
|  reassemble the whole packet.
|  Asking every SAVI device to reassemble every packet which does not have
|  TCP or UDP has the next header in the first fragment seems a major
|  imposition.
|  But that is what it would take to find the ICMP header.

Completely agreed, so far we have the same understanding of the spec.

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

My misunderstanding is why you call this a 'vulnerability'. 
 [RFC4949]: " $ vulnerability
      (I) A flaw or weakness in a system's design, implementation, or
      operation and management that could be exploited to violate the
      system's security policy. (See: harden.)"

How can this be exploited to violate the system's security policy? From my
point of view, the issue we are discussing could prevent a legitimate user
to communicate, and we are discussing which would be the appropriate SAVI
behavior that works well for most cases without requiring too high cost from
SAVI devices. But I don't see how this relate to the security considerations
of the mechanism.

Regards,
Alberto

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