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

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

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.

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