Re: Next steps on Extension Header Insertion

[Fernando Gont <[e-mail]>]

On 11/03/2016 10:39 AM, [e-mail] wrote:
>>> PS: As an operator would you be happy if I sent packets with NH=59, SA=:: with an integrity check covering all fields apart from the HLIM field, and everything else beyond the IPv6 header (40 bytes) was encrypted?
>>
>> Hmmmmm. Interesting question. As a network operator I'd probably drop that packet because of BCP38. As a security engineer I would be scratching my head and wondering what was going on. But effectively the payload wouldn't be that different from ESP...
> 
> If you dropped it because you looked beyond the 40 bytes IPv6 header that does violate the IPv6 specification.
> You can argue even looking violates the specification.

I think you're missing two different things. Dropping such packet is a
matter of policy. Where modifying packets on the fly can introduce
problems difficult (if at all possible) to troubleshot, for no evident
reason.

>From draft-gont-opsawg-firewalls-analysis-02:

---- cut here ----
3.3.  Firewalls and The End-to-End Principle

   One common complaint about firewalls in general is that they violate
   the End-to-End Principle [Saltzer].  The End-to-End Principle is
   often incorrectly stated as requiring that "application specific
   functions ought to reside in the end nodes of a network rather than
   in intermediary nodes, provided they can be implemented 'completely
   and correctly' in the end nodes" or that "there should be no state in
   the network."  What it actually says is heavily nuanced, and is a
   line of reasoning applicable when considering any two communication
   layers.

      [Saltzer] "presents a design principle that helps guide placement
      of functions among the modules of a distributed computer system.
      The principle, called the end-to-end argument, suggests that
      functions placed at low levels of a system may be redundant or of
      little value when compared with the cost of providing them at that
      low level."

   In other words, the End-to-End Argument is not a prohibition against
   lower layer retries of transmissions, which can be important in
   certain LAN technologies, nor of the maintenance of state, nor of
   consistent policies imposed for security reasons.  It is, however, a
   plea for simplicity.  Any behavior of a lower communication layer,
   whether found in the same system as the higher layer (and especially
   application) functionality or in a different one, that from the
   perspective of a higher layer introduces inconsistency, complexity,
   or coupling, extracts a cost.  That cost may be in user satisfaction,
   difficulty of management or fault diagnosis, difficulty of future
   innovation, reduced performance, or something else.  Such costs need
   to be clearly and honestly weighed against the benefits expected, and
   used only if the benefit outweighs the cost.

   From that perspective, introduction of a policy that prevents
   communication under an understood set of circumstances, whether it is
   to prevent access to pornographic sites or to prevent traffic that
   can be characterized as an attack, does not fail the End-to-End
   Argument; there are any number of possible sites on the network that
   are inaccessible at any given time, and the presence of such a policy
   is easily explained and understood.

   What does fail the End-to-End Argument is behavior that is
   intermittent, difficult to explain, or unpredictable.  If a site can
   be reached sometimes and not at other times, or can be reached using
   this host or application but not another, one will wonder why that is
   the case, and may not even know where to look for the issue.
---- cut here ----



-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492