[j-nsp] EX3300 family ethernet-switching IPv6 matches?

[Saku Ytti]

On (2014-01-09 16:47 -0800), Han Hwei Woo wrote:

> I believe you're looking for next-header
> 
> e.g. set from next-header tcp

I know this is known already to many, but I still feel it's important to keep
reminding. 'next-header tcp' is different thing than 'protocol tcp'.

'next-header' strictly verifies static byte place in ipv6 header and what it
says, if you carry EH, it does not say TCP, and the match is negative, even
though ultimately EH tells next-header tcp.

This means you must not build FW filters like this

1. permit smtp/tcp to my.smtp.server.com
2. deny smtp/tcp to all
3. permit rest

The key here is 'permit rest', these kind of FW must not exist in Juniper in
IPv6, as all subsequent L4 'deny' statements can be bypassed by inserting
single EH, causing deny to not match, falling to ultimate permit statement.
Far end server will be able to parse EH and will treat the packet as normal
TCP header.

This is not inherently so, JNPR can fix this in devices like Trio/MPC if there
is sufficient business motivation to do so.
I'm not blaming JNPR, IPv6 was designed in an era where HW implementation was
not consider, making it in many ways very badly scaling/insecure protocol when
implemented in HW (SLAAC, L2 mcast snooping, EH)

-- 
  ++ytti