Redundant paths with different segment IDs about scion

[aznair]

I'm not sure if this is related, but I did notice something a little troubling.
The code that generates interface IDs looks like this:
if_id = str(255 + int(ad_id) + int(nbr_ad_id))
This means the interface between ADs 11-14 and the interface between ADs 12-13 have the same ID (of course there are several other cases like this one as well).
I'm not sure if this actually causes a problem somewhere in the code but conceptually it seems wrong that two completely unrelated interfaces have the same identifier.

[aznair]

@pszalach

So I think I've got the problem narrowed down to two parts.

1. Race condition in _get_if_rev_token()
   This function is called in both the "BS PCB propagation" thread and "BS register segments" thread.
   Sometimes if we're unlucky both threads create a new revocation token, leading to two topologically equivalent paths.
2. PCBs carried over from previous iteration
   When SCION is run multiple times, it keeps a PCB from the previous iteration.
   So when beacon servers start up they register this PCB in the path server, then receive a newly created PCB from the core and register this as well, again creating two topologically equivalent paths.
   While clearing ZooKeeper every time is probably not a good approach, I think we need some way to prevent duplicate paths resulting from this carry-over behavior.

[pszal]

@aznair oh, right, probably zookeeper is a main culprit. Probably we should also keep (seeds of) revocation tokens in ZK. I'll think about that.
Yes, 1. looks as another potential problem.
Hopefully that's all, but maybe @shitz noticed such behavior previously?

[shitz]

I have not, but then I haven't looked to closely to be honest. 1) does
indeed sound like a problem, but it should be easily fixable with a lock.
2) sounds more serious and I can't say much about this, since I haven't
looked too closely at the ZK code so far.

On Tue, May 5, 2015 at 3:46 PM, pszalach [email protected] wrote:

@aznair https://github.com/aznair oh, right, probably zookeeper is a
main culprit. Probably we should also keep (seeds of) revocation tokens in
ZK. I'll think about that.
Yes, 1. looks as another potential problem.
Hopefully that's all, but maybe @shitz https://github.com/shitz noticed
such behavior previously?

—
Reply to this email directly or view it on GitHub
netsec-ethz#93 (comment).

[pszal]

I think that solution for 2. may be generating (seeds for) revocation tokens in a deterministic way. For example using AD's secret key and paths'id (get_hops_hash()).

[shitz]

You have to be careful though, since get_hops_hash() uses interface
revocation tokens and you might end up with a circular dependency. I could
see something like this working:

Seed for interface rev-token chain: secret-key + interface-ID
Seed for segment rev-token chain: secret-key + get_hops_hash()

However, you will run into problems when a hash chain gets exhausted, so
there needs to be some sort of versioning for the hash-chain as well.

On Wed, May 6, 2015 at 10:39 AM, pszalach [email protected] wrote:

I think that solution for 2. may be generating (seeds for) revocation
tokens in a deterministic way. For example using AD's secret key and
paths'id (get_hops_hash()).

—
Reply to this email directly or view it on GitHub
netsec-ethz#93 (comment).

[pszal]

Yes, I thought about something like that.
Probably, we will rotate the secret keys (~daily), hence it would help
with exhausted hash chain.

On 06.05.2015 11:32, shitz wrote:

You have to be careful though, since get_hops_hash() uses interface
revocation tokens and you might end up with a circular dependency. I could
see something like this working:

Seed for interface rev-token chain: secret-key + interface-ID
Seed for segment rev-token chain: secret-key + get_hops_hash()

However, you will run into problems when a hash chain gets exhausted, so
there needs to be some sort of versioning for the hash-chain as well.

On Wed, May 6, 2015 at 10:39 AM, pszalach [email protected] wrote:

I think that solution for 2. may be generating (seeds for) revocation
tokens in a deterministic way. For example using AD's secret key and
paths'id (get_hops_hash()).

—
Reply to this email directly or view it on GitHub
netsec-ethz#93 (comment).

—
Reply to this email directly or view it on GitHub
netsec-ethz#93 (comment).

[pszal]

please reopen if issue still exists