Hi
(part two of the security and pathfinding)
We are currently treating exchange points like switches (which is not really
that weird, as that is what they are). Specifically, we are treating them as an
independent domain, which does not reflect that the ports on exchange is leased
by the connecting network, and hence be under control of the NSA of that
network.
Allowing a third party NSA to create circuits on an exchange to another
networks port violoates the simple principle that an NSA should be in charge of
the networks resources. This means that a network can no longer decicde how it
wants to allocate its resources, which is pretty bad. There are some potential
solutions to this like allocating a static vlan range to a certain
network-network combination, but it is inefficient resource-wise.
Requiring a token is another possiblity, but adds much complexity, as the token
must be aquired apriori. As there is no standard mechanism in place for
acquiring these, it would often end up being a long-lived token with wide
permissions, which is less than ideal security-wise.
The following presents a scheme that keeps the port under control by their
respective NSA, doesn't require any static pre-allocation, and does not require
any out-of-band token distribution. It can be seen as a standard mechanism for
acquiring a token for setup. It does change the path setup flow somewhat, and
requires special behavior for the exchange NSA, and the pathfinders using it.
Finally it requires a control-level peering between the two NSAs responsible
for the networks connecting to the exchange.
We have the following scenario:
Two networks: A & B
One exchange: X
The networks connect to the exchange on port X.A and X.B.
NSA for network A, wants to setup a circuit from A to B over the exchange.
The NSA for the exchange knows the identities of the NSAs for Network A & B,
but will only allow them to allocate resource on their port. Having an exchange
NSA operate in this manner is essential, as networks should only be able to
allocate resources on their own ports (I don't consider the exchange backplane
to be an issue here, usally congestion happens on the links).
The circuit is setup on the following way:
NSA for Network A, requests a circuit on the exchange from port X.A to a
logical/virtual STP, named X.IC (for interconnect) in this example. The NSA for
X recognizes that NSA A has the right to allocate resouces on port X.A, and
grants the request. The STP returned for X.IC, is not X.IC, but instead X.A
with a label (or token) on it. This label is randomly generated, and cannot be
guessed (it could be a UUID, but it doesn't matter).
Hereafter NSA A, makes a request to NSA B, with the newly created STP (with
token), to create a circuit (could be tree or chain, doesn't matter), lets say
it connect to B.P. NSA B will split this request up into two requests: One to
NSA X for X.A to X.B (using the token, NSA X allow using X.A, and the NSA B is
allowed to use X.B), and an internal link from X.B to B.P. When both requests
have completed, a reply is send to NSA A.
A perhaps more comprehensible version of the example:
1: Request from NSA A to NSA X:
Reserve: X.A -> X.IC
Response: X.A -> X.A?token=a5cbdf88-73e0-11e4-a1b3-f0def14b5d43
2. Reserve from NSA A to NSA B:
Reserve: X.A?token=a5cbdf88-73e0-11e4-a1b3-f0def14b5d43 -> B.P
2A: Request from NSA B to NSA X:
Reserve: X.A?token=a5cbdf88-73e0-11e4-a1b3-f0def14b5d43 -> X.B
Response: X.A - X.B
2B: NSA B Interal Reserve:
Reserve: X.B -> X.P
Response: X.B -> X.P
Response: X.A -> B.P
Using this schema we avoid the situation where third party NSAs can allocate
resource on networks without going through the NSA of the network.
For the scheme to work, NSAs operating exchange points need to change the
behavior of what they allow and how links are set up. Furthermore, they need to
advertise this behaviour through their discovery service.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net>
Software Developer, NORDUnet
FYI. This project is closely related to GENI and may be of interest to the NSI-WG for testing.
Any feedback on new or existing projects that we should call to the attention of the OGF community at large for testing purposes or any other related topic for useful or related projects would be helpful.
Alan
Begin forwarded message:
From: Robert Ricci <ricci(a)cs.utah.edu>
Subject: [cloudlab-announce] CloudLab is up and running
Date: December 16, 2014 at 12:09:10 PM CST
To: <announce(a)cloudlab.us>
Reply-To: <contact(a)cloudlab.us>
We're happy to announce that CloudLab is up and running, and ready to
accept users! Sign up for an account at:
https://cloudlab.us/signup.php
Many things are still in an early state, but we have enough in place for
you to start getting some real work done. The cluster at the University
of Utah is up, and clusters at Wisconsin and Clemson are coming soon.
We have example profiles that provision bare-metal nodes and full,
dedicated installs of OpenStack to get you started quickly. You can
define experiments through CloudLab's GUI and provision both hosts and
networks. You can also try out alpha-stage features like defining
profiles through Python scripts. Coming in the near future are versioned
images and profiles, persistent block storage, and quick profile
creation.
Come give it a try!
Our user manual, including a "getting started" chapter:
http://docs.cloudlab.us/
Descriptions of the clusters that we have up and on order:
http://docs.cloudlab.us/hardware.html
Join our community mailing list:
https://groups.google.com/forum/#!forum/cloudlab-users
[You're receiving this message because you signed up for the
cloudlab-announce list. To be removed from the list, simply send a
message with the subject 'remove' to <announce-remove(a)cloudlab.us>]
Hello All,
The GWD-R document: 'Network Service Interface, NSA Description Document' has now been submitted to Richard Hughes-Jones (OGF area director for infrastructure) to review before going out to public comment.
You can download this document here: https://redmine.ogf.org/dmsf_files/13338
Guy
_____________________________________________________________________
Guy Roberts PhD
Senior Transport Network Architect
GEANT Limited
Email: guy.roberts(a)dante.net<mailto:guy.roberts@dante.net>
Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417
GEANT Limited is part of the GÉANT Association
Networking. Services. People
Learn more at: www.geant.org<http://www.geant.org/> and www.dante.net<http://www.dante.net/>
GEANT Limited registered in England & Wales. Registration Number 2806796.
Registered Office - City House, 126-130 Hills Road, Cambridge CB2 1PQ
_____________________________________________________________________
.... is available here:
https://redmine.ogf.org/dmsf_files/13381
_____________________________________________________________________
Guy Roberts PhD
Senior Transport Network Architect
GEANT Limited
Email: guy.roberts(a)dante.net<mailto:guy.roberts@dante.net>
Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417
GEANT Limited is part of the GÉANT Association
Networking. Services. People
Learn more at: www.geant.org<http://www.geant.org/> and www.dante.net<http://www.dante.net/>
GEANT Limited registered in England & Wales. Registration Number 2806796.
Registered Office - City House, 126-130 Hills Road, Cambridge CB2 1PQ
_____________________________________________________________________
The following is dial-in information for Wednesday's NSI call, time:
7:00 PDT 10:00 ET, 15:00 GMT, 16:00 CET, 24:00 JST
1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#"
Agenda:
- All to update their progress on NSI documentation
- Security and request forwarding (discussion initiated by Henrik on mailing list)
- John to update on his work on STPiD update to NSI extensions document.
_____________________________________________________________________
Guy Roberts PhD
Senior Transport Network Architect
GEANT Limited
Email: guy.roberts(a)dante.net<mailto:guy.roberts@dante.net>
Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417
GEANT Limited is part of the GÉANT Association
Networking. Services. People
Learn more at: www.geant.org<http://www.geant.org/> and www.dante.net<http://www.dante.net/>
GEANT Limited registered in England & Wales. Registration Number 2806796.
Registered Office - City House, 126-130 Hills Road, Cambridge CB2 1PQ
_____________________________________________________________________
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
There will be no NSI call this week, next call will be at the usual time on Wednesday 10th Dec.
Guy
_____________________________________________________________________
Guy Roberts PhD
Senior Transport Network Architect
GEANT Limited
Email: guy.roberts(a)dante.net<mailto:guy.roberts@dante.net>
Tel: +44 (0)1223 371316 Mob: +44 (0)7881 336417
GEANT Limited is part of the GÉANT Association
Networking. Services. People
Learn more at: www.geant.org<http://www.geant.org/> and www.dante.net<http://www.dante.net/>
GEANT Limited registered in England & Wales. Registration Number 2806796.
Registered Office - City House, 126-130 Hills Road, Cambridge CB2 1PQ
_____________________________________________________________________
