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

[Joe Touch <[e-mail]>]

On 4/21/2015 11:35 AM, Joel M. Halpern wrote:
> The need to protect the control plane components (routers, controllers,
> whatever you want to call them) from overload is a well-established
> practice in the industry.  It is expected by operators when they buy,
> and delivered by all major vendors in the devices they build.
> 
> Given that until recently it has been a behavior inside a device, no, it
> is not documented inan RFC.  That does not mean it is untrue or
> unrealistic.

I don't disagree. But it is an E-ticket ride - it is inherently expensive.

I don't object to ops docs that say "this is hard", but I do think it's
not productive to say "and we should make the protocol easier by gutting
the hard parts" unless there is a rationale - one that presumably
doesn't rely only on "because it's hard".

Because that just translates to "because I'm greedy".

Here's an analogy:

	Cars advertise seating capacity.

	It's unrealistic to expect every 4-person car to
	fit four 600-pound people.

	It's equally unrealistic to redefine "person" to
	mean "110-pound model".

There needs to be a balance between what's expensive and inconvenient
vs. neutering a protocol to make it easy to implement.

Protecting the control plane can be done by the receiving host
(destination router). Protecting the network from sending traffic that
is dumped at the destination is certainly a useful capability, but not
to protect the destination router. It protects the network as a whole.

Protecting the network as a whole is useful, and may involve some level
of DPI - or may not. If the traffic is encrypted, then only the
destination router can protect itself anyway. But dropping the packets
because of EH use just makes the filtering router an attacker to the E2E
communication between the routers.

Joe