1. Elements of the PRP Philip Papadopoulos

2. DMZ 1 DMZ 2 DMZ 3 DMZ 4 Pacific Research Platform Traffic flows freely within the PRP Traffic can be impeded in/out of the PRP PRP Knits together DMZs Basic Tenets Within PRP, Traffic flows freely In/Out of PRP, traffic CAN be impeded Everybody has a different DMZ implementation. Solutions need to work for everybody Need to pay attention as to how much people time a “solution” requires

3. DMZ 1 DMZ 2 DMZ 3 DMZ 4 CRG 1 CRG 2 CRG 3 Pacific Research Platform Collaborating Research Groups - CRGs PRP Constructed with Specific Science Drivers Some of these groups need to “protect” their traffic Likely sharing modes that we need to support Share only within the group Share with anyone in PRP Share with anyone on Internet2 Share to the world

4. DMZ 1 vlan1-4 DMZ 2 DMZ 3 DMZ 4 vlan2-4 vlan4-3 vlan1-2 DMZ-to-DMZ implemented with VLANs R vlan2-3 vlan1-3 Each Site Border Router Knows All other VLANs R R R Traffic can be impeded in/out of PRP Pacific Research Platform Peering VLANs – Not Scalable We can build it this way, but take Frank W.’s comment about PRP is only 3 FTEs to heart.  We will need to develop mechanics to enable each site easily determine: Is the source/destination on the PRP? Is the source/destination a “partner” destination?

5. What are the mechanisms for managing PRP access? (and Monitoring Performance) Route advertisments? BGP has many control features (I’m not an expert in this area) My external view is that much of the “routing” security required can be accomplished with BGP, but it very very time intensive. A system similar to SciPass ? Identify “good” traffic and reroute around firewalls Is there anything inherent/clever that we could do with IPv6 addresses to identify something as “part of the PRP”? Can SDN (e.g. Openflow-enabled) hardware be of utility?

6. DMZ 1 DMZ 2 DMZ 3 DMZ 4 DMZ-to-DMZ implemented as v6-to-v6 Routing R Traffic can be impeded in/out of dDMZ IPv6 routing R R R Pacific Research Platform PRPv2 will be IPv6 ARIN ran out of v4 address blocks, last month. https://www.arin.net/resources/r equest/ipv4_countdown.html https://www.arin.net/resources/r equest/ipv4_countdown.html This is going to be hard transition for many software components. We (as a community) have to move to v6. Proposal is for PRPv2 to be IPv6 only.

7. DMZ Subnets and Hosts Rtr openflow SW FW Allowed List Flow Controller All DMZ-bound v6 Traffic Allowed Subnets updated from PRP registry Per Site Template for PRPv2 with flow-based firewall implemented with OpenFlow One idea: for Openflow-based firewall A PRP-allowed resources place an openflow Switch between their local DMZ and border router. A central (PRP-wide) registry identifies ALL PRP subnets Each site can upload (cryptographically secure) a list of their local PRP-enabled resources Local Flow controller can use a combination of central registry and local policy to decide on pass/fail of a particular flow Decision can be made on a per- flow basis, not a per packet basis.