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

From: Uma Chunduri <[email-masked]>
Date: Fri, 2 Sep 2011 19:20:13 -0400

There was a discussion on traffic selectors needed or not during the last ietf meeting (IETF81).

Recap on the discussion:

===
SH: May have multiple SAs for, say, multiple protocols. Share IKE SAs.

Steve Kent (SK): Asked about more values in the SA. Suggested traffic selectors.

SH: Only Protocol ID is needed.

SK: Disagrees. Before you throw something away, traffic selectors were designed to do this. Code reuse.

SH: The traffic selectors would be different at the bit-level. Ports.

TK: Encouraged keeping existing SA payload structures-complicated to change.

---

Uma Chunduri (UC): Need source port numbers.

SH: Disagrees. Will you have multiple BGP SAs between the same two endpoints? Not clear this needs to be negotiated at the IKE layer.

=====

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

If it is not already considered, probably traffic selectors need to be considered in the next revision of the combined IKEv2 based  KMP draft.

-Uma

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Sep 2011 12:42:21 -0400

>>>>> "Uma" == Uma Chunduri <[email-masked]> writes:

    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.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 26 Sep 2011 14:50:00 -0400

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.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Sep 2011 15:25:41 -0400

> 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.

    Uma>  ==== [Uma] You raised an
    Uma> important point. I would say, the second solution is not
    Uma> necessarily complex but it's the opposite.  Think of it- your
    Uma> KMP is capable and it's giving unique session keys to protect
    Uma> underlying session that could be multiple sessions between the
    Uma> same end points (our case of discussion) or different end
    Uma> points.  In this case TCP-AO which is the eventual user of the
    Uma> keys, need not do extra KDF to get the session keys (just
    Uma> directly use the KMP keys).

    Uma> The advantage os this approach: - Each underlying session has
    Uma> the capability to choose session parameter more granularly -
    Uma> E.g.: Life time even AUTH algo (BGP may select one and LDP can
    Uma> select different) 

To show that this is an advantage, you need to show why one BGP session
between two peers wants algorithm A and another wants algorithm B. (Or
similar for another protocol). We already agree that BGP and LDP are
different protocols and thus need different KMP keys.
It seems fairly unlikely to me that different sessions between two BGP
peers need different algorithms.

    Uma> - Limited damage in case of a key compromise

    Uma>  - and as I mentioned
    Uma> I would argue integration with KMP is rather more easier -
    Uma> Remember, in your case what KMP is giving to TCP-AO is KMP's
    Uma> traffic key (CHILD_SA key) to generate multiple traffic keys to
    Uma> protect multiple sessions between same peers.

Right.  In our model, we give BGP one key between two peers.  In your
model, BGP somehow needs to communicate the source port to the KMP
before the session is opened. It means the KMP has to understand several
concepts it doesn't need to understand in our model. In your model the
KMP needs to understand the concept of ports, the concept of different
transport protocols and their interactions. We don't avoid understanding
the concept of routing protocols  because that's where access control
decisions are made.
It would also be very easy to expose details like the per-TCP-AO session
state in the configuration in a manner that made the KMP far harder to
configure or use.
Note that the requirement that the routing protocol tell the KMP the
source port significantly complicates the interlocking between the
routing protocol and KMP.

port 

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

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

I think there are several disadvantages.
First, changing TCP-AO is expensive from a specification and
implementation standpoint.

Secondly, there is no advantage in doing so.  Even if we find it
valuable to do per-session SAs, we can still do the TCP-AO key
derivation. The performance is not significant and comes at a
non-critical time (session setup not per-packet).

Adding direct traffic key support to TCP-AO adds a less secure mode,
complicates the security analysis and complicates the protocol. Without
significant advantages, I do not support it.

I also find that the advantages stated so far for per-session SAs do not
justify the complexity in my mind.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 26 Sep 2011 12:42:22 -0700

I would submit that even if BGP and LDP are two different protocols, why 
would they need two different KMP keys? It is the level of security that 
is being negotiated between the two peers, which has no relationship 
(necessarily) to what will be carried in the payload.

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 26 Sep 2011 17:05:40 -0400

To show that this is an advantage, you need to show why one BGP session between two peers wants algorithm A and another wants algorithm B. (Or similar for another protocol). We already agree that BGP and LDP are different protocols and thus need different KMP keys.
It seems fairly unlikely to me that different sessions between two BGP peers need different algorithms.

[Uma]: Why do you need to differentiate the application (routing) protocol between the same peers to authenticate the peer?
I believe,  you don't need to differentiate the routing protocol between the same peers. At the end of the day it's the TCP who 
is carrying the data and protocol for KMP purpose is TCP (infact, you can hide all protocols this way i.e., BGP, LDP, MSDP etc..). 
Then the selection of SA purely depends on the port. And each SA corresponding to a session MAY have different lifetimes and 
algos negotiated.

Right.  In our model, we give BGP one key between two peers.  In your model, BGP somehow needs to communicate the source port to the KMP before the session is opened. It means the KMP has to understand several concepts it doesn't need to understand in our model. In your model the KMP needs to understand the concept of ports, the concept of different transport protocols and their interactions. We don't avoid understanding the concept of routing protocols  because that's where access control decisions are made.

[Uma] KMP is supposed to understand the selectors, algos lifetimes configured to help negotiate the right set of parameters agreeable to both ends.
      This is precisely the point of CHILD_SA exchange (which is being used to give the key to RP). 

It would also be very easy to expose details like the per-TCP-AO session state in the configuration in a manner that made the KMP far harder to configure or use.
Note that the requirement that the routing protocol tell the KMP the source port significantly complicates the interlocking between the routing protocol and KMP.

[Uma]  We are slightly going on a different topic here. But nevertheless this is related and extremely important:
Some body has to trigger KMP to get the keys at the time of re-key or at the time of application restart to get new set of keys. I didn't understand how can you *completely* avoid the trigger.
When you trigger - give the parameters to KMP.

I think there are several disadvantages.
First, changing TCP-AO is expensive from a specification and implementation standpoint.Secondly, there is no advantage in doing so. 
 Even if we find it valuable to do per-session SAs, we can still do the TCP-AO key derivation. The performance is not significant and 
comes at a non-critical time (session setup not per-packet).

[Uma] Yes, KDF doesn't cause performance problem but that is not the point. The only disadvantage I hear is, changing TCP-AO. There is a simple way for this and we briefly discussed this with
Brian Weis, Kayur and one of the TCP-AO authors Ron Bonica at last IETF.  

Adding direct traffic key support to TCP-AO adds a less secure mode, complicates the security analysis and complicates the protocol. Without significant advantages, I do not support it.I also find that the advantages stated so far for per-session SAs do not justify the complexity in my mind.

[Uma] I didn't understand how it complicates the security analysis/protocol. 
      Let me re-iterate  the advantages of populating the KMP session keys directly in TCP-AO:
      Non-Security:
          - Granular session specific parakeets including session life-time and optimally algo (which is not needed for multi session BGP)
          - Easy integration with KMP (which we both disagreed)
          - This can eliminate the operational issue(may not be issue for RPs and I didn't mention this earlier)
            Session specific selectors are part of the traffic key generation through KDF, which can cause NAT issues.
            (there is a draft and this being worked differently out at this moment) 
      Security:
          - Any key compromise is limited to that particular session
          - You can satisfy all KMP requirements for the traffic key ingredients 
            (again will stop here and can elaborate more if this is required)

So, I strongly believe this is to be designed right at first time considering all the facts and probably as KMP draft is being published, this is the right time.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Sep 2011 11:08:37 -0400

> To show that this is an advantage, you need to show why one BGP
> session between two peers wants algorithm A and another wants
> algorithm B. (Or similar for another protocol). We already
> agree that BGP and LDP are different protocols and thus need
> different KMP keys.  It seems fairly unlikely to me that
> different sessions between two BGP peers need different
> algorithms.

    Uma> [Uma]: Why do you need to differentiate the application
    Uma> (routing) protocol between the same peers to authenticate the
    Uma> peer?  I believe, you don't need to differentiate the routing
    Uma> protocol between the same peers. At the end of the day it's the
    Uma> TCP who is carrying the data and protocol for KMP purpose is
    Uma> TCP (infact, you can hide all protocols this way i.e., BGP,
    Uma> LDP, MSDP etc..).  Then the selection of SA purely depends on
    Uma> the port. And each SA corresponding to a session MAY have
    Uma> different lifetimes and algos negotiated.

We could do that.  It would be a bad idea because at the end of the day
an operator is trying to configure security for a routing protocol.
That means the operator wants to make a configuration decision like
"turn on security for BGP with peer x," not "turn on security for PORT y
to port 179 on peer x".
Knowing that it's BGP simplifies configuration, simplifies monitoring
and simplifies debugging.
The operator wants to make access control decisions in terms of BGP. The
operator may very sensibly want to do things like use the same
configuration to define a peer as to permit a security association with
a peer.
All that is easier if we think of this in terms of BGP rather than some
TCP port.

As you have pointed out several times, we can negotiate different
lifetimes and algorithms for two distinct sessions beetween the same
peers for the same protocol if we think of things in terms of TCP ports.
I agree. However I'm still not seeing that as an advantage. Why would an
operator want to do so?

> Right.  In our model, we give BGP one key between two peers.
> In your model, BGP somehow needs to communicate the source port
> to the KMP before the session is opened. It means the KMP has
> to understand several concepts it doesn't need to understand in
> our model. In your model the KMP needs to understand the
> concept of ports, the concept of different transport protocols
> and their interactions. We don't avoid understanding the
> concept of routing protocols because that's where access
> control decisions are made.

    Uma> [Uma] KMP is supposed to understand the selectors, algos
    Uma> lifetimes configured to help negotiate the right set of
    Uma> parameters agreeable to both ends.  This is precisely the point
    Uma> of CHILD_SA exchange (which is being used to give the key to
    Uma> RP).

Absolutely truep. However the KMP needs to understand the child SAs
exactly to the level of abstraction that we define.  That's what we're
discussing now.  The KMP only needs to understand ports and TCP if we
say it does.
> It would also be very easy to expose details like the
> per-TCP-AO session state in the configuration in a manner that
> made the KMP far harder to configure or use.  Note that the
> requirement that the routing protocol tell the KMP the source
> port significantly complicates the interlocking between the

    Uma> [Uma] We are slightly going on a different topic here. But
    Uma> nevertheless this is related and extremely important: Some body
    Uma> has to trigger KMP to get the keys at the time of re-key or at
    Uma> the time of application restart to get new set of keys. I
    Uma> didn't understand how can you *completely* avoid the trigger.
    Uma> When you trigger - give the parameters to KMP.

It's a lot easier if the trigger can be before connections open and not
include ports or other TCP-specific info.  Remember that a lot of TCP
implementations allocate the source port as part of making a
connection. All (or almost all) allow you to override that, but it's
significant unnecessary complexity to force routing algorithms to
implement their own port allocation strategies.

> I think there are several disadvantages.  First, changing
> TCP-AO is expensive from a specification and implementation
> standpoint.Secondly, there is no advantage in doing so.  Even
> if we find it valuable to do per-session SAs, we can still do
> the TCP-AO key derivation. The performance is not significant
> and comes at a non-critical time (session setup not
> per-packet).

    Uma> [Uma] Yes, KDF doesn't cause performance problem but that is
    Uma> not the point. The only disadvantage I hear is, changing
    Uma> TCP-AO. There is a simple way for this and we briefly discussed
    Uma> this with Brian Weis, Kayur and one of the TCP-AO authors Ron
    Uma> Bonica at last IETF.

> Adding direct traffic key support to TCP-AO adds a less secure
> mode, complicates the security analysis and complicates the
> protocol. Without significant advantages, I do not support it.I
> also find that the advantages stated so far for per-session SAs
> do not justify the complexity in my mind.

    Uma> [Uma] I didn't understand how it complicates the security
    Uma> analysis/protocol.  

Today it's very easy to argue that TCP-AO traffic keys are fresh.
With this change, we need to consider two arms of a choice. In the
manual choice, we need to examine the existing mechanism. In the direct
traffic keys choice, we need to consider the KMP interactions.

    Uma> So, I strongly believe this is to be designed right at first
    Uma> time considering all the facts and probably as KMP draft is
    Uma> being published, this is the right time.

Agreed.

Having considered the facts so far, I strongly support the existing
           approach of using protocol IDs for each routing protocol and
           not changing TCP-AO. If we find there is an operational or
           security reason to distinguish sessions, we should do that.
I do not support direct traffic keys for TCP-AO.

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 27 Sep 2011 15:47:21 -0400

We could do that.  It would be a bad idea because at the end of the day an operator is trying to configure security for a routing protocol.
That means the operator wants to make a configuration decision like "turn on security for BGP with peer x," not "turn on security for PORT y to port 179 on peer x".
Knowing that it's BGP simplifies configuration, simplifies monitoring and simplifies debugging.The operator wants to make access control decisions in terms of BGP. 
The operator may very sensibly want to do things like use the same configuration to define a peer as to permit a security association with a peer.
All that is easier if we think of this in terms of BGP rather than some TCP port.As you have pointed out several times, we can negotiate different 
lifetimes and algorithms for two distinct sessions beetween the same peers for the same protocol if we think of things in terms of TCP ports.
I agree. However I'm still not seeing that as an advantage. Why would an operator want to do so?

[Uma]: 
       1. Even if you build  application (routing) protocol knowledge in IKEv2 by introducing protocol ID to distinguish 
          CHILD_SA, the true user of this SA is TCP-AO and it *doesn't* identify connection with application protocol 
          (just SIP, DIP, source port and Destination port). If you really want this (why?) then you need to change TCP-AO 
          connection identifier. Application protocol can be identified simply by unique destination port.
       2. What you are suggesting is taking away the granularity of the connection identification, which is well present in 
          both IKEv2 (Child_SA) and TCP-AO by lumping all connections with a protocol ID. Life time of keys for a particular 
          connection can always be more aggressive based on the topology of the connection or operator policy (for SIDR, for XYZ etc..). 
          You don't need to take this away for no reason (I don't agree your notion of complexity and hiding parameters here). 
          Infact, taking this away through specification introduces unnecessary churn and changes to both established protocols.

Absolutely truep. However the KMP needs to understand the child SAs exactly to the level of abstraction that we define.  
That's what we're discussing now.  The KMP only needs to understand ports and TCP if we say it does.

[Uma]: Even with one connection between the peers the ability to negotiate the lifetime of the keys and algorithm is one 
       of the advantage of the CHILD_SA negotiation. If some body deploys KMP, they expect this flexibility when connecting to 
       100 peers around with different algo and different lifetime requirements. I don't like taking this way for one connection 
       or multiple connections for unexplained complexity.

It's a lot easier if the trigger can be before connections open and not include ports or other TCP-specific info.  

[Uma]: If you want make the trigger before connection the disadvantage I see is all protocols  (BGP, LDP, MSDP etc..) 
       change and built-in this interaction with KMP. Which is a *significant* disadvantage.
       TCP-AO already provides that interface, one has to build on that and just use the same. With this one can better 
       control which traffic  is being protected exactly with connection identifies provided by TCP-AO
       (where SRC port could always be *).

Today it's very easy to argue that TCP-AO traffic keys are fresh.
With this change, we need to consider two arms of a choice. In the manual choice,
we need to examine the existing mechanism. In the direct traffic keys choice, 
we need to consider the KMP interactions.

[Uma] If this is the point of worry, then answer is very simple. With a *simple* extension 
      to TCP-AO this can be achieved with absolutely 0 changes for existing manual mechanism.
      So your worry for current/future manual deployment is non-issue. 

[Uma] I don't agree this. As I listed earlier and again below  - it has both operational and security reasons.
      Non-Security:
          - Granular session specific parameters
          - Easy integration with KMP (which we both disagreed)
          - This can eliminate the operational issue. Session specific selectors are part of the 
            traffic key generation through KDF, which can cause NAT issues.
      Security:
          - Any key compromise is limited to that particular session
          - You can satisfy all KMP requirements for the traffic keys (and it's ingredients).
 
      The weired part is you are giving a child_sa generated *traffic key* to TCP-AO to generate multiple 
      *traffic keys* again by AO to protect the eventual connections. 

> Adding direct traffic key support to TCP-AO adds a less secure mode, 

[Uma]: How this can be less secure mode??

---

From: Sam Hartman <[email-masked]>
Date: Tue, 27 Sep 2011 16:22:31 -0400

I think we've more or less reached the point where we've clearly stated
our positions and disagree.  This will be a matter for WG consensus
either during the process of adopting a proposal or once the WG has
adopted a proposal.

This is likely to be my last message on the subject unless something
really new pops up.

>>>>> "Uma" == Uma Chunduri <[email-masked]> writes:

    Uma> [Uma]: Even with one connection between the peers the ability
    Uma> to negotiate the lifetime of the keys and algorithm is one of
    Uma> the advantage of the CHILD_SA negotiation. If some body deploys
    Uma> KMP, they expect this flexibility when connecting to 100 peers
    Uma> around with different algo and different lifetime
    Uma> requirements. I don't like taking this way for one connection
    Uma> or multiple connections for unexplained complexity.

I absolutely agree that per-peer lifetime and algorithm negotiation is
something that a KMP should be able to do.  Our proposal has this
flexibility.

Note that we are not proposing using IKEv2. We are proposing a KMP based
on IKEv2 (possibly sharing code in some implementations). So, we are
proposing no changes to IKEv2.

Also, we are proposing no changes to TCP-AO. TThe interface between
TCP-AO and the application is largely
undefined. draft-ietf-karp-crypto-tables defines that interface for KARP
protocols. Our design is intended to be consistent with the crypto
tables.

Thanks for an excellent discussion: it has helped me clarify my
thinking.

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 27 Sep 2011 18:16:22 -0400

I think we've more or less reached the point where we've clearly stated our positions and disagree.  This will be a matter for WG consensus either during the process of adopting a proposal or once the WG has adopted a proposal.

[Uma]: Sure, I agree with this.

This is likely to be my last message on the subject unless something really new pops up.
[Uma]: Sure ..we both have only limited time for this.

I absolutely agree that per-peer lifetime and algorithm negotiation is something that a KMP should be able to do.  Our proposal has this flexibility.

[Uma]: Ok. Again we discussed more from per-connection requirements where we didn't converge.
       I know, IKEv2 based KMP has the flexibility for that too and it all starts with what keys are used eventually.

Also, we are proposing no changes to TCP-AO. TThe interface between TCP-AO and the application is largely undefined. 
[Uma]: My point is from KMP perspective, how we should *better* integrate and leverage properties of IKEv2 based KMP with TCP-AO
       I see minor extension for AO to get there. But it's not fair for me to talk further on this, with out specifying  what those are.
       Even, If we disagree we will specify what those are exactly and the benefits.

Thanks for an excellent discussion: it has helped me clarify my thinking.
[Uma]: Thanks. I echo the same.

---

From: Russ White <[email-masked]>
Date: Tue, 27 Sep 2011 18:28:55 -0400

> We could do that.  It would be a bad idea because at the end of the day an operator is trying to configure security for a routing protocol.

For what it's worth, I will agree with Sam here. At some point in the
future you might want to be able to have multiple sessions running
between the same pair of peers, and have them authenticated separately.
So it's valuable to know which specific protocol is being secured, not
just which pair of peers is being secured.

Russ

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 27 Sep 2011 18:57:34 -0400

> We could do that.  It would be a bad idea because at the end of the day an operator is trying to configure security for a routing protocol.

For what it's worth, I will agree with Sam here. At some point in the future you might want to be able to have multiple sessions running between the same pair of peers, and have them authenticated separately.
So it's valuable to know which specific protocol is being secured, not just which pair of peers is being secured.

[Uma]: Authentication and having multiple sessions (for the same protocol or different protocol) between the same peers are different things.
       You will authenticate the peer only *once* and with CHILD_SA you can create as many re-keyable sessions as you want between the same peers. The application 
       protocol being secured will and can always be distinguished by destination port (which will be unique for routing protocol E.g.: BGP 179) at both IKEv2 and TCP-AO.
       In that sense no way which specific protocol is being secured is lost any where.

_______________________________________________
karp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/karp

---

From: Russ White <[email-masked]>
Date: Tue, 27 Sep 2011 19:10:04 -0400

>        In that sense no way which specific protocol is being secured is lost any where.

You're assuming each session represents the same peering at the
administrative level --and this might not be true.

:-)

Russ

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 27 Sep 2011 20:16:00 -0400

>        In that sense no way which specific protocol is being secured is lost any where.

You're assuming each session represents the same peering at the administrative level --and this might not be true.

:-)

[Uma]: That is even better. We were talking about the obvious case, say both BGP and LDP using the same loopback.
       If both protocols use different peering at the administrative level you will end-up authenticating the same guy twice (different DIP), and followed by different CHILD_SA.
       There also routing protocol ID is not required to distinguish the SA. Again, your protocol info is inherently being represented by unique destination port.
       KMP can always see the protocol as TCP.
       The question is what extra benefit you are getting by introducing the routing protocol ID otherwise you would not have?

---

From: Russ White <[email-masked]>
Date: Tue, 27 Sep 2011 22:19:51 -0400

>        The question is what extra benefit you are getting by introducing the routing protocol ID otherwise you would not have?

You're thinking that a single "box," in terms of a virtual machine, or a
single o/s instance, is going to be a single "thing," in terms of
identity. The problem is this simply might not be true, even in the
short term. Today we already have one hardware interface with many
virtual interfaces that expose themselves to the o/s instance, and you
have many address families within a single protocol.

We need to have the ability to virtualize at this level, as well as at
the o/s level. I would argue these identifiers would give you this
ability, and it doesn't seem like they cost all that much to add, so...

:-)

Russ

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 28 Sep 2011 00:28:00 -0400

You're thinking that a single "box," in terms of a virtual machine, or a single o/s instance, is going to be a single "thing," in terms of identity. The problem is this simply might not be true, even in the short term. Today we already have one hardware interface with many virtual interfaces that expose themselves to the o/s instance, and you have many address families within a single protocol.

[Uma]: If you go back and see the discussion started exactly around similar situation (multi-session BGP with many address families).. 

We need to have the ability to virtualize at this level, as well as at the o/s level. I would argue these identifiers would give you this ability, and it doesn't seem like they cost all that much to add, so...
[Uma]: So..?? Which identifiers give you what exact ability to virtualize at O/S level and interface level??

---

From: Russ White <[email-masked]>
Date: Wed, 28 Sep 2011 11:18:42 -0400

> [Uma]: So..?? Which identifiers give you what exact ability to virtualize at O/S level and interface level?? 

The identifier would give you the ability to identify which routing
process on a particular machine you are pairing with, rather than simply
assuming all routing processes are in the same admin domain. Are you
saying you don't need any identifiers to identify which routing process
you're pairing with? If not, why not?

:-)

Russ

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 28 Sep 2011 12:30:31 -0400

Hello Russ:

The identifier would give you the ability to identify which routing process on a particular machine you are pairing with,

[Uma] Ok, let me ask this. How do you identify the machine (virtual/physical)? 
      Routing process can be identified by destination port or protocol. Even if you put this redundant information in the KMP 
     (on what is being discussed in here)  you don't have this in the ultimate user of this SA, which is TCP-AO.. Because - it  is 
     just not needed to securely deliver a packet a particular virtual/physical interface/machine.

rather than simply assuming all routing processes are in the same admin domain. 
Uma] No.. I don't think neither me or sam assumed this.

Are you saying you don't need any identifiers to identify which routing process you're pairing with? If not, why not?

[Uma] As I said you can identify same thing with multiple identifiers and build more redundant knowledge not only in KMP and TCP-AO etc.. 

Ok, let me summarize this for your opinion:
protocol ID introduction and identifying SA alone with that, doesn't give the granularity of the underlying connection. As you correctly, mentioned even each AFI/SAFI in the protocol need to be identified separately and that can be simply achieved by creating a connection with different source port but not just introducing one protocol ID to identify the whole thing and removing the existing source port granularity. This is the main issue we disagreed upon. 

If a connection granularity for the same protocol is given talking about protocol ID is completely ancillary and I have absolutely no issue with introducing the same as doesn't harm.