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

From: Jean-Michel Combes <[email-masked]>
Date: Mon, 5 Sep 2011 19:09:40 +0200

2011/8/24 Joel M. Halpern <[email-masked]>:
> Without arguing about what document things belong in, the proposed text is
> just a paraphrase of one half of what "trusted port for dhcp" meands.
> the other half, "untrusted port for dhcp" means that if the Next Header
> value is detectably DHCP, but the port is not trusted for DHCP, it should be
> dropped.
> Those are, I believe already in the document.
>
> The issue we are discussing is what more should be said about the cases
> where the Next Header value can not be found.  This arises either when
> either fragmentation moves the next header to the next message, or extra
> headers move it outside of the parse capabilities of the device.

Yes, this is the issue.

>
> It is probably sufficient to simply note that the trusted port enforcement
> does not handle those cases.
>
> The reason for putting it in the MIX document is that there is a very
> similar issue for NS detection.

Yes. BTW, maybe, MIX deployment may complicate the situation too
because this includes many SAVI solutions (and so their consequent
drawbacks).

Best regards.

JMC.

>
> Yours,
> Joel
>
> On 8/23/2011 10:55 PM, Jun Bi wrote:
>>
>> I agree with Guang Yao.
>> thanks,
>> Jun Bi
>> *From:* Guang Yao <mailto:[email-masked]>
>> *Sent:* Monday, August 22, 2011 5:19 PM
>> *To:* Jean-Michel Combes <mailto:[email-masked]>
>> *Cc:* SAVI Mailing List <mailto:[email-masked]>
>> *Subject:* Re: [savi] Potential issue for all SAVI mechanisms?
>> Hi,
>> I agree with the text. However, in DHCP case, only DHCP message from
>> dhcp-trust and savi-validation port is processed by the SAVI device. So
>> I add the condition as follows.
>> -If the Next Header value inside the Fragment header is DHCP, / and if
>> the packet is from dhcp-trust port or SAVI-validation port/, the packet
>> is processed by the SAVI device,
>> If this condition can be implied from existing text, just remove it.
>> Besides, I wonder whether it is necessary to include this in the MIX
>> document, as MIX document doesn't specify the details of packet process.
>> If FCFS/DHCP/SEND can each handle this problem separately, MIX can also
>> handle this problem.
>>
>> Best regards,
>> Guang
>>
>> 2011/8/19 Jean-Michel Combes <[email-masked]
>> <mailto:[email-masked]>>
>>
>>    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
>>    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 <[email-masked]
>>    <mailto:[email-masked]>>:
>>     > Hi Joel,
>>     >
>>     > 2011/6/28 Joel M. Halpern <[email-masked]
>>    <mailto:[email-masked]>>:
>>     >> 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
>>    [email-masked] <mailto:[email-masked]>
>>    https://www.ietf.org/mailman/listinfo/savi
>>
>> _______________________________________________
>> savi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/savi
>>
>>
>> _______________________________________________
>> savi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/savi
>

---

From: Jean-Michel Combes <[email-masked]>
Date: Mon, 5 Sep 2011 19:10:56 +0200

> Comments/alternative text (deadline: 8-september-2011) are welcome!

Thanks!

Best regards.

JMC.

2011/8/18 Jean-Michel Combes <[email-masked]>:
> <TEXT: only keep ND for FCFS/SEND SAVI and only keep UDP(DHCP) for DHCP SAVI>
> o SAVI limitations
> 2011/6/28 Jean-Michel Combes <[email-masked]>:
>> Hi Joel,
>>
>> 2011/6/28 Joel M. Halpern <[email-masked]>:
>>> 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.
>>>>
>>>>
>>>>
>>>
>>
>

---

From: Alberto García <[email-masked]>
Date: Tue, 6 Sep 2011 13:46:40 +0200

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

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] 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 <[email-masked]>:
|  > Hi Joel,
|  >
|  > 2011/6/28 Joel M. Halpern <[email-masked]>:
|  >> 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
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 06 Sep 2011 10:22:39 -0400

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.

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.

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.

Yours,
Joel

On 9/6/2011 7:46 AM, Alberto García wrote:
> |<TEXT: only keep ND for FCFS/SEND SAVI and only keep UDP(DHCP) for DHCP
> |</TEXT>
> |  2011/6/28 Jean-Michel Combes<[email-masked]>:
> |>  Hi Joel,
> |>
> |>  2011/6/28 Joel M. Halpern<[email-masked]>:
> |>>  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.
> |>>>
> |>>>
> |>>>
> |>>
> |>

---

From: Alberto García <[email-masked]>
Date: Tue, 6 Sep 2011 19:05:11 +0200

Hi Joel,

|  -----Mensaje original-----
|  De: Joel M. Halpern [mailto:[email-masked]]
|  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: [email-masked] [mailto:[email-masked]] 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<[email-masked]>:
|  > |>  Hi Joel,
|  > |>
|  > |>  2011/6/28 Joel M. Halpern<[email-masked]>:
|  > |>>  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
|  > |  [email-masked]
|  > |  https://www.ietf.org/mailman/listinfo/savi
|  >
|  > _______________________________________________
|  > savi mailing list
|  > [email-masked]
|  > https://www.ietf.org/mailman/listinfo/savi
|  >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 06 Sep 2011 13:37:19 -0400

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.

It seems to me much better to note this vulnerability in SAVI, and leave 
it there.
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,
> |>  Caching up  - still within the deadline :-)
> |>
> |>  |  -----Mensaje original-----
> |>  |  De: [email-masked] [mailto:[email-masked]] 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
> |>  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
> |>  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',
> |>  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<[email-masked]>:
> |>  |>   Hi Joel,
> |>  |>
> |>  |>   2011/6/28 Joel M. Halpern<[email-masked]>:
> |>  |>>   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
> |>  |  [email-masked]
> |>  |  https://www.ietf.org/mailman/listinfo/savi
> |>
> |>  _______________________________________________
> |>  savi mailing list
> |>  [email-masked]
> |>  https://www.ietf.org/mailman/listinfo/savi
> |>
>
>

---

From: Fred Baker <[email-masked]>
Date: Tue, 6 Sep 2011 10:54:31 -0700

On Sep 6, 2011, at 10:37 AM, Joel M. Halpern wrote:
> It seems to me much better to note this vulnerability in SAVI, and leave it there.
> If we want it fixed, 6man should simply instruct hosts not to accept RAs or DHCPs in fragmented packets.

having 6man fix it makes sense to me. I'm not sure how we can fix it in SAVI without asking the switch to reassemble fragmented messages.

---

From: Alberto García <[email-masked]>
Date: Wed, 7 Sep 2011 10:31:02 +0200

Hi Joel,

|  -----Mensaje original-----
|  De: Joel M. Halpern [mailto:[email-masked]]
|  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:[email-masked]]  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: [email-masked] [mailto:[email-masked]] 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<[email-masked]>:
|  > |>  |>   Hi Joel,
|  > |>  |>
|  > |>  |>   2011/6/28 Joel M. Halpern<[email-masked]>:
|  > |>  |>>   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
|  > |>  |  [email-masked]
|  > |>  |  https://www.ietf.org/mailman/listinfo/savi
|  > |>
|  > |>  _______________________________________________
|  > |>  savi mailing list
|  > |>  [email-masked]
|  > |>  https://www.ietf.org/mailman/listinfo/savi
|  > |>
|  >
|  >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 07 Sep 2011 10:04:06 -0400

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:
> |>  |  De: Joel M. Halpern [mailto:[email-masked]]  Enviado el:
> |>  | martes, 06 de septiembre de 2011 16:23
> |>  |  Para: Alberto García; SAVI Mailing List
> |>  |  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
> |>  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: [email-masked] [mailto:[email-masked]] 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<[email-masked]>:
> |>  |>   |>    Hi Joel,
> |>  |>   |>
> |>  |>   |>    2011/6/28 Joel M. Halpern<[email-masked]>:
> |>  |>   |>>    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
> |>  |>   |  [email-masked]
> |>  |>   |  https://www.ietf.org/mailman/listinfo/savi
> |>  |>
> |>  |>   _______________________________________________
> |>  |>   savi mailing list
> |>  |>   [email-masked]
> |>  |>   https://www.ietf.org/mailman/listinfo/savi
> |>  |>
> |>
> |>
>
>

---

From: Jean-Michel Combes <[email-masked]>
Date: Fri, 9 Sep 2011 17:05:30 +0200

Hi Joel,

2011/9/6 Joel M. Halpern <[email-masked]>:

[snip]

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

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.

---

From: Jean-Michel Combes <[email-masked]>
Date: Fri, 9 Sep 2011 17:06:49 +0200

Hi Fred,

same clarification: from your point of view, we have just to mention
the issue without adding a potential solution to
mitigate it, correct?

Thanks.

Yours,

JMC.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 09 Sep 2011 11:54:07 -0400

Agreed.  Our document should not describe the solution.  Joel

On 9/9/2011 11:05 AM, Jean-Michel Combes wrote:
> Hi Joel,
>
>
> 2011/9/6 Joel M. Halpern<[email-masked]>:
>
> [snip]
>
>>

---

From: Fred Baker <[email-masked]>
Date: Fri, 9 Sep 2011 09:52:30 -0700

> the issue without adding a potential solution to

Yes. From my perspective, the most likely solution to be developed in 6man is to ignore ICMP messages with headers or which arrive fragmented, so that sending the messages is at most a bandwidth dos but has no other real effect. In SAVI, however, it makes sense to mention that there is a problem.

---

From: Jean-Michel Combes <[email-masked]>
Date: Fri, 9 Sep 2011 19:03:35 +0200

OK. Thanks.

I would appreciate the opinion from other people in the WG (i.e., just
mentioning the issue and the consequences v.s. mentioning the issue
and adding text about a potential solution to mitigate it), please.

Thanks.

Best regards.

JMC.

---

From: "Jun Bi" <[email-masked]>
Date: Sun, 11 Sep 2011 01:12:09 +0800

I vote for "just mentioning the issue and the consequences"

I agree with Fred and Joel. This common threat should be fixed by 6man or 
other WGs working on IPv6 itself.
In SAVI, we just mention the issues (and actually also the requirement to 
fix it by other WGs). Especially when the current SAVI charter forbids to 
change protocol or create new protocol, our solution is weakened, then it is 
hard for us to fix it completely.

thanks,
Jun Bi

-----原始邮件----- 
From: Jean-Michel Combes
Sent: Saturday, September 10, 2011 1:03 AM
To: Fred Baker
Cc: SAVI Mailing List ; Alberto García
Subject: Re: [savi] Potential issue for all SAVI mechanisms?

OK. Thanks.

Thanks.

Best regards.

JMC.

2011/9/9 Fred Baker <[email-masked]>:
> Yes. From my perspective, the most likely solution to be developed in 6man 
> is to ignore ICMP messages with headers or which arrive fragmented, so 
> that sending the messages is at most a bandwidth dos but has no other real 
> effect. In SAVI, however, it makes sense to mention that there is a 
> problem.
>
>> Thanks.
>>
>> Yours,
>>
>> JMC.
>>
>>> having 6man fix it makes sense to me. I'm not sure how we can fix it in 
>>> SAVI without asking the switch to reassemble fragmented messages.

---

From: Alberto García <[email-masked]>
Date: Mon, 12 Sep 2011 18:35:40 +0200

Hi,
For me it's also fine the 'just mentioning the issue and the consequences' approach.

Regards,
Alberto

|  -----Mensaje original-----
|  De: [email-masked] [mailto:[email-masked]] En nombre de Jun
|  Bi
|  Enviado el: sábado, 10 de septiembre de 2011 19:12
|  Para: Jean-Michel Combes; Fred Baker
|  CC: SAVI Mailing List; Alberto García
|  Asunto: Re: [savi] Potential issue for all SAVI mechanisms?
|  
|  I vote for "just mentioning the issue and the consequences"
|  
|  I agree with Fred and Joel. This common threat should be fixed by 6man or
|  other WGs working on IPv6 itself.
|  In SAVI, we just mention the issues (and actually also the requirement to fix
|  it by other WGs). Especially when the current SAVI charter forbids to change
|  protocol or create new protocol, our solution is weakened, then it is hard
|  for us to fix it completely.
|  
|  thanks,
|  Jun Bi
|  
|  
|  
|  -----原始邮件-----
|  From: Jean-Michel Combes
|  Sent: Saturday, September 10, 2011 1:03 AM
|  To: Fred Baker
|  Cc: SAVI Mailing List ; Alberto García
|  Subject: Re: [savi] Potential issue for all SAVI mechanisms?
|  
|  OK. Thanks.
|  
|  I would appreciate the opinion from other people in the WG (i.e., just
|  mentioning the issue and the consequences v.s. mentioning the issue and
|  adding text about a potential solution to mitigate it), please.
|  
|  Thanks.
|  
|  Best regards.
|  
|  JMC.
|  
|  2011/9/9 Fred Baker <[email-masked]>:
|  >
|  > On Sep 9, 2011, at 8:06 AM, Jean-Michel Combes wrote:
|  >
|  >> Hi Fred,
|  >>
|  >> same clarification: from your point of view, we have just to mention
|  >> the issue without adding a potential solution to mitigate it,
|  >> correct?
|  >
|  > Yes. From my perspective, the most likely solution to be developed in
|  > 6man is to ignore ICMP messages with headers or which arrive
|  > fragmented, so that sending the messages is at most a bandwidth dos
|  > but has no other real effect. In SAVI, however, it makes sense to
|  > mention that there is a problem.
|  >
|  >> Thanks.
|  >>
|  >> Yours,
|  >>
|  >> JMC.
|  >>
|  >> 2011/9/6 Fred Baker <[email-masked]>:
|  >>>
|  >>> On Sep 6, 2011, at 10:37 AM, Joel M. Halpern wrote:
|  >>>> It seems to me much better to note this vulnerability in SAVI, and
|  >>>> leave it there.
|  >>>> If we want it fixed, 6man should simply instruct hosts not to
|  >>>> accept RAs or DHCPs in fragmented packets.
|  >>>
|  >>> having 6man fix it makes sense to me. I'm not sure how we can fix it
|  >>> in SAVI without asking the switch to reassemble fragmented messages.
|  >>> _______________________________________________
|  >>> savi mailing list
|  >>> [email-masked]
|  >>> https://www.ietf.org/mailman/listinfo/savi
|  >>>
|  >
|  >
|  _______________________________________________
|  savi mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi
|  
|  _______________________________________________
|  savi mailing list
|  [email-masked]
|  https://www.ietf.org/mailman/listinfo/savi