Re: draft-wang-6man-flow-label-reflection

[Jeroen Massar <[e-mail]>]

On 2014-11-18 02:42, Aijun Wang wrote:
[..]
>> But more importantly, do you think the Operator community can actually use
>> it?
>>
> 【Aijun】: When the IPv6 traffic are dominant in the internet, the analysis
> for application traffic that based on IPv6 will increased, the flow label
> filed will be exploited gradually.

Why would they use it?

[..]
> For service operator, they are eager to know the application traffic
> distribution within their network, not just the total traffic volume and
> every link's usage.

As the Flow Label does not identify any application, how is the above
relevant?


> For IPv4-based packet, they must know such info via
> 5-tuple message of one packet or via some deep analysis devices in both
> directions. For IPv6 packet, such process can be simpler if they use the
> flow label and flow label reflection mechanism-----the flow label is in IPv6
> fix header potion and the flow label reflection mechanism can correlate the
> upstream and downstream of one session together easily.

The Flow Label is a random number. It does not identify anything.

As such, the 5-tuple is a lot more worthy than that.

>> See below for more about that.
>>
>>
>>> We also consider other usage scenarios for flow label reflection, for
>>> detail information, you can review the presentation document(the link
>>> on the current IETF website connect to the wrong file, then I attached
>>> it via
>>> e-mail.)
>>
>> Those "Usage Scenarios" should be in your draft. That is the only way
> people
>> can properly comment on them.
>>
> 【Aijun】:The "Usage Scenarios" are also described in
> http://datatracker.ietf.org/doc/draft-wang-6man-flow-label-reflection/?inclu
> de_text=1 section 5. The presentation document may be more vivid due to some
> colorful sketch. That's the reason I recommend you to refer the presentation
> document.

You will want to remove this section completely:
8<-------------
   There is rapidly increasing requirement from service providers (SP)
   to cooperate with the content providers (CP) to provide more accurate
   services and charging policies based on accurate traffic recognition."
---------->8

You are basically describing that they will be charging based on
content. That completely defies any kind of "Net Neutrality". Definitely
not something the IETF wants to promote.

Also due to a rather bad connotation of the abbreviation, please do not
use "CP".

Note also, that as the Flow Label is a random number, it does not add
any value to the information already known (typically that the Content
Provider only has a single service on that IP/port).

As such, that is not a good useage scenario.

"5.2.  Flow Label Reflection for Bi-direction Tunnels"

Tunnel providers KNOW what is in the inside. And typically these folks
(think: anonymous VPN) will not want to expose any traffic relation anyway.

Hence, they will not properly use the Flow Label, which still is a
random number, and the src+dst address will tell you the same thing:
some user is sending traffic from src to dst.

"5.3.  Flow Label Reflection on edge devices" has "the service provider
could always use it for bi-directional traffic recognition."

That they can do that is one, but they can already do that based on
other properties.... thus why would they do it this way?


I am very sorry, but I really do not see any need for the Flow Label.
Let alone bothering 'reflecting' it.



>>>> Oh, and IPv6 Errors (ICMPv6) are part of that flow, but the Flow
>>>> Label
>>> will not
>>>> include those.
>>>>
>>> 【Aijun】：ICMP Errors packets are often regenerated by the router, not
>>> the original data packet destination(3-tuple information has been
>>> changed). So the process for flow label reflection would be different
>>> and we will consider it more carefully later.
>>
>> As you are attempting to change this whole Flow Label mechanism (again),
>> please consider how to handle this _now_ and not another RFC later.
>>
>> The Flow Label for "flow identification" is useless without ICMPv6 Errors
> being
>> part of the flow as it typically indicates why that specific flow has
> ended.
>>
> 【Aijun】: The original flow info can be gotten from the message body of
> ICMP error message. As the RFC4443 section 2.4 sub clause c) 'description:
> "Every ICMPv6 error message (type < 128) MUST include as much of the IPv6
> offending (invoking) packet (the packet that caused the error) as possible
> without making the error message packet exceed the minimum IPv6 MTU", the
> (src,dest, flowlabel) of this part can be used to identify which specific
> flow cause the ICMP error.

While that is great. Load Balancers, those things that are described to
be the primary use of Flow Labels, do not do that. This as they do not
want to look beyond the first 40 bytes of the IPv6 header.

If they can look after the 40 bytes, then they can just as well check
the TCP and UDP ports. Why bother with a Flow Label?



> What we are considering is how to set the flow label value of the ICMP error
> message itself(the outer part). Does it need to copy the original packet's
> value or not.

It would be very useful. But it requires all the hosts in the world to
do so.

Seeing the little uptake of the last revision of the Flow Label
demonstrates that this is not going to happen.

Especially as folks are getting more and more privacy conscious. Note
that the IETF has a mandate around that too now.


>> In the case of IPFIX/NetFlow you will find that there you also get two
>> flows: one for instance for TCP and another for ICMPv6. Only the better
>> IPFIX/NetFlow analyzers out there are able to bind together the two so
> that the
>> first (the TCP Flow) has the detail of why it was ended (eg Port
> Unreachable).
> 
> 【Aijun】As you mentioned here, then it seems more reasonable to copy the
> flow label info of the original packet to the same field of its
> corresponding ICMP error message. The IPFIX/Netflow then can easily know
> which source, which flow cause the generation of ICMP error message. If you
> agree with this, we can add it into our draft later.

But that would require redefining the Flow Label completely and getting
that deployed world wide, which is not going to happen...

Note also that folks doing IPFIX/NetFlow already HAS the capability of
matching these up as processing IPFIX/NetFlow can be done really fast.

The problem is that one cannot do that at line-rate in a load balancer,
which will not bother with checking these things.


>>> For PTB error message in ECMP environment, especially for the load
>>> balancer before server farm, we recommend the load balancer to deal
>>> with specially such PTB error message, that is to say, send this error
>>> message to all servers that have the same address.
>>
>> And then an attacker sends a few thousand ICMPv6 PTBs and your load
>> balancer then nicely explodes that to the 1000 servers in the farm behind
> it,
>> yeah, that is going to scale.
>>
>> As you see, that is not an answer. No operator would want to see that.
>> They are much better off just limiting the Internet to a MTU of 1280 as
> that is a
>> safe thing to do.
>>
> 【Aijun】: The reason that I consider the servers in one cluster should all
> receive such PTB message is that if only one server receive and change the
> MTU of its output packet, when load balancer allocate to traffic to another
> server in next round, the new selected server will still encounter the PTB
> error message and increase the TCP and application process dealy.

The ECMP hash is stable. Thus unless the server is replaced with
another, thus the final/real destination will not change that often.

Much less often than broadcasting a single packet to all your 1000
backends at least.


> Actually,
> there may exist some attack explosion influences, but I think it should be
> considered and mitigated by the load balancer. 

The 'mitigation' at those speeds is: rate limit.

Hence, it will break various setups.

> The process of DHCP DISCOVERY/OFFER/REQUEST/ACKNOWLEDGE uses the similar
> notify mechanism, to inform other DHCP servers that one of the server in the
> broadcast domain has served the client.

DHCP is not done at several gigabits/second...


>>> Such method is more simple and less
>>> influences to redefine the meaning of this field.
>>
>> Your approach does not simplify anything.
>>
>> It does provide a great attack vector.
>>
>> As there are papers like this out:
>> http://christian-rossow.de/publications/amplification-ndss2014.pdf
>>
> 【Aijun】: I can't download this document, would you like to send it to me
> individually?

Google/Bing/Yahoo/etc for "Amplification Hell: Revisiting
Network Protocols for DDoS Abuse"

eg also at:
http://www.internetsociety.org/sites/default/files/01_5.pdf

There is lots of copies of this around as it is a really important
document to be aware of.

>> Operators will do anything to minimize any kind of amplification attacks
> on their
>> infrastructures.
>>
>>> Servers that receive the
>>> PTB error message should all reduce their following packet size
>>> according to the recommending MTU value.
>>
>> They MUST NEVER do that. They should only lower MTU when the payload
>> packet in the ICMPv6 matches a packet that they could have sent.
> 
> 【Aijun】: Please see the explain above.

That does not explain why you would want to restrict your whole server
farm to such a low MTU...


[..]
>> They will just do what they have been doing for well over a decade: src
>> + dst + proto + src & dst ports
>>
>> As that does give them a reasonable assumption of what they are looking
> at.
>>
>> The "Flow Label" is not giving them any details whatsoever.
> 
> 【Aijun】: we only need the "flow label" to identify one unique flow between
> two hosts. Based on the flow label filed and flow label reflection, the
> service provider need only do the deep analysis work once and can understand
> such traffic in other places, in both direction.  SFC, NFVRG etc. group can
> also benefit from this filed in future.

Here you state that they will do "deep analysis work".

Why do we need a Flow Label then?

Please note that a five-tuple is perfectly fine for making up a random
id so that one "only has to do deep analysis work once". This is what
people have been using for as long a they have been doing this kind of work.

Greets,
 Jeroen