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

[Jen Linkova <[e-mail]>]

On Wed, Jun 17, 2015 at 2:19 PM, Nick Hilliard <[e-mail]> wrote:
> On 17/06/2015 11:01, Jen Linkova wrote:
>> I'd like to point out that the problem is not specific to IPv6 at all.
>> How deep is MPLS label stack? Where are TCP flags or port number in
>> the packet (so I can match 'tcp established' or 'tcp 443')? oops, we
>> don't know....it depends...so some linecards do not copy enough data,
>> some (newer ones) do.
>
> bear in mind that each entry in the mpls label stack will be 4 octets,
> which gives.  An EH could be orders of magnitude larger.

Sorry, I should have made my point clear. What 'm trying to say is that:
1) if the current approach of 'copy X bytes to on-chip memory' there
is always a chance to receive a valid packet which requires more than
X bytes to be copied for correct processing.Therefore I believe we
should discuss how to handle such situation in general instead of
trying to find a magic value of X (I'd suggest 42 then ;)) and limit
all headers length by that number.
2) while just a few years ago you might see linecards which could look
at...how many? 64 bytes? into packets, nowadays they are replaced with
linecards which are able to look much deeper. So while protocol
designers should be aware of such limitation, absolute numbers are
increasing and the situation is improving (btw my measurements do show
that packets with 8 / 16 bytes EHs have much lower drop rate than
packets with 512/1024 bytes EHs, which I dare attribute to the hw
limitations).
3) I assume that vendors are developing hardware and software to meet
customers needs (more or less ;)) - 5 years ago who would need to look
deeper than 5 labels? so some linecards were quite upset to see such
deep label stack and might crash; now I'm told that 'we can inspect 10
labels easily because there are use cases'. Why could not we expect
smth like that happening if/when a use case for EH arises?


-- 
SY, Jen Linkova aka Furry