This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
- Previous message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
- Next message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
sthaug at nethelp.no
sthaug at nethelp.no
Wed Jun 17 22:26:02 CEST 2015
> > Taking into account that stateless ACLs of all router vendors we > > tested (results tb published soon) can be avoided/evaded by adding ~5 > > extension headers to datagrams I fully understand any operator who > > does not want SSH on its devices to be reachable from the Internet > > (over v6 with extension headers) and hence acts in a way similar to > > the one Steinar described. > > There is a big difference between an operator dropping all packets with > EHs that are destined for *his own devices/routers* (I have no problem > with that - your devices, your rules), and an operator that drops > *transit* traffic destined for his customers because his routers cannot > understand/parse/filter its L4/EH payload. I certainly appreciate this distinction. However, problems arise in practice when customers *ask* for various types of protection - which are most sensibly implemented on border routers. Just to be clear - we don't drop IPsec traffic today (neither IPv6 nor IPv4). > In my opinion, an ISP/IP transit network shouldn't even attempt to > parse the L4/EH payload in customer traffic (except if the customer > asks for it of course), it should just deliver the packets. The problem is - the customer *does* ask for it, in many cases. > > I doubt Steinar loses many customers (due to "application breakage") > > by taking that path. In contrary I expect many of his customers > > valueing the increased level of device & network availability gained > > by eliminating an entire class of attacks. > > The first operator I mentioned above won't lose any customers because > his filtering activities doesn't impact customer traffic. The second > operator would lose my business, at least. And probably others' too, as > business customers might want their site2site IPSEC tunnels to work, > residental customers might want their Xbox One online gaming to work, > and so on. I agree - IPSEC tunnels and Xbox One online gaming need to work. That doesn't mean *all* extension header combinations should be expected to work - and it appears that they often don't. I expect we'll see much more of these discussions in the coming years, as IPv6 traffic grows. And I certainly also expect significant size IPv6 DDoS attacks - at least some of which will probably be based on extension header manipulation. Steinar Haug, AS 2116
- Previous message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
- Next message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]