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

["Joel M. Halpern" <[e-mail]>]

The vulnerability was reported in several drafts discussed in v6ops and 
6man.

Specifically, we describe that there are trusted ports and untrusted 
ports, and RAs are blocked from untrusted ports (and similar filtering 
is applied to DHCPv6 responses.)

However, using this mechanism, if a host is willing to reasssemalbe a 
packet and accept RAs that were fragmented and have extra headers, then 
an attacker on any port can
Pprepare a false RA or RHCPv6 response.
Add as many extension heaqders as desired
Fragment the packet at any position he desires such that the ICMP or 
DHCP header is not in the first fragment
Send the result

It will get past the filtering.
This is a vulnerability in the system as we describe it.

As a secondary vulnerability, hosts can source NS/NA messages the wame 
way, and their contents will not be checked by the SAVI devices.  This 
can mislead other nodes as to where the bound addresses actually reside, 
and whether they are in use.

Yours,
Joel M. Halpern

On 9/7/2011 4:31 AM, Alberto García wrote:
> 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
> |>  |>
> |>
> |>
>
>