[Nsi-wg] Security and Request Forwarding

Henrik Thostrup Jensen htj at nordu.net
Mon Dec 1 05:34:48 EST 2014


Hi

(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.

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.

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.


     Best regards, Henrik

  Henrik Thostrup Jensen <htj at nordu.net>
  Software Developer, NORDUnet



More information about the nsi-wg mailing list