Re: [RAM] ITR complexity & security (ICMP) in LISP-NERD/CONS & eFIT-APT

    > From: Robin Whittle <rw@firstpr.com.au>

    > .. handling ICMP DU messages regarding reachability and Path MTU
    > Discovery.
    > The only way I can imagine these being handled securely seems to
    > involve an impractically large amount of state and processing.

I'm a bit too crunched for time to really understand this entire message, but
I was wondering if you have considered the following approach to this problem:

All ITRs/ETRs have their interfaces which face toward the 'core' (i.e. the
other ITRs/ETRs in the system) have addresses from some reserved part of the
address space (e.g. net 10), addresses which are not functional on the 'site'
side of the ITRs/ETRs. (I.e. you can't send a packet to one of the addresses
from inside a site.) The ITRs only accept reachability DU messages on those
interfaces, destined to the addresses from the reserved space.

In other words, there's no way to send them one of these DU packets from a
customer site. This should be easier than carefully validating each
individual DU, and keeping enough state to do so, right?

Yes, this still allows a compromised ITR/ETR to generate bogus traffic, but I
think it's a useful reduction in the threat universe.

I don't have any clearest best idea on how to validate incoming DU messages
from other ITRs/ETRs... Maybe a per-ETR nonce (i.e. only a slight amount of
increase in the state in the ITR), which is included in each tunnelled
packet, or something like that. If it's 32 bits, and changed every 10
seconds, it would be hard to find by generating random values (and in any
case the incoming errors could set off alarm bells), and even if it were
found, it would only give you a break-in for a few seconds.

In short, I agree this is a problem, and one that needs a solution, but
I'm not sure the mechanism you posit is the best solution.

In part, you seem to be trying to solve it without changing the protocol
(i.e. packet format), and I think that's too hard a constraint. If you really
need a screwdriver, go buy one, don't try and make do with a hammer.

	Noel

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram