Guang

2011/8/19 Jean-Michel = Combes <jeanmichel.combes@gmail.com>

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 <jeanmichel.combes@gmail.com>:

> Hi Joel,
>
> 2011/6/28 Joel M. Halpern <j= mh@joelhalpern.com>:
>> 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 d= evice
>> can not detect an ND packet which is fragmented and hiding behind<= br> >> 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 o= ptions
>> (or AH, or ESP.) =A0they 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 wo= uld
>> ever use that construct.
>>
>> As far as I can tell, the only path to sanity here is for the host= s not
>> to accept such packets.
>> And that is a matter for 6man, not for SAVI. =A0We should simply d= ocument
>> 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 identifie= s the
>>> first header of the Fragmentable Part of the original packet >>> (2) The Unfragmentable Part consists of the IPv6 header plus a= ny
>>> extension headers that must be processed by nodes en route to = the
>>> destination, that is, all headers up to and including the Rout= ing
>>> header if present, else the Hop-by-Hop Options header if prese= nt, 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,<= br> >>> 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 SE= ND, as
>>> this is just ND options)/DHCP:
>>> (a) AH
>>> (b) ESP
>>> (c) Destination Option
>>>
>>> IMHO, ND/DHCP messages with such extension headers are not com= mon ...
>>>
>>>
>>>> >
>>>> > =A0Then the SAVI devices can assume and require that = the known ULP is
>>>> > =A0contained in the first fragment, thus they can det= ermine whether a
>>>> > =A0packet is ND/DHCP/SEND, and reject any such packet= s that include a
>>>> > =A0fragment header.
>>> Indeed, we could assume for each SAVI mechanism that:
>>> - if the Next Header value inside the Fragment header is ND/UD= P(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
savi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/savi