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

[Uma Chunduri <[e-mail]>]

    Uma> Apart from the protocol ID to differentiate multiple child SA's
    Uma> (BGP, LDP) between the same peers, it's possible there could be
    Uma> multiple TCP connections between the same peers for the same
    Uma> routing protocol.  Please refer IDR WG draft:
    Uma> http://datatracker.ietf.org/doc/
    Uma> draft-ietf-idr-bgp-multisession/ So all these BGP connections
    Uma> between same peers can be differentiated by source port, which
    Uma> is part of the traffic selectors.
 
    Uma> If it is not already considered, probably traffic selectors
    Uma> need to be considered in the next revision of the combined
    Uma> IKEv2 based KMP draft.

We agree there will be multiple TCP connections.  However, I've yet to see an argument for you need different outputs from the KDF in this instance. If all the TCP connections are between the same authenticated peers and have the same access control requirements, why do we need different SAs?  TCP-AO will give us different traffic keys in this instance even if it is the same SA.

Put another way, is the SA between BGP on peer A and BGP on peer B, or does the SA refer to BGP session x on peer A talking to BGP session y on peer B.
The second is more complex in terms of the interface between the KMP and routing protocol.
My opinion is that unless the second provides security value, we should take the simpler approach.
====
[Uma]
You raised an important point. I would say, the second solution is not necessarily complex but it's the opposite. 
Think of it- your KMP is capable and it's giving unique session keys to protect underlying session that 
could be multiple sessions between the same end points (our case of discussion) or different end points.
In this case TCP-AO which is the eventual user of the keys, need not do extra KDF to get the session keys 
(just directly use the KMP keys). 

The advantage os this approach:
	- Each underlying session has the capability to choose session parameter more granularly 
               - E.g.: Life time even AUTH algo (BGP may select one and LDP can select different) 
      - Limited damage in case of a key compromise (limited to the life time of one session)
      - and as I mentioned I  would argue integration with KMP is rather more easier
              - Remember, in your case what KMP is giving to TCP-AO is KMP's traffic key (CHILD_SA key)
                to generate multiple traffic keys to protect multiple sessions between same peers. 

If we think more, the reason for KDF and key derivation in TCP-AO is for inter-session replay protection and this
Is extremely relevant to manual keys but not keys generated with re-key capable KMP.

But, I recognize today TCP-AO can't consume direct traffic keys from KMP, but this can be changed if one see there 
is value in it. I will pause here and would listen on what do you think.