Subject: Re: [karp] Q's on karp-crypto-tables

From: Sam Hartman <[email-masked]>
Date: Tue, 08 May 2012 14:17:29 -0400

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

    Uma> On Apr 24, 2012, at 5:26 PM, Uma Chunduri wrote:

    Dear All,
     
    Uma>     I understand the spirit of the
    Uma> http://datatracker.ietf.org/doc/
    Uma> draft-ietf-karp-crypto-key-table/?include_text=1 WG document.
    Uma> I saw the presentation on the same at IETF83, but still have
    Uma> the following specific questions and comments.
     
    Uma>     Questions/Comments: ---------------------------------
     
    Uma>     1. Text in Abstract and Section-1 assumes this conceptual
    Uma> database if for security protocols such as TCP-AO with a
    Uma> following exception in Section-1
     
    Uma>              "In other instances, security protocols will
    Uma> directly use the long-lived key from the database."  AFAICT,
    Uma> KARP is interested in security protocol TCP-AO to protect all
    Uma> TCP based pair wise routing protocols (BGP, LDP, MSDP, PCEP).
    Uma> I am interested to know what other security protocols relevant
    Uma> to KARP use long-lived keys.  

Almost all the group routing protocols use long-lived keys.
OSPF, IS-IS, etc.
I believe every routing protocol mentioned in our charter can take
advantage of the key tables.

    Uma> 2.  From the fields in conceptual
    Uma> database and the description it's very clear that this is a
    Uma> common table not only for security protocols like TCP-AO but
    Uma> also for routing protocols which use group keys (notably OSPF,
    Uma> ISIS etc..).  But, a. For one set of routing protocols which
    Uma> use security protocols like TCP-AO, for E.g., 'interfaces'
    Uma> field is not relevant as key selection is not done per

I could imagine a TCP-AO implementation that permitted interface to be
considered in key selection, but I agree that this would be highly
unusual.  The next version will make it clear that the interfaces field
may not be mandatory to support for all protocols.
I'd expect that descriptions for binding the key tables to
BGP/TCP-AO/etc would make it clear that interfaces will not typically be
supported.

    Uma>     Uma> interface level.  Similarly for group keying routing protocols
    Uma> KDF, KDF inputs are not relevant.  

It's true that today's routing protocols do not use KDF.
There's nothing inherent about that though.
If I were designing authentication for a new protocol I would support a
KDF.
The KDF inputs field is going away.

    Uma> b. For lifetime there are 4
    Uma> fields defined, which seems more relevant to OSPF. But this can
    Uma> be specified in seconds as well as number of bytes secured with
    Uma> that key.  I don't see any requirement for routing protocols to
    Uma> specify key lifetime in terms of number of bytes secured and
    Uma> also don't see all routing protocols as well as security
    Uma> protocols use the same lifetime format either.

This is something we discussed in the presentation.
The hope here is to normalize things to something that is operationally
easy.
Like Joe, I don't think number of bytes is needed here.

    Uma> How else would one determine it is time for a key rollover?
    Uma> [Uma]: Just by one config option with lifetime in "secs". For
    Uma> all TCP based pair wise routing protocols which is IKEv2 this
    Uma> can be the best option.  Key rollover decision made locally at
    Uma> either end with out necessarily having co-ordinated out of band
    Uma> config agreement for this.  IKEv2 doesn't negotiate
    Uma> lifetimes. AO is capable of co-oridinated key changes with out
    Uma> impacting single TCP segment.  By having the 4 fields in the
    Uma> keytable and enforcing in all types (sets) of routing protocols
    Uma> we may not utilizing the full potential of what security
    Uma> protocol and KMP we use for some RPs.

I agree this needs to be considered.

    Uma>           I am not worried about few extra fields which are
    Uma> relevant to one set of protocols and not at all relevant to
    Uma> other set. But, I am not sure why we have to club routing
    Uma> protocols which use group keying, use different transports (L2,
    Uma> L3, L4) and do security by themselves need to be clubbed with a
    Uma> security protocol like TCP-AO which is specifically designed to
    Uma> protect TCP based pair wise routing protocols (BGP, LDP etc..).

The rationale is operators want to secure routing protocols.
Conceptually an OSPF virtual link looks to an operator a lot like BGP in
terms of security.
so, the intent is to have one conceptual model for all the above.
We're cleaning up many of the issues you describe and by the next
version I don't think that it will feel forced.
    Uma> Section-3 specifies Key Selection and as mentioned earlier this
    Uma> is not applicable to security protocols like TCP-AO as key
    Uma> selection happens by consulting it's internal tables. How ever,
    Uma> a routing protocol which secures it's routing packet by itself
    Uma> can consult this table.

This will be dealt with.
     
    Uma>     In summary- IMO, as we have various types of routing
    Uma> protocols it's better to define conceptual key table specific
    Uma> to that set.  Set1: BGP, LDP, PCEP, and MSDP (Pair wise TCP
    Uma> based which use security protocol like TCP-AO) Set 2: OSPF,
    Uma> IS-IS, RIP (group keying, different transports and security is
    Uma> provided by themselves) - OSPFv3 ( Originally defined with
    Uma> IPSec based on the new draft/RFC it?s similar to OSPFv2) -
    Uma> RSVP-TE (I would say still come under group key category) Set3:
    Uma> Multicast routing protocols like PIM -- Uma C.

I strongly believe that a single conceptual table will serve us well in
terms of making a set of specifications that are easy to deploy and use
in the real world.

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 May 2012 13:07:25 -0700

Hi, Sam (et al.),

Cutting down to the interfaces point, one comment below.

On 5/8/2012 11:17 AM, Sam Hartman wrote:
>>>>>> "Uma" == Uma Chunduri<[email-masked]>  writes:
>
..
> unusual.

TCP-AO uses the IP address in determining which key to use. That address 
could belong to multiple interfaces, and if it does I would assume the 
same key would be used.

FWIW.

Joe

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 May 2012 16:21:20 -0400

>>>>> "Joe" == Joe Touch <[email-masked]> writes:

Or that the routing protocol would choose a specific interface when
setting up a socket (several platforms support this), etc.
I think it's safe to say that we should not standardize interface
restrictions for TCP-AO.

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 May 2012 13:25:14 -0700

On 5/8/2012 1:21 PM, Sam Hartman wrote:
>>>>>> "Joe" == Joe Touch<[email-masked]>  writes:
>

There's no restriction, but TCP-AO doesn't understand using a key 
specific to an interface unless it's specific to an IP address - and an 
IP address isn't *necessarily* limited to a single interface.

Joe

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 8 May 2012 16:49:42 -0400

In-line [Uma] 

-- 
Uma C. 

Almost all the group routing protocols use long-lived keys.
OSPF, IS-IS, etc.
I believe every routing protocol mentioned in our charter can take advantage of the key tables.

[Uma]: Actually that is the problem I have. You didn't answer my question. 
       My Q was specifically on security protocols not routing protocols as section 1 says. If you read the introduction
       you get the feeling this is mostly designed for RPs which use TCP-AO but as we know this is not true.
       Make distinction between RPs seeking security through security protocols and RPs doing security by themselves.

---

It's true that today's routing protocols do not use KDF.
There's nothing inherent about that though.
If I were designing authentication for a new protocol I would support a KDF.
The KDF inputs field is going away.

[Uma]: I am not sure this justification warrants KDF to be in the table and to be (not) applicable to all existing 
       group keying protocols.

This is something we discussed in the presentation.
The hope here is to normalize things to something that is operationally easy.
Like Joe, I don't think number of bytes is needed here.

[Uma]: I didn't say it's needed either.

[Uma]: This is one good example where separate tables can really help associating the 
       tables fields for what RP is doing/not doing.

The rationale is operators want to secure routing protocols.
Conceptually an OSPF virtual link looks to an operator a lot like BGP in terms of security.
so, the intent is to have one conceptual model for all the above.
We're cleaning up many of the issues you describe and by the next version I don't think that it will feel forced.

[Uma]: OSPF virtual link case justifies a bigger group for group keying case. But I don't see any parallels to BGP in terms of 
       security requirements. I am not convinced this is the reason to have single table for all RPs.

I strongly believe that a single conceptual table will serve us well in terms of making a set of specifications that are easy to deploy and use in the real world.

[Uma]: I won't insist on this separation one more time, if authors still feel it's better to have one table only.
       I specified reasons (how one relates and adopts key table much easier) and why it is better to separate 
       the tables but I yet to hear convincing answers on why it has to be in the same table. As an example, 
       you can see the questions asked on crypto tables earlier from IGP side and how some fields which are 
       not relevant to IGPs created more confusion overall. 
	 To summarize again why separate tables are better for RP set:
		1. to refer key tables or not while securing the packets/PDUs
		2. to differentiate RPs using security protocols and RPs use various transports and doing security by themselves
		3. to differentiate pair-wise and group keying RPs (the requirement would be completely different)
		4. to relate and adopt key tables easily by RP
	 But overall, I see agreement on couple of key points and would like to see the new version of this document.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 08 May 2012 16:53:53 -0400

Joe> On 5/8/2012 1:21 PM, Sam Hartman wrote:
    >> Or that the routing protocol would choose a specific interface
    >> when setting up a socket (several platforms support this), etc.

    Joe> There's no restriction, but TCP-AO doesn't understand using a
    Joe> key specific to an interface unless it's specific to an IP
    Joe> address - and an IP address isn't *necessarily* limited to a
    Joe> single interface.

There is a restriction: the interface column in the key table is a
restriction on the scope of a key.  I'm arguing that we should not
require that routing protocols on top of TCP-AO support that
restriction, nor worry about the specific semantics if an implementation
should go ahead and implement that restriction for an AO-secured routing
protocol.  I can think of implementation strategies if you really wanted
to implement that interface restriction, but my preferred strategy is to
suggest that for AO, you restrict the scope of keys using peer
identifiers (IP addresses). My goal is to align the next version of the
key tables draft with this.

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 May 2012 13:59:11 -0700

> key tables draft with this.

AOK. That makes sense.

Joe