Re: [v6ops] Extension Headers / Impact on Security Devices

On 26/05/2015 17:27, Mark ZZZ Smith wrote:
> 
> 
> 
> 
> ________________________________
> From: Eric Vyncke (evyncke) <evyncke@cisco.com>
> To: Tim Chown <tjc@ecs.soton.ac.uk>; Joe Touch <touch@isi.edu> 
> Cc: "v6ops@ietf.org" <v6ops@ietf.org> 
> Sent: Wednesday, 20 May 2015, 22:28
> Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
> 
> 
> On 20/05/15 10:14, "Tim Chown" <tjc@ecs.soton.ac.uk> wrote:
>>
>> The other question is what existing work is being done that relies on the
>> correct (desired) operation of EHs? The two that would spring out would
>> be segment routing and sfc, at least one of which is using the existing
>> Routing Header. If such protocols are constrained to specific
>> administrative domains then their successful operation I would assume is
>> down to specific EH handling in the equipment in that domain, and its
>> capabilities, rather than (undesired) operator filtering somewhere
>> between sender and receiver.
> 
> The primary use case of segment routing is indeed within a single
> administrative domain, so, EH does not cause a problem.

I've lost track of who wrote that (Tim?), but it's only true if
all middleboxes respect RFC 7045, especially the bits about what
needs to be configurable and what the factory defaults should be.

> OTOH, this whole discussion is pretty close to having a discussion on
> whether an ISP should block everything which is neither UDP nor TCP? Or
> block currently-unallocated TCP/UDP ports? (and I appreciate that there
> are differences of course).

Again: all these choices need to be configurable, so that providers
can make their own choices and decide what to break. I assume that
discussion belongs in opsec.

   Brian

> 
> 
> / +1
> 
> / In my opinion a huge amount of security context is missing from this discussion, to the point where the question has been simplified to a too simplistic and binary EHs or not question, and there is never going to be consensus on that question.
> 
> / There seems to be an underlying and unstated set of assumptions behind the sorts of "block EHs","must be able to look at TCP/UDP headers in the network" questions/statements : 
> 
> / (a) the network is the only place that network, host and application security can and must be done, implying that hosts and applications do nothing to protect themselves
> / (b) that the contents of packets will always remain transparent to the network, allowing them to be inspected in the network
> / and (c) that all traffic to and from a host/application will always traverse a single inspection/choke point in the network and will always use the same Internet protocol.
> 
> 
> 
> / I think all of the above assumptions were true up until about the mid 1990s (if I remember well enough). Since then, they've all become false to varying degrees. Consequently, a choke point in the network may not be the best place to perform all network, host and application security measures, and in some cases persisting with that model will cause security failures. (For example, it seems that hosts aren't the lowest hanging fruit for network delivered malware any more, it is residential CPE itself - the device that is supposed to be so effective at providing "security" (including implicitly via NAT) that theoretically downstream hosts don't need firewalls at all.)
> 
> To Enno's original point: it is fair for a destination domain to handle
> (permit, drop, log, inspect) incoming (or outgoing BTW) packets based on
> layer-4 ports, layer-4 protocols or extension headers. This is their own
> responsibility
> 
> -éric
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 