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

[Jeroen Massar <[e-mail]>]

On 2014-11-17 02:10, Aijun Wang wrote:
> Hi, Jeroen
> 
> Please see the reply inline below.
> 
>> -----Original Message-----
>> From: Jeroen Massar [mailto:[e-mail]]
>> Sent: Saturday, November 15, 2014 10:51 AM
>> To: Aijun Wang; 'Sheng Jiang'; '6man WG'
>> Subject: Re: draft-wang-6man-flow-label-reflection
>>
>> On 2014-11-15 02:05, Aijun Wang wrote:
>>> Hi, Jeroen:
>>>
>>> Service Provider wants to apply the same policy to the upstream and
>>> downstream of one session, or more accurately, apply the policy to
>>> downstream of one session based on the recognition of it upstream
> packet.
>>>
>>> The flow label can be used to identify the unique session between one
>>> pair of IPv6 hosts, and alleviate the burden for the network device to
>>> recognize the downstream packet, for example, http response packet. We
>>> think this is one appropriate use case for the flow label.
>>
>> The Flow Label as defined tells you nothing about the contents of the
> flow.
>> Hence nothing to prioritise on there. You will still have to look at the
> typical five
>> tuple and likely deeper when everything is just going to look like HTTP.
>>
> 【Aijun】: with the reflection mechanism, we only need to the deeper
> information of upstream packet, not necessary for the corresponding
> downstream packet. For downstream packets of the same session, the 3-tuple
> info(src, dst, flow label) is enough for upper layer traffic recognition. 

It will be enough IF the source host sets it AND the destination
reflects it. As the redefinition of the Flow Label (the bunch of RFCs
from end of 2011) have not made it into hosts stacks yet almost 3 years
later and lots of people do not upgrade. When do you expect this to happen?

But more importantly, do you think the Operator community can actually
use it?

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.


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


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

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


> 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

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.

Though indeed, the only thing that could happen is that the MTU becomes
1280, that is still a bad idea.

As most stacks stuff the Path MTU in a per-destination route though
those hosts likely do not have an entry and it would be discarded anyway.

>> And as you say "Service Provider" though, sounds like you are opening that
> can
>> of worms called Net Neutrality.
>
> 【Aijun】: SFC, NFVRG etc group in IETF are all considering how to deal with
> various traffic flow in more flexible manner, this is the development trend.
> It is not enough for service provider to consider only the ip src and ip
> dest information. 

Indeed just the src/dst pair is not enough.

But realize that an extra random number ("Flow Label") chosen by the
source host is not going to give these kind of folks the information
they want anyway.

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.

Greets,
 Jeroen