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

From: Jean-Michel Combes <[email-masked]>
Date: Thu, 18 Aug 2011 19:50:34 +0200

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]>:
> 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: Guang Yao <[email-masked]>
Date: Mon, 22 Aug 2011 17:19:58 +0800

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

> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 24 Aug 2011 10:55:25 +0800

I agree with Guang Yao.

thanks,
Jun Bi

From: Guang Yao 
Sent: Monday, August 22, 2011 5:19 PM
To: Jean-Michel Combes 
Cc: SAVI Mailing List 
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, 

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

  Hi,

  Thanks in advance.

  Best regards.

  JMC.

--------------------------------------------------------------------------------
_______________________________________________
savi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/savi

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Aug 2011 01:27:44 -0400

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.

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.

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,
> 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,
> 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,
>
>     2011/6/28 Jean-Michel Combes <[email-masked]
>     <mailto:[email-masked]>>:
>      > Hi Joel,
>      >
>      > 2011/6/28 Joel M. Halpern <[email-masked]
>     <mailto:[email-masked]>>:
>     [email-masked] <mailto:[email-masked]>

---

From: "Jun Bi" <[email-masked]>
Date: Wed, 24 Aug 2011 13:41:25 +0800

Thanks Joel,

About mix document, I think Guang meant if each solution draft handle this 
issue,
then mix doucment itself won't be involved into this issue, because the mix 
draft mainly handle the conflics.

thanks,
Jun Bi

-----原始邮件----- 
From: Joel M. Halpern
Sent: Wednesday, August 24, 2011 1:27 PM
To: Jun Bi
Cc: Guang Yao ; Jean-Michel Combes ; SAVI Mailing List
Subject: Re: [savi] Potential issue for all SAVI mechanisms?

Yours,
Joel