[Nsi-wg] Security and Request Forwarding

[Hans Trompert]

Hi Henrik,

On 01/12/14 11:34, Henrik Thostrup Jensen wrote:
>
> (this is the first in series of three planned emails on security and
> pathfinding)
>
> I have been thinking about request proxying / forwarding (where
> request are simply forwarded to another NSA), and I think they form a
> potentially serious security risk an NSI system. The problem is that
> when we allow request forwarding it practicallyh impossible to stop a
> misbehaving NSA making requests as one cannot simply revoke access for
> that NSA, as the misbehaving NSA can have multiple vectors for making
> requests. The peers of an NSA, and their peers (and so forth), all
> have to revoke access for the misbehaving NSA. This requires a very
> high degree of coordination to do global access revocation within a
> small timeframe, which just isn't realistic.
>
> Consider the following setup (excuse my ascii art):
>
>   A
>  / \
> B   C
>  \ /
>   D
>
> If D wants to revoke access from A it has to isolate itself by
> revoking access from B and C.

No, D would ask both B and C to revoke their peers with A. Remember the
transitive trust principle here, it is not only true that I trust what
others send me but it is also true that I trust that my peers will take
corrective measures against an upstream NSA when I ask them to do so.

> When there is a tighly connected mesh, request forwarding is a very
> efficient attack vector to attack an NSI system. Only one NSA has to
> be compromised in order to get full access to the system. That is bad
> system design.
>
> This affects both tree and chain pathfinding: Tree relies on request
> forwarding in order to setup circuits on networks which is not
> directly available through control-plane peering. The consequence of
> disallowing request forwarding would be subpar circuit paths or not
> being able to setup paths due to reachability problems. Having all
> networks allow all other networks is not ideal either (but a solution
> none the less, and makes revocation possible). However that solution
> does not scale (similar to having all networks connect directly to all
> other networks).
>
> Chain relies on request forwarding to reach the source (or
> destination) of the circuit. From here on the request is broken up
> (chained). Chaining could be seen as a form of request forwarding, but
> unlike tree, endpoint authorization has to be done before the circuit
> can be setup (committed) end-to-end. This however, assumes that
> endpoint authZ is mandatory, which is currently not the case.
> Disallowing request forwarding, would that it might not be possible to
> setup circuits if the URA does not have a control plane peering with
> the NSA responsible for the source (or destination) STP.
>
> The fundemental problem here is really that we don't have a good
> security model for transit. BGP has similar conceptual issues, but the
> source and destination IPs are known, and filters are in place along
> with limitation such as max prefixes.

It is a pity that my connection trace got voted down during the last f2f
NSI meeting. The connection trace could be very helpful here, it will
show you how the message reached you and allows all NSAs along the way
to verify the correctness of the NSA ID of the sending NSA. This would
even allow you to implement a NSA blacklist if you want to protect your NSA.

> Currently we don't really have any policies or best practices in place
> for request forwarding either. Having "blind" forwarding as several
> NSAs implement it now poses a security as revoking access from a
> certain NSA is close to impossible (the only effective strategy is to
> leave the NSI system or split it somehow).
>
> I don't have a ready made solution to the issue. Proxy request
> forwarding has been an integral way in how we think about an NSI
> system for a long time. I do think the issue is moderately serious,
> and we should do something about it. In particular, I think we should
> try to leave the "setup the circuit with all possible means" and
> instead focussing on providing them in way that is responsible
> security wise.

We already have a way of authorizing STPs, currently this is only used
to authorize endpoint STPs, but as I have been advocating for some time
I believe that we will end up with some kind of authorization of
intermediate STPs as well. If a reservation request fails because of
lack of STP authorization then the message forwarding will stop at that
point.

Cheers,
    HansT.