[ippm] Update on draft-ietf-ippm-ioam-data-integrity

[Justin Iurman <[e-mail]>]

Hi folks,

Following secdir review, we are working on a draft revision. We would 
like to share different solutions, based on trade-offs we are facing, 
and get some feedback/opinions from the WG. The real challenge is to 
have something deployable/efficient for the integrity protection of 
Trace Option-Types (other Option-Types are OK), and which does the 
expected job. Right now, we have three possibilities for Trace 
Option-Types, each listed with their pros and cons:

1) Current method proposed in the document, i.e., a full chain 
validation at the end (i.e., on the Validator).

(+) full integrity protection
(-) not efficient
(-) consumes more bytes, different header compared to other Option-Types

This solution is messy but does the (full, expected) job. It does not 
trust any nodes (even IOAM ones) and would detect any compromised nodes. 
Why is it messy? Because the entire chain validation is performed at the 
end on the Validator, which is of course not efficient, and because it 
requires an additional Nonce/ICV to distinguish the integrity of the 
header and IOAM-Data-Fields (i.e., each transit nodes must be able to 
check the header integrity independently). Note that the Validator 
problem could be mitigated by, e.g., (i) having the Validator out of the 
forwarding path and (ii) having multiple Validators.

2) Ben's suggestion, i.e., a per hop validation.

(+) more efficient than solution 1
(+) same integrity header for all Option-Types
(-) partial integrity protection (i.e., we trust IOAM nodes)

This solution solves all problems encountered in solution 1 and is 
elegant, *but* it does "half" the job (i.e., we trust IOAM nodes, which 
means that if an IOAM node is compromised, we wouldn't be able to detect 
tampered IOAM data).

3) IPsec (i.e., sunset this draft).

+ pragmatic approach which does not require any new protocol definition
+ less overhead than solution 1
- requires additional configuration effort (setup IPsec tunnels)
- partial integrity protection (i.e., we trust IOAM nodes)

This solution is quite similar to what solution 2 proposes, here without 
the need for a new protocol, but which probably introduces more 
overhead. For each link that connects to nodes, configure an associate 
IPsec connection - and implement IOAM on top of the IPsec topology. As a 
result, each link will be encrypted and/or integrity checked and man in 
the middle attacks are not feasible. Which also means that we would 
sunset this draft.


So I guess it all comes down to choosing between solution 1 and solution 
3 (solution 2 may be better than solution 3 but, given the similarities, 
solution 3 would probably be chosen for simplicity). The key question 
is: do we want full or partial integrity protection? And, based on that, 
consider the impact of such a choice: is it efficient and/or deployable?

We would really appreciate your comments or feedback on this.

Thanks,
Justin