Subject: Re: FW: New Version Notification for draft-wang-6man-flow-label-reflection-00.txt

From: Florent Fourcot <[email-masked]>
Date: Tue, 04 Nov 2014 20:12:30 +0100

Hello,

> 
> We have submitted a new draft to 6man WG. It proposes a flow label reflection mechanism that network devices copy the flow label value from received packets to the corresponding flow label field in return packets. With this mechanism, network operators would easily correlate an upstream session and the corresponding downstream session together. This mechanism could simplify the network traffic recognition process in network operations and make the policy for both directions of traffic of one session consistent.
> 
> http://tools.ietf.org/html/draft-wang-6man-flow-label-reflection
> 

You could be interested on the implementation of this reflection in the
Linux Kernel:

http://marc.info/?l=linux-netdev&m=138978542017318&w=2

It is available in the current stable kernel (and several previous one).
On the same topic, applications can get the received flow label on the
same operating system:

http://marc.info/?l=linux-netdev&m=138997531906902&w=2

Obviously, I think that our draft is a very good idea.

Best Regards,

Florent.

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 6 Nov 2014 01:22:35 +0000

Hi, Florent,

Thanks for your email. That's a very good work. This would certainly enrich the usages for both flow label itself and flow label reflection.

Best regards,

Sheng

>-----Original Message-----
>From: Florent Fourcot [mailto:[email-masked]]
>Sent: Wednesday, November 05, 2014 3:13 AM
>To: [email-masked]; Sheng Jiang
>Subject: Re: FW: New Version Notification for
>draft-wang-6man-flow-label-reflection-00.txt
>
>Hello,
>
>>
>> We have submitted a new draft to 6man WG. It proposes a flow label
>reflection mechanism that network devices copy the flow label value from
>received packets to the corresponding flow label field in return packets. With
>this mechanism, network operators would easily correlate an upstream
>session and the corresponding downstream session together. This mechanism
>could simplify the network traffic recognition process in network operations
>and make the policy for both directions of traffic of one session consistent.
>>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 6 Nov 2014 21:26:38 -0800

Hi,

----- Original Message -----
> From: Sheng Jiang <[email-masked]>
> To: 6man WG <[email-masked]>
> Cc: Aijun Wang <[email-masked]>
> Sent: Friday, 24 October 2014, 16:45
> Subject: FW: New Version Notification for draft-wang-6man-flow-label-reflection-00.txt
> 
> Hi, 6man,
> 
> We have submitted a new draft to 6man WG. It proposes a flow label reflection 
> mechanism that network devices copy the flow label value from received packets 
> to the corresponding flow label field in return packets. With this mechanism, 
> network operators would easily correlate an upstream session and the 
> corresponding downstream session together. This mechanism could simplify the 
> network traffic recognition process in network operations and make the policy 
> for both directions of traffic of one session consistent.
> 
> Please review this draft. Any comments are appreciated.
> 

So for a while I've thought something like this could be used to further mitigate the router ND cache DoS, allowing a received ND NA to statelessly be matched up with a previously sent ND NS.

For example, when a router sends an NS, it sets the flow label to a lightweight hash value that it considers valid for the maximum time an NS/NA transaction could take to complete, including retransmissions (perhaps one of the hash inputs would be the time of day or system uptime rounded off to the nearest RETRANS_TIMER * MAX_MULTICAST_SOLICIT seconds).

An answering host reflects that flow label value back in the ND NA. The receiving router re-calculates the hash, and if it matches the value in the received NA, then it accepts the NA. Otherwise, it could consider the NA to be spoofed, and drop it, or in a less strict mode of operation, only accept the NA if there is room in the ND cache for it.

So in effect the flow label in this scenario is being used as a ND NS/NA transaction identifier that is then only valid for a set period of time.

(Of course, there would be no reason hosts couldn't use this technique either to have a bit more assurance that NAs they receive match up to NSes they've sent.)

> Sheng + Aijun
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Tuesday, October 21, 2014 4:10 PM
>> To: Aijun Wang; Aijun Wang; Sheng Jiang; Sheng Jiang
>> Subject: New Version Notification for
>> A new version of I-D, draft-wang-6man-flow-label-reflection-00.txt
>> has been successfully submitted by Sheng Jiang and posted to the
>> IETF repository.
>> 
>> Name:        draft-wang-6man-flow-label-reflection
>> Revision:    00
>> Title:        IPv6 Flow Label Reflection
>> Document date:    2014-10-21
>> Group:        Individual Submission
>> Pages:        9
>> URL:
>> http://www.ietf.org/internet-drafts/draft-wang-6man-flow-label-reflection-0
>> 0.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-wang-6man-flow-label-reflection/
>> Htmlized:
>> http://tools.ietf.org/html/draft-wang-6man-flow-label-reflection-00
>> 
>> 
>> Abstract:
>>    The current definition of the IPv6 Flow Label focuses mainly on how
>>    the packet source forms the value of this field and how the forwarder
>>    in-path treats it.  In network operations, there are needs to
>>    correlate an upstream session and the corresponding downstream
>>    session together.  This document propose a flow label reflection
>>    mechanism that network devices copy the flow label value from
>>    received packets to the corresponding flow label field in return
>>    packets.  This mechanism could simplify the network traffic
>>    recognition process in network operations and make the policy for
>>    both directions of traffic of one session consistent.
>> 
>> The IETF Secretariat
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 7 Nov 2014 05:58:01 +0000

In lines.

>From: Mark ZZZ Smith [mailto:[email-masked]]
>
>reflection
>So for a while I've thought something like this could be used to further
>mitigate the router ND cache DoS, allowing a received ND NA to statelessly
>be matched up with a previously sent ND NS.
>
>For example, when a router sends an NS, it sets the flow label to a lightweight
>hash value that it considers valid for the maximum time an NS/NA transaction
>could take to complete, including retransmissions (perhaps one of the hash
>inputs would be the time of day or system uptime rounded off to the nearest
>RETRANS_TIMER * MAX_MULTICAST_SOLICIT seconds).
>
>An answering host reflects that flow label value back in the ND NA. The
>receiving router re-calculates the hash, and if it matches the value in the
>received NA, then it accepts the NA. Otherwise, it could consider the NA to be
>spoofed, and drop it, or in a less strict mode of operation, only accept the NA
>if there is room in the ND cache for it.

Hi, Mark,

This looks a good usage for flow label reflection as well. We will consider to include it in the future version. In this case, we even don't need to worry the trust issue of flow label, because there is no intermediate router at all.

One discussion, in the above mechanism, it is not absolutely necessary for the hash-based mechanism although it is technically better by making the sending router stateless. An alternative stateless implementation could also work, the router records the time that it seeds a NS with a certain flow label. 

Best regards,

Sheng

>So in effect the flow label in this scenario is being used as a ND NS/NA
>transaction identifier that is then only valid for a set period of time.
>
>(Of course, there would be no reason hosts couldn't use this technique either
>to have a bit more assurance that NAs they receive match up to NSes they've
>sent.)
>
>> Best regards,
>>
>> Sheng + Aijun
>>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 6 Nov 2014 22:13:19 -0800

----- Original Message -----
> To: Mark ZZZ Smith <[email-masked]>; 6man WG <[email-masked]>
> Sent: Friday, 7 November 2014, 16:58
> Subject: RE: New Version Notification for draft-wang-6man-flow-label-reflection-00.txt
> 
> In lines.
> 
>>>  corresponding downstream session together. This mechanism could 
> simplify
>> the
> This looks a good usage for flow label reflection as well. We will consider to 
> include it in the future version. In this case, we even don't need to worry 
> the trust issue of flow label, because there is no intermediate router at all.
> 
> One discussion, in the above mechanism, it is not absolutely necessary for the 
> hash-based mechanism although it is technically better by making the sending 
> router stateless. An alternative stateless implementation could also work, the 
> router records the time that it seeds a NS with a certain flow label. 
> 

True, except that the ND Cache DoS attack is fundamentally a state resources exhaustion attack, so storing any state while the ND NS is outstanding means the ND implementation is still vulnerable to a state resources exhaustion attack, proportional to the many addresses possible within a /64. The stateless method I've suggested above changes the DoS vector to being a control plane CPU one, which is still an issue however I think it is less of one.

I think the true fundamental issue in either case is that an attacker can use data plane traffic to consume remote router control plane resources, memory and/or CPU. Ultimately I think the only way to completely solve this problem would be to have host's neighbor addresses resolved before they need to be used by data plane traffic forwarded by the router, which I think fundamentally means a host to router node registration protocol of some form, rather than a discovery protocol that is triggered by traffic from remote hosts.

Stateful DHCPv6 is close to that, however it isn't used for link-local addresses or (of course) static addresses, and may be too heavy weight for low power and resource constrained devices that might want to use SLAAC instead. So I think a protocol or method that is closer to or an extension of ND to do no more than node/address registration with a router would be better.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Nov 2014 06:23:15 +1300

>> the trust issue of flow label, because there is no intermediate router at all.

However, an on-link attacker could still inject forged packets with the
same flow label. I expect somebody could invent an attack based on that.

   Brian