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

["Aijun Wang" <[e-mail]>]

Hi, Jeroen

Please see the reply for your concern below.

> -----Original Message-----
> From: Jeroen Massar [mailto:[e-mail]]
> Sent: Monday, November 17, 2014 4:03 PM
> To: Aijun Wang; 'Sheng Jiang'; '6man WG'
> Subject: Re: draft-wang-6man-flow-label-reflection
> 
> 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?
> 
【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.  RFC6437 give detail the generation rule
for this field and why use this filed instead of the 5-tuple to identify one
specific flow:
 
   "Traditionally, flow classifiers have been based on the 5-tuple of the
source address, destination address, source port, destination port, and the
transport protocol type.  However, some of these fields may be unavailable
due to either fragmentation or encryption, or locating them past a chain of
IPv6 extension headers may be inefficient. Additionally, if classifiers
depend only on IP-layer headers, later introduction of alternative
transport-layer protocols will be easier."

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

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

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

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

> 
> > 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.  Actually,
there may exist some attack explosion influences, but I think it should be
considered and mitigated by the load balancer. 
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.

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

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

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

【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.
> 
> Greets,
>  Jeroen