DRKey usage

[aaronbojarski]

The DRKey system enables to use symmetric keys within a SCION network.
How the keys are derived or distributed is asymmetric. This is especially beneficial for a client-server setup where the server can efficiently derive the key and the client can ask for it from a trusted authority.

We now need to decide how the Lightning Filter (LF) should use the DRKeys. Which key is used (for incoming and outgoing packets)? Do we use different modes? This issue tries to explain the problem and give possible solutions.

For the following I assume that the LF has access to the HOST-AS keys for the HOST that it protects. It can therefore derive HOST-HOST' keys.

The Issue

Assuming the following setup where a client talks to a server and both are behind a LF instance.

+--------+    +-------+         +-------+    +--------+
| Server |    |  LF1  |         |  LF2  |    | Client |
| (HostS)|----|       |---------|       |----| (HostC)|
+--------+    +---|---+         +---|---+    +--------+
              (HostS-AS)        (HostC-AS)

The LF2 has access to the HostC-AS key and can therefore derive a HostC-HostS key.
It forwards the clients request authenticated with that key.

The LF1 has access to the HostS-AS key. This however does not help to derive the HostC-HostS key since it is not equal to the HostS-HostC key.
It therefore has to ask the control service for the key.
The same would happen in the other direction with the response from the server to the client.

This is obviously inefficient since two different symmetric keys are used and both LFs have to contact the SCION control service.
Therefore, there is no real benefit for the server side being able to derive keys efficiently.

Solutions

1. Different keys for incoming and outgoing traffic

Setup

This "solution" is what is described above as the issue. I mention it here again since this is not yet implemented and should therefore also be considered as an option.

Keys

Use own derivable key for outgoing traffic.
Fetch key from scion control service for incoming traffic.

Pro

• Only one LF configuration needed for server and client side.

Contra

• Unacceptable efficiency for server side.

2. Client Server setup with two LF modes

Setup

+--------+    +-------+         +-------+    +--------+
| Server |    |  LF1  |         |  LF2  |    | Client |
| (HostS)|----| Mode S|---------| Mode C|----| (HostC)|
+--------+    +---|---+         +---|---+    +--------+
              (HostS-AS)        (HostC-AS)

We still consider the client-server setup but to solve the issue we introduce two different modes for the LF.

"Mode S" means the LF runs in server mode. It will only use its own HostS-AS key to derive symmetric keys.

"Mode C" means the LF runs in client mode. It will ask for HOST'-HostC keys from the control service.
It then uses them to authenticate a request and caches them to be able to efficiently authenticate the response.
(LF in "Mode C" could also accept traffic authenticated with own HostC-HOST' keys. Not sure if there would be any drawbacks with that.)

This setup would allow the LF to be very efficient for the server side. It would still be acceptable for the client side assuming that not too many different servers are accessed at once. Which I think is a fair assumption in most cases.

Keys

Server side HostS-HOST' keys are used.

Pro

• Efficient.
• Relativly easy setup.

Contra

• Two different modes are needed.
• Mode needs to be configured.
• What happens if the server itself has to do a request to some other server. Which key is then used?
  • See 2.b)

2.b) Setup like 1. but using an additional LF for outgoing server requests.

Setup

+--------+    +-------+         +-------+    +--------+
| Server |    |  LF1  |         |  LF2  |    | Client |
| (HostS)|----| Mode S|---------| Mode C|----| (HostC)|
+---|----+    +---|---+         +---|---+    +--------+
    |         (HostS-AS)        (HostC-AS)
    |
+---|---+         +-------+    +---------+
|  LF3  |         |  LF4  |    | Server2 |
| Mode C|---------| Mode S|----| (HostS2)|
+---|---+         +---|---+    +---------+
(HostS-AS)        (HostS2-AS)

We still have a client-server setup but now the server also performs requests but to a different server "Server2".
Therefore, the server has an additional LF "LF3" that works in client mode. The server can direct his own requests to be sent through LF3.

Keys

Same as with 1. Server side HostS-HOST' keys are used.

Pro

• Efficient.
• Server can do requests.

Contra

• Server needs two LF instances.
• Server needs to send requests to different LF instance.

3. Consideration for applications already using SPAO

Setup

Client-Server setup from 2.

Applications that already add a SPAO header to the packets could be sent directly and not over the LF.

This could allow a server to make requests using a different symmetric key. However, the incoming traffic would still pass the LF and it therefore needs access to the key. This was just a thought but I wanted to at least write it down.

[fstreun]

Thank you for the detailed description of the problem and the possible solutions. I think it is very important to define clear use cases for LF, derive the requirements from them, and then further design the system accordingly.

I have a few questions and comments.

Terminology

... LF has access to the HOST-AS keys for the HOST that it protects. It can therefore derive > HOST-HOST' keys.

I assume that you are using the same notation as in the SCION DRKey documentation. In particular, the term on the left identifies the key issuer (the fast side in the derivation), whereas the right term identifies the key subject (the slow side in the derivation). Is that right?

What is the meaning of HOST'?

Use Case

Assuming the following setup where a client talks to a server and both are behind an LF instance.

In your setup, LF provides protection for client-server communications, whereas the client and server are clearly separated. I am curious about your thoughts on the placement of LF in the network (close to the server, close to the border router, etc.).

Do you consider LF as a network function that provides protection for the whole network of an AS? Or do you consider LF as a network function that provides protection for a small set of servers within an AS?

The Issue

The LF2 has access to the HostC-AS key and can therefore derive a HostC-HostS key. > It forwards the clients request authenticated with that key.

LF2 uses the HostS-HostC key (and not HostC-HostS) to authenticate to the forwarded client's request. Hence, LF1 can efficiently derive the key to authenticate the request efficiently. The issue is that LF1 cannot efficiently derive the key to authenticate the response. Or do I misunderstand something here?

Solution: 1

DITO as for the issue (it seems to be the wrong way around).

Depending on the use case, a non-blocking LF implementation might be sufficient. In this case, LF would not buffer outgoing packets if the required key is not in the cache. Instead, LF would simply forward the packets and fetch the key from the control service in expectation of more packets that require the same key. On the receiving side, LF would forward the packet without an authenticator on a best-effort basis. In case of an attack, LF would eventually obtain the key from the control service for the current traffic.

Solution: 2

Summary: Only use the level 3 key from the responder side (HostS-HostC) to authenticate the traffic. This solution assumes a clearly asymmetric client-server setup, where only the server side needs to authenticate arbitrary traffic efficiently without keeping state. The client side can keep a state of active connections and can authenticate traffic with cached keys.

I think we should clearly think about the implications of using the same keys for requests and responses.

Alternatively to the modes, LF could also handle packets differently depending on the direction and some information available in the packet:

• For incoming packets, depending on the key used, LF either derives the key (as on the server side) or looks for a key that is cached in the active connections (as on the client side).
• For outgoing packets, the packet must contain an indicator to differentiate between a request or a response (e.g., a flag in a pseudo-SPAO header). If the packet is a response, LF derives the host-host key. If the packet is a request, LF fetches the key from the control service and caches it for the response.

Solution: 2.b

Summary: Use a second LF instance on the server side to authenticate the server's requests.

I do not really like the idea of having two LF instances on the server side. This setup requires that traffic from the client C is routed through LF1, whereas traffic from the server S2 is routed through LF3, which might be more difficult in reality than expected. I think it is essential to keep the setup as simple as possible. Instead of having two LF instances, the server could add some indicators to the packets to differentiate between requests or responses.

Setup 3: Applications that already use SPAO

I think it is essential to consider the case where applications already use SPAO. In this case, LF does not need to buffer packets while waiting for the key from the control service, which I consider a significant advantage.

However, it is not clear how LF would obtain the key for the authentication of the response (if this is actually something we are concerned with).

Here are some ideas:

• LF could act as the key service for the client. In this case, LF would be aware of the keys that are used by the client and cache them accordingly.
• Outgoing traffic could still be routed through LF. In this case, LF would simply forward the traffic and fetch the key from the control service if it is not already cached. When receiving the response, LF might already received the key from the control service and can authenticate the response. Otherwise, LF would forward the response on a best-effort basis.

[aaronbojarski]

Thank you for your comments.

Terminology

I assume that you are using the same notation as in the SCION DRKey documentation. In particular, the term on the left identifies the key issuer (the fast side in the derivation), whereas the right term identifies the key subject (the slow side in the derivation). Is that right?

Yes I tried to use the same notation as in the SCION DRKey documentation.

What is the meaning of HOST'?

HOST' should just be some other host not equal to HOST. I just wanted to give it another name to differentiate it from HOST, since I also called what it protects the HOST.

Use Case

Do you consider LF as a network function that provides protection for the whole network of an AS? Or do you consider LF as a network function that provides protection for a small set of servers within an AS?

I am currently thinking of LF as a network function that provides protection for a small set of servers within an AS. This mostly comes from the Hercules use case we are currently trying to achieve. (High speed file transfer using Hercules and LF in conjunction, so both sender and receiver are protected by LF instance.)

However in a next step I also want to look at LF as a network function that provides protection for the whole network of an AS. There I assume the LF would have access to AS-AS keys. But the asymmetry we are discussing now still exists. Do you agree?

Do you think of LF more as an AS protection?

The Issue

LF2 uses the HostS-HostC key (and not HostC-HostS) to authenticate to the forwarded client's request. Hence, LF1 can efficiently derive the key to authenticate the request efficiently. The issue is that LF1 cannot efficiently derive the key to authenticate the response. Or do I misunderstand something here?

I see. You would assume that LF takes the own (derivable HOST-HOST) key to authenticate incoming traffic and therefore has to use the destinations (non derivable) HOST-HOST key for outgoing traffic.

My reasoning was that if the LF would only use its own HOST-HOST key, then we run into an issue. I was not thinking about which way around makes more sense. But to conclude, I think we are talking about the same thing.

Solution: 1

I agree this seems reasonable for some use cases. Thank you for forther expanding the solution.
Best effort if no key is available and key caching makes sense ans solves most of the issue.

However for a service that serves a lot of clients the caching of the keys might not be feasable. In that case it could happen that most packets are forwarded without an authenticator. Do you think this is an issue to worry about? Do you see a solution for it without an asymmetric setup like "Solution 2".

Solution: 2

I think we should clearly think about the implications of using the same keys for requests and responses.

Do you already see an issue here?

For outgoing packets, the packet must contain an indicator to differentiate between a request or a response (e.g., a flag in a pseudo-SPAO header). If the packet is a response, LF derives the host-host key. If the packet is a request, LF fetches the key from the control service and caches it for the response.

I like the idea. However that means that every service needs to explicitly differentiate between requests and respondses. (Or at least indicate that it is a response and use "request mode" per default.) Do you think this is doable? And I do not mean technically, I mean do you think that people are willing to use this?

Solution: 2b

Agree the setup is too complicated.

Solution: 3

However, it is not clear how LF would obtain the key for the authentication of the response (if this is actually something we are concerned with).

Agree. Not sure if this is relevant at this point.

[fstreun]

However in a next step I also want to look at LF as a network function that provides protection for the whole network of an AS. There I assume the LF would have access to AS-AS keys. But the asymmetry we are discussing now still exists. Do you agree?
Do you think of LF more as an AS protection?

With LF, we try to protect services from being flooded with a high number of packets/requests. For LF to be effective, the link/network to LF must be able to handle the attack traffic. For that, LF must likely be placed close to a border router and have access to AS-AS keys (or, better, to the AS key). LF would be capable of providing AS-wide protection, while stateful firewalls can provide additional protection for individual services.

Whether LF or another service should add the authenticator to the outgoing traffic is up for debate here.

I see. You would assume that LF takes the own (derivable HOST-HOST) key to authenticate incoming traffic and therefore has to use the destinations (non derivable) HOST-HOST key for outgoing traffic.

Yes.

LF has been designed to be able to statelessly authenticate any incoming traffic, respectively, with a manageable amount of state. To achieve this, it is essential which way around the DRKeys are used.

Solution 1

However for a service that serves a lot of clients the caching of the keys might not be feasable. In that case it could happen that most packets are forwarded without an authenticator. Do you think this is an issue to worry about?

I do not think this is a big issue:

• Firstly, LF only has to cache one key for each AS in which a client is located, and not for each client.
• Secondly, in case the number of ASes in which legitimate clients are located becomes too large for one LF instance multiple approaches could be taken:
  -- (prioritization) provide authentication only for limited number of ASes (e.g., AS with a lot of clients).
  -- (load balancing) deploy more LF instances, and devide traffic according to the AS number among them.

Solution 2

I think we should clearly think about the implications of using the same keys for requests and responses.
Do you already see an issue here?

No.

[...] that means that every service needs to explicitly differentiate between requests and respondses. (Or at least indicate that it is a response and use "request mode" per default.) Do you think this is doable? And I do not mean technically, I mean do you think that people are willing to use this?

I do not think that this solution should depend on other services to change their behavior. I think this could simply be an additional network function on the service's machine that adds the information to each outgoing traffic depending on the address and port it is coming from. For this to work, I assume that the address and port a service is listening on is only used for responses and never for requests. Do you think this is a reasonable assumption?

In case there is only a limited amount of publicly facing services (identified by some address and port), LF could also differentiate between requests and responses depending on the addresses.

[aaronbojarski]

I will try to summarize my understanding and what I think we currently agree on.

LF uses "its own" Host-AS key or AS-AS key for authenticating incoming traffic. For this it only needs to cache one key per AS and can then efficiently derive Host-Host keys.
The question of who adds the authentication to the packets is still open.

For our Hercules use case we will probably add the SPAO header directly in the application. The LF protecting the receiver will then check the authentication efficiently with the derivable Host-Host key.

Firstly, LF only has to cache one key for each AS in which a client is located, and not for each client.

Here I was thinking what happens if LF also adds the SPAO header. Then it would need to cache one key per client it is talking to since this key could not be derived efficiently by the LF. Here I assume that the LF does not have access to AS-AS keys.

For this to work, I assume that the address and port a service is listening on is only used for responses and never for requests. Do you think this is a reasonable assumption?

Agreed. However having a separate function that adds this info on the service's machine sounds cumbersome. I like the idea that LF differentiates by address and port better.

[fstreun]

SPAO on the client side

Here I was thinking what happens if LF also adds the SPAO header. Then it would need to cache one key per client it is talking to since this key could not be derived efficiently by the LF. Here I assume that the LF does not have access to AS-AS keys.

I agree, how the SPAO header is added is not clearly defined currently. As you described, this can either be done by the application itself, some services on the client's machine, or by some other service in the sender's AS, such as an LF instance.

In case an LF instance would add the SPAO headers for all traffic (in a non-blocking way), it is possible that not all DRKeys for all the flows can be cached. Possible solutions:

1. distributing the cached keys among multiple instances and route the outgoing traffic to the instance that has the key for the particular destination.
2. only cache keys with enough priority.

SPAO on the server side

Agreed. However having a separate function that adds this info on the service's machine sounds cumbersome. I like the idea that LF differentiates by address and port better.

I am not sure which is more cumbersome:

1. synchronize server IP addresses and ports with a LightningFilter instance on another machine
2. monitor server IP addresses and ports on the machine itself and adding some indicator to outgoing packets accordingly.

Both approaches require some application on the server's machine.

There are still some widely used protocols that do not use UDP or TCP (e.g., IKEv2). It will become quite complex if LF should be able to differentiate responses from requests from arbitrary protocols, while synchronizing the information with multiple servers. Offloading this logic to the servers themselves and having them add a "this is a response" flag, seems more scalable, more adaptable, and less complex for the LF implementation.

[aaronbojarski]

Thank you for your input and sorry for my late response.

I agree the "SPAO on the server side" variant stills seems a bit unpractical. We should discuss this further at a later point.

As I think you also discussed with Marc, we will for now add the SPAO header with LF.
In a use case like Hercules where there should be a fixed number of hosts a small cache should suffice.

As you might have seen, I am currently changing the DRKey derivation to the new format.
The plan is then to add a small cache for

1. Host-As keys to derive Host-Host keys for incoming traffic
2. Host-Host keys to be used for outgoing trafic

(For AS level LF there would of course still be an AS-AS key cache.)

Before the keys are cached they will be fetched from the Control Service.
Since DRKey is currently not deployed in a production system, we will also add the option to preconfigure AS-AS keys in the LF config.
This is to simplify the first initial deployment of Hercules and LF.