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

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