Hi Joel,
[clipped]
> It seems
> to me that
> if an attacker is present on enough links for this to be a
> problem, then
> one has a lot more issues than just the preservation of
> adjacencies. In
> fact, using this attack calls immediate attention to the
> presence of the
> attacker. (It is not like a remote DoS or DDoS where the attack can
> continue once the victim is aware. network operators will be able to
> track this VERY fast.)
Yup, I agree. However, it is a cheap solution to a vulnerability that exists
and which has been mentioned in multiple documents.
This attack vector also appears to be in scope as per
draft-ietf-karp-threats-reqs-01.txt (sec 2.1).
Additionally you could also look at the section 3 of the above document which
says the following:
20. In most routing protocols (OSPF, ISIS, BFD, RIP, etc), all
speakers share the same key on a broadcast segment. Possession
of the key itself is used for identity validation and no other
identity check is used. This opens a window for an attack where
the sender can masquerade as some other neighbor. Routing
protocols SHOULD thus use some other information besides the key
to validate a neighbor. One could look at
[I-D.ietf-opsec-routing-protocols-crypto-issues] for details on
such attacks.
21. Routing protocols that rely on the IP header (or information
beyond the routing protocol payload) to identify the neighbor
which originated the packet must either protect the IP header or
provide some other means to identify the neighbor.
[I-D.ietf-opsec-routing-protocols-crypto-issues] describes some
attacks that are based on this.
This solution attempts to fix the above mentioned issues. If we think that such
attacks are NOT in scope of KARP then we need to remove them from the document
lest folks spend time working on them.
>
> Second, how would this be deployed? It requests a
This is an easy part and can be trivially taken care of once we decide that its
indeed a problem that we need work on.
> modification in the
> sender and receiver behavior for authentication. Is your assumption
> that this would be handled like a key change? First you
> upgrade every
> router on the LAN to be able to receive this, then you turn
> on sending
> it on the LAN? It seems to me that in terms of diagnosing
> communication
> failures one needs to be able to tell from packet traces
> which behavior
> is actually being used.
We could define a new authentication type, say 3, which would indicate that the
new mechanism (i.e. where Apad is not a constant but derived from source IP of
the packet) is being used.
>
> The third question is actually the most important. Given
> that operators
> would ahve to choose to enable this new behavior, is there any
> indication that they would do so? I have heard reports that some
> operators have started turning off IGP authentication, or
> using it only
> as a stronger packet checksum. In either case, this does not
> add value
> for those operators.
While I agree that some operators use authentication only for stronger checksum
there are some that care for security. I also agree that its not very simple to
launch these attacks, however, the idea behind this draft was as I had
explained earlier - it fixes a potential issue at zero (implementation,
computational and operational) cost that exists. My assumption was that if we
are repeatedly citing a vulnerability then there is a willingness to fix it
(see above).
Cheers, Manav
_______________________________________________
OSPF mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ospf
