Subject: [ippm] draft-ietf-ippm-ioam-direct-export comments on security

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Fri, 31 Jul 2020 18:07:14 +0200

Greetings,

As promised in today's meeting, I had a look at draft-ietf-ippm-ioam-direct-export with an eye toward its security properties.

The security considerations section is a good start, but I still have the following issues with it:

(1) In order to mitigate the attacks described above, it should be
    possible for IOAM-enabled devices to limit the exported IOAM data to
    a configurable rate.

I'd like this to be a MUST, even though that's meaningless; SHOULD would be better than should. 

Rate limiting is one way to mitigate damage. There are others, and this text should point at some of them (e.g. only honoring DE on packets with certain configurable properties to require spoofing or injection to be more targeted, only keeping state for a certain number of flows), since relying only on rate limits essentially completes the DoS as a DoS defense. Something like "since devices handling DE and performing data export in response to a DE signal cannot authenticate that signal, these devices should be coded and tested defensively; i.e., as if they were on the open Internet without any perimeter protection".

(2) IOAM is assumed to be deployed in a restricted administrative domain,
    thus limiting the scope of the threats above and their affect.

I understand the architecture; note this will get pushback both in SECDIR and in IETF last call, as the idea of restricted administrative domains and the "hard perimeter/squishy middle" security model that comes with it is falling out of favor. See my comment above. 

Otherwise I think this is ready as it can be for security review.

Cheers,

Brian