Subject: Re: [karp] KARP-KMP for pair wise routing protocols (traffic selectors)

From: Sam Hartman <[email-masked]>
Date: Thu, 03 Nov 2011 17:22:23 -0400

>>>>> "Russ" == Russ White <[email-masked]> writes:

    Russ> For what it's worth, I will agree with Sam here. At some point
    Russ> in the future you might want to be able to have multiple
    Russ> sessions running between the same pair of peers, and have them
    Russ> authenticated separately.  

Russ, as part of designing a KMP proposal we've tried to come up with a
situation where an operator would like to do this.  So far we've failed.
We can easily come up with reasons to have multiple sessions between two
peers.  So far though, we've been unable to come up with reasons why
you'd want to use different authentication for these two sessions.
Can you help us with use cases?

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sun, 6 Nov 2011 07:18:45 +0530

Hi Sam,

I'm thinking aloud here.

Consider the following topology:

S1a -- B -- C -- S2a
       |    |
      S2b  S1b

S1a and S1b are two routers belonging to the same site S1, and S2a and S2b are two routers belonging to a different site S2. 

B and C are backbone routers running multiple routing instances (ISIS, for example) to connect sites S1 and S2. The idea is to use multiple instances of ISIS to segregate traffic within a large network. Routes from instance S1 are not placed in the instance S2.

In this case we will have two ISIS routing instances running between B and C (actually 3, as there will be a default instance also running).

Given that S1 and S2 are two different administrative domains there is nothing that precludes them from having different security policies. In which case you could, at least theoretically, have S1 use one auth algo and S2 use some other. This could also happen if for example, S1b doesn't support a particular authentication algo that other routers in the larger network support. In such a case, the routers in site S1 could fall back to the lowest auth algo that all routers in that site support, while routers in the other sites could use a stronger algorithm.

Cheers, Manav

> Russ, as part of designing a KMP proposal we've tried to come 
> up with a situation where an operator would like to do this.  
> So far we've failed.
> We can easily come up with reasons to have multiple sessions 
> between two peers.  So far though, we've been unable to come 
> up with reasons why you'd want to use different 
> authentication for these two sessions.
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: Sam Hartman <[email-masked]>
Date: Sun, 06 Nov 2011 10:41:35 -0500

>>>>> "Bhatia," == Bhatia, Manav (Manav) <[email-masked]> writes:

    Bhatia,> Given that S1 and S2 are two different administrative
    Bhatia,> domains there is nothing that precludes them from having
    Bhatia,> different security policies. In which case you could, at
    Bhatia,> least theoretically, have S1 use one auth algo and S2 use
    Bhatia,> some other. This could also happen if for example, S1b
    Bhatia,> doesn't support a particular authentication algo that other
    Bhatia,> routers in the larger network support. In such a case, the
    Bhatia,> routers in site S1 could fall back to the lowest auth algo
    Bhatia,> that all routers in that site support, while routers in the
    Bhatia,> other sites could use a stronger algorithm.

That's a good point.  Note that the RKMP work we're doing is focusing on
unicast associations, so not IS-IS.  (Even in point-to-point mode, IS-IS
does area-wide or domain-wide keying, so it would need a group security
association.)  You're absolutely right that two peers can participate in
groups with different parameters, and that the name of a group would
need to distinguish multiple instances especially for something like
IS-IS.

We haven't found an example where the same issue comes up in unicast
associations.  If we change your example to use multiple BGP instances
for example, It seems fine for B and C to use the same SA to protect all
BGP traffic between B and C given that this affects nothing else in the
system and given the KARP threat model.