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

From: Uma Chunduri <[email-masked]>
Date: Tue, 24 Apr 2012 20:26:54 -0400

Dear All,

I understand the spirit of the http://datatracker.ietf.org/doc/draft-ietf-karp-crypto-key-table/?include_text=1 WG document.
I saw the presentation on the same at IETF83, but still have the following specific questions and comments.

Questions/Comments:
---------------------------------

1. Text in Abstract and Section-1 assumes this conceptual database if for security protocols such as TCP-AO with a following exception in Section-1

        "In other instances, security protocols will directly use the long-lived key from the database."
    AFAICT, KARP is interested in security protocol TCP-AO to protect all TCP based pair wise routing   protocols (BGP, LDP, MSDP, PCEP).
    I am interested to know what other security protocols relevant to   KARP use long-lived keys.
2.  From the fields in conceptual database and the description it's very clear that this is a common table not only for security protocols like TCP-AO but also for routing
     protocols which use group keys (notably OSPF, ISIS etc..).  But,
       a. For one set of routing protocols which use security protocols like TCP-AO, for E.g., 'interfaces' field is not relevant as key selection is not done per interface level.
           Similarly for group keying routing protocols KDF, KDF inputs are not relevant.
      b. For lifetime there are 4 fields defined, which seems more relevant to OSPF. But this can be specified in seconds as well as number of bytes secured with that key.
          I don't see any requirement for routing protocols to specify key lifetime in terms of number of bytes secured and also don't see all routing protocols as well as
          security protocols use the same  lifetime format either.
      I am not worried about few extra fields which are relevant to one set of protocols and not at all relevant to other set. But, I am not sure why we have to
      club routing protocols which use group keying, use different transports (L2, L3, L4)  and do security by themselves  need to be clubbed with a security
      protocol like TCP-AO which is specifically designed to protect TCP based pair wise routing protocols (BGP, LDP etc..).  If separation for a set of
      routing protocols with common characteristics is provided, more specific and more relevant fields to the routing protocols can be added  to the table.
3.  Section-3 specifies Key Selection and as mentioned earlier this is not applicable to security protocols like TCP-AO as key selection happens by consulting it's
    internal tables. How ever, a routing protocol which secures it's routing packet by itself can consult this table.

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 24 Apr 2012 20:43:15 -0700

> I saw the presentation on the same at IETF83, but still have the following specific questions and comments.

How else would one determine it is time for a key rollover?

>               - OSPFv3 ( Originally defined with IPSec based on the new draft/RFC it’s similar to OSPFv2)
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp

Mahesh Jethanandani
[email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 25 Apr 2012 13:08:54 -0400

Dear All,

Questions/Comments:

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

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

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Apr 2012 16:50:43 -0700

> On Apr 24, 2012, at 5:26 PM, Uma Chunduri wrote:
...
>> I don't see any requirement for routing protocols to specify key
>> lifetime in terms of number of bytes secured and also don't see all
>> routing protocols as well as

Time or byte-based key rollover isn't necessarily required by all protocols.

Some protocols have replay counter fields that require bytecount key 
rollover, but if the replay counter is large enough (e.g., 64 bits), 
that seems unnecessary.

Keys in TCP-AO, e.g., don't have a time-based or byte-based rollover; 
they are changed as needed (e.g., you can externally change them every 
day or week to reduce the impact of potential key exposure, or you can 
change them when you terminate an employee or have other reason to 
believe there is a need).

Joe