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

[Mark ZZZ Smith <[e-mail]>]

      From: Gert Doering <[e-mail]>
 To: Mark ZZZ Smith <[e-mail]> 
Cc: Nick Hilliard <[e-mail]>; "[e-mail]" <[e-mail]> 
 Sent: Wednesday, 22 April 2015, 18:51
 Subject: Re: [v6ops] draft-gont-v6ops-ipv6-ehs-in-real-world: clarification text
   
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.

/ So would you expect all of your routers to be able to do this level of processing? It seems to me that you'd only need routers that can do that processing facing potential malicious sources e.g. transit, peering, and possibly customer (although customers have a strong disincentive because it is in their interests for the router to stay available). I wouldn't think it would be worth the expense to have this level of hardware filtering available on core routers.


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'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
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                  HRB: 136055 (AG Muenchen)
Tel: [phone]          USt-IdNr.: DE813185279