Re: Fwd: RFC 6980 on Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery

On Thu, Aug 15, 2013 at 03:28:41AM -0300, Fernando Gont wrote:

Thanks so much for your timely response! -- Please find my comments
in-line...

On 08/14/2013 08:06 PM, Hannes Frederic Sowa wrote:

quoted

On Wed, Aug 14, 2013 at 05:19:13AM -0300, Fernando Gont wrote:

quoted

Folks,

FYI. -- this is an important piece when it comes to First Hop (i.e.,
"local link") Security.

Thanks for the heads-up, Fernando!

I sketched up a patch to protect the receiving side. I still don't know if I
should make this behaviour default or configurable via a sysctl knob. I really
don't want to break existing installations.

Make it the default behavior. If anything, provide a sysctl knob to
override it.

Note: In the specific case of NS/NA messages, it's impossible nowadays
to find them fragmented in a real network (we don't even have options
(other than padding) to make NS/NAs grow so large!).

Yes, I also do favour making this the default behavior.

quoted

As an extra plus, we now discard packets with nested fragment headers at once.
Those packets should never have been accepted.

Is that the "goto fail_hdr" part in your patch?

Yes, still have to check if I should silently ignore them or generate a
parameter problem (that is the current behavior).

P.S.: What about RS/RA messages?

ndisc_rcv, which does now silently discard fragmented packets, is called
for the following types:

        case NDISC_ROUTER_SOLICITATION:
        case NDISC_ROUTER_ADVERTISEMENT:
        case NDISC_NEIGHBOUR_SOLICITATION:
        case NDISC_NEIGHBOUR_ADVERTISEMENT:
        case NDISC_REDIRECT:

So all packet types from RFC6980 should be covered (we do not support SEND,
yet).

Thanks,

  Hannes