Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text

[Ray Hunter <[e-mail]>]

Gert Doering wrote:
> Hi,
>
> On Wed, Apr 22, 2015 at 06:20:00AM +0000, Mark ZZZ Smith wrote:
>> So I'm going to call the emperor naked.
>> What I think you and Gert actually want is for EHs to be completely
>> deprecated, so that the TCP and UDP headers are always in the same
>> place in the packet, so that hardware can look at them for the
>> purposes of dropping them in hardware or as inputs into LB. Is that
>> the case?
>
> No :-) - Hardware *is* sophisticated today, but only up to a certain limit.
>
> What I think would be implementable with reasonable tradeoffs between
> "unsane hardware effort that my end customers are not going to pay" and
> "still flexible" is to require that the final EH is contained in the
> first<n>  bytes (say, 512) and that the final header must be in the
> first fragment.
>
> Right now, we have "the packet can have any size, and the final header can
> be anywhere" - and doing that in hardware is just too expensive.
>
>> What I'm curious about then is how do you handle DDoSes that are
>> using IP fragments, where there are no TCP or UDP headers ports to
>> look at?
>
> That is actually quite easy: rate-limit fragments against the control plane,
> and drop first fragments if there is no L4 header inside.
>
> (The thing is: not all packets are equal - for some, like ICMP, you want
> to permit them towards the control plane up to a certain limit - say,
> 10 Mbit/s, sufficient to permit people to do network testing, but not
> to overwhelm your control plane link or CPU.  For others, like BGP from
> established peers, you take what they give you, because it speeds up
> convergence.  BGP SYNs, rate-limit.  And so on)
>
I do think there's a strong need to differentiate between
i)  packets switched by a device (e.g. normal unicast),
ii) packets switched by a device but which require some local action 
(e.g. replying to an ICMP packet with a hop limit expiry, or processing 
hop by hop options which are anyway an allowable exception in RFC7045), and
iii) packets destined for the device itself as an end host (e.g. BGP 
session).

Which to me suggests that the correct fix to this problem is that a 
hardware vendor worried about control plane performance can introduce a 
queueing mechanism between any fast path switch fabric and any slower 
control plane, in a similar way to implementing WRED or other queuing 
mechanisms on outgoing interfaces. Packets containing "excessive EH" 
would then probably be placed in one of the slow/high drop probability 
queues.

So I really do understand the desire to protect any slow path, but I 
don't see this as an IPv6 protocol issue.

IMHO I think this problem was already fixed at the protocol level by 
https://tools.ietf.org/html/rfc7112

>> I'm also curious about how you LB packets (either at layer 2 or
>> layer 3) that don't have TCP or UDP headers, or aren't IP. I've
>> seen LB become completely ineffective at layer 2 because a customer
>> was using MPLS between two routers, so no MAC address variation,
>> and no IP addresses and no TCP or UDP ports to look at.
>
> This is actually a hard problem in the generic case.  If the hardware can
> find reasonable discriminators, you can hash based on that (like, MAC
> addresses in Ethernet-over-MPLS packets) - if not, fall back to flow label
> or "src/dst MAC address", which is usually a spectacularily bad idea
> between routers.
>
> [..]
>> "LAG is good, but it???s not as good as a fatter pipe."
>
> True.  But sometimes life is not nice, and you have to live with what
> you have - like, you can get 2x 10G wavelength between cities, but not
> 40G or 100G, or your equipment just cannot handle 40G/100G.
>
> Gert Doering
>          -- NetMaster