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

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

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

Thanks!

Best regards.

JMC.

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