Subject: [karp] KARP Proposed Charter (post BoF)

From: Brian Weis <[email-masked]>
Date: Tue, 12 Jan 2010 19:01:01 -0800

Folks,

Joel & I have made a number of changes to the previously proposed  
charter. We've taken into account comments made during the BoF as well  
as edited it for brevity and reorganized it a bit. Please send your  
comments to the list.

Thanks,
Brian & Joel

=========== Proposed Charter 1/12/10

The KARP working group is tasked to work with the routing protocol
working groups in order to improve the communication security of the
packets on the wire used by the routing protocols. This working group is
concerned with message authentication, packet integrity, and denial of
service (DoS) protection.  At present, this charter explicitly excludes
privacy and non-repudiation concerns.

Authenticating the routing peer sending a message, and message integrity
protection will be provided through the use of per-packet cryptographic
message authentication. Peer authentication will protect against
unrecognized peers, imposter peers, and some DoS attacks aimed at
routers. Protecting against misbehavior of an otherwise allowed peer
router is outside the scope of this working group.

Many routing protocols (or groups of protocols) already have some method
for accomplishing cryptographic message authentication.  In most cases
the existing methods are vulnerable to known attack, and/or employ
cryptographic algorithms that have been deprecated. Internet security
practices have progressed in the last 10 years when many of the first
generation routing authentication mechanisms were created. It is time to
review and update those mechanisms to use modern security practices.
Ensuring algorithm agility within routing protocols is of particular
importance.  A goal of the working group is to add incremental security
to existing mechanisms rather than replacing them.  Better deployable
solutions that vendors and operators can migrate to is more important
than getting a perfect security solution.

Although there are many candidate routing protocols to evaluate, KARP
must by necessity begin with a restricted focus. The initial set of
routing protocols in scope include BGP, OSPFv2, OSPFv3, PCE, PIM, LDP,
RSVP-TE, ISIS, BFD, LMP, and MSDP.

The working group must coordinate very closely with other working
groups, such as:

-  Routing protocol working groups for any routing protocol being
evaluated. This coordination will include cooperatively determining the
current or already planned state of the security work in the protocol.
  It will also include ensuring that any proposed mechanisms are
consistent with with architecture and use of the protocol.  And any
specific proposal will be developed in cooperation with the concerned
protocol working group.

-  Security area working groups for cryptographic advice, and/or key
management protocol support. Cryptographic protocol support may be
required in order to support certain KARP WG milestones. Coordination
with an appropriate working group in the security area would be
necessary in order to get the appropriate expertise in completing a
milestone. This charter provides for preliminary work in this space,
although it is expected that detailed work items will be added to the
charter when the problem has been better analyzed.

-  OPSEC working group for advice on best practices to create and use
integrity keys used with routing protocol message authentication.

Routing protocols use a range of transport mechanisms and communication
relationships. There are also differences in details among the various
protocols. The working group will attempt to describe the security
relevant characteristics of routings protocols, such as the use or
non-use of TCP, or the frequent use of group communication versus purely
pairwise communication. Using these characteristics, the working group
will then provide suitable common frameworks that can be applied, and
tailored, to improve the communication security of the routing
protocols.  In later phases, it is expected that the working group will
investigate the suitably of defining conceptual structures and APIs, so
as to enable further work to be more effective.

Work Items:

- Determine current threats to the routing protocol operation, and
define general requirements for cryptographic authentication of routing
protocols. A primary source for these documents should be
draft-lebovitz-kmart-roadmap, although RFC 4393 may also be useful.

- Identify deficiencies of each routing protocol in scope, and specify
mechanisms that bring them in line with the general requirements.

- Define one or more frameworks describing the common elements for
modern authentication in routing protocols.

- Publish guidance on how to create and use integrity keys used with
routing protocol message authentication.

- Specify automated key management needs for routing protocols.

Goals and Milestones:

Aug 2010 - Submit General Framework, General Requirements, and
Priorities/Work-Plan documents to the IESG to be considered as
Informational RFC

Aug 2010 - Submit a framework document describing protocol groups and
the common techniques and interfaces that apply to them to the IESG to
be considered as Informational RFC

Dec 2010 - Submit a document describing best best practices for creating
and using protocol message authentication integrity keys as a BCP

TBD - Submit specification document for OSPFv2 to the IESG to be
considered as as a Proposed Standard

TBD - Submit specification document for OSPFv3 to the IESG to be
considered as as a Proposed Standard

TBD - Submit specification document for PIM to the IESG to be considered
as as a Proposed Standard

TBD - Submit specification document for RSVP-TE to the IESG to be
considered as as a Proposed Standard

TBD - Submit specification document for ISIS to the IESG to be
considered as as a Proposed Standard

TBD - Submit specification document for BGP to the IESG to be considered
as as a Proposed Standard

TBD - Submit specification document for LDP to the IESG to be considered
as as a Proposed Standard

TBD - Submit specification document for PCE to the IESG to be considered
as as a Proposed Standard

TBD - Submit specification document for MSDP to the IESG to be
considered as as a Proposed Standard

TBD - Submit specification document for BFD to the IESG to be considered
as as a Proposed Standard

TBD - Submit specification document for LMP to the IESG to be considered
as as a Proposed Standard

TBD - Specify automated key management needs for routing protocols using
unicast techniques

TBD - Specify automated key management needs for routing protocols using
multicast techniques

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Fri, 15 Jan 2010 17:09:43 -0800

Great work guys. Inline...

>solutions that vendors and operators can migrate to is more important

nit:
s/that vendors and operators can migrate to/to which vendors and 
operators can migrate/

>specific proposal will be developed in cooperation with the concerned

define more clearly where the work will be done?

>charter when the problem has been better analyzed.

I like this paragraph. It clearly indicates that we will move in the 
direction of defining a mechanism for KMP, but indicates that we are 
still working on how. It also invites and sets the expectation of 
Security area involvement. Well done.

>protocols.

I'd like to see the following added, so that we set the long term 
vision clearly that we want to get to KMPs:

In a later phase, it is expected that a key management protocol (KMP) 
will be defined for use by routing peers to automatically negotiate 
keys and other connection parameters, and that this KMP could be used 
by many, if not all, of the routing protocols. More about the use of 
a KMP will be captured in the Framework document(s) described below.

>In later phases, it is expected that the working group will
>protocols. A primary source for these documents

s/these documents/this document/

(I think we've decided to roll these into one document with two major 
sections. Justification:  most of the requirements derive from 
attempting to cover the threat landscape, so they go well together.)

>should be

s/-kmart/karp/

>mechanisms that bring them in line with the general requirements.

can we create a name for these? How about "Protocol Gap Analysis". 
Thus, the new text would be:

These we will refer to as "Protocol Gap Analysis".

>modern authentication in routing protocols.

add:
This will be called the Framework document.

>routing protocol message authentication.

What I had in mind for the guidance document was more of a work list 
and security tips/tricks for the teams doing the protocol gap 
analysis. So the guidance is more like the charter for those papers, 
and how to move through the process. Here is an outline I came up 
with, which should NOT be in this charter text, but may help you to 
better craft this item:

Guidance - more template for what a protocol gap analysis and design 
team for a specific category of Routing Protocols will do, i.e. the 
step by step instructions. Current in sections 4.1, and 4.4 of 
draft-lebovitz-kmart-roadmap. E.g.:
  - Clearly list the category you are addressing, what protocols fall 
into that category, and justify ea proto's existence in said category
  - go present in each protocols WG that the proto falls into said 
category, and that work is starting. Ask for volunteers. make sure we 
are cross sync'ing with the proto WG well.
  - Form a design team that includes protocol designers from protos 
in that category + security guys.
  - update to the related proto WG's
  - Look at current security mechanisms of ea protocol and compare to 
karp-threats-reqs document. Create a gap analysis
  - using karp-framework, solve for the gaps, conceptually. This can 
include requirements listing, suggested fixes
  - update to the related proto WG's
  - start a document for each protocol and apply the fixes needed for 
each protocol
  - section on proper care and feeding of the process:
       - define work split between KARP and actual rouint protocol WG's.
       - final protocol design changes get made in protocol WGs, not 
KARP, but done based on docs coming out of KARP
       - cc the proto WG often
       - present in the proto WG often
       - don't DoS the proto WG with your security stuff, it creates bitterness

>- Specify automated key management needs for routing protocols.

add:  These we will call KARP Design Teams. These may well be very 
close to the same teams that do the protocol gap analysis.

>Priorities/Work-Plan documents to the IESG to be considered as

seems agressive to me. I'd say Nov is a better bet.

>be considered as Informational RFC

Very aggressive. I'd start with Nov.

>and using protocol message authentication integrity keys as a BCP

Seems reasonable.

>TBD - Specify automated key management needs for routing protocols using

All look good to me. Note that I think some of these will fall 
together in groups, so we could do one document for the design for 
the group, and then take that and go apply it specifically in each 
protocol's own WG, with the commitment of the KARP people to go there 
and continue the work there.

Those are my thoughts. Hth,
Gregory.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 18 Jan 2010 12:33:10 -0500

So far, we have gotten comments on the charter from exactly 1 person.
While those comments are useful, and I want to explore some of the 
points in more detail below, I want to take this opportunity to ask 
whether anyone else has comments on the proposed charter.  (For that 
matter, has anyone else even read it carefully?)

Thank you,
Joel M. Halpern

Gregory M. Lebovitz wrote:
...
> At 07:01 PM 1/12/2010, Brian Weis wrote:
...
> define more clearly where the work will be done?
I don't know that the work will always bew done on the same side of the 
fence.  That is, for some protocols we may agree to do the work in KARP, 
and for others we may agree to do with work in the specific protocol 
working group.  I would prefer that the charter didn't nail this down 
too tightly.

...
> This will be called the Framework document.
Minor point, but either we say "Define a framework", or we do not refer 
to and give a name for a single document.
>> routing protocol message authentication.
I think we have a slight disconnect here.  THis bullet was, I beleive, 
attempting to address the specific request from the meeting that we 
provide operational guidance (in cooperation with opsec and the 
operations area), on how operators should use these tools.
What you have described is a different document.  I don't know whether 
we had agreed we needed that other document or not.

> 
> What I had in mind for the guidance document was more of a work list and 
> security tips/tricks for the teams doing the protocol gap analysis. So 
> the guidance is more like the charter for those papers, and how to move 
> through the process. Here is an outline I came up with, which should NOT 
> be in this charter text, but may help you to better craft this item:
> 
> team for a specific category of Routing Protocols will do, i.e. the step 
> by step instructions. Current in sections 4.1, and 4.4 of 
>  - Form a design team that includes protocol designers from protos in 
> that category + security guys.

---

From: Bill Atwood <[email-masked]>
Date: Mon, 25 Jan 2010 23:27:49 -0500

Comments on the proposed charter:

Milestones:
Submit a specification document for OSPFv2---
See draft-gupta-ospf-ospfv2-sec
Submit a specification document for OSPFv3---
See RFC 4552
Submit a specification document for PIM
See draft-ietf-pim-sm-linklocal, which has already been approved by the
IESG as an RFC (but not yet published).

It might be important to talk to Gupta and Melam (for the OSPFv2 and
OSPF v3 documents), and to the chairs of the OSPF WG before adopting the
OSPF milestones.  In terms of PIM, while I will be eager to apply the
coming Framework and Design Guidelines documents to what has been done,
I expect that a new PIM document will not be an early one in the
sequence; I believe that it is more likely to be an early example of
Step 2, rather than Step 1.

Specific grammatical comments are inline.

  Bill

> protection will be provided through the use of per-packet cryptographic
            ,
> consistent with with architecture and use of the protocol.  And any
                  the                                         Also,
> draft-lebovitz-kmart-roadmap, although RFC 4393 may also be useful.
                 karp
> Dec 2010 - Submit a document describing best best practices for creating
                                               xxxxx
> considered as as a Proposed Standard
                xxx
> considered as as a Proposed Standard
                xxx
> as as a Proposed Standard
     xxx
> considered as as a Proposed Standard
                xxx
> as as a Proposed Standard
     xxx
> as as a Proposed Standard
     xxx
> as as a Proposed Standard
     xxx
> considered as as a Proposed Standard
                xxx
> as as a Proposed Standard
     xxx
> TBD - Specify automated key management needs for routing protocols using

- --

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email: [email-masked]
1455 de Maisonneuve Blvd. West    http: //users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Brian Weis <[email-masked]>
Date: Tue, 26 Jan 2010 15:17:53 -0800

Hi Bill,

Thanks for your review.

On Jan 25, 2010, at 8:27 PM, Bill Atwood wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

It is my expectation that all of these documents will be considered  
when analyzing particular routing protocols, but it may be that a KARP  
design team would come up with additional security requirements so we  
do need to plan for PIM and/or OSPF relevant document. If the  
conclusion of a review is that nothing need be done, then I'm sure the  
WG will be justified in not meeting that milestone.

> Specific grammatical comments are inline.

Got 'em, thanks!
Brian

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkteb0UACgkQV5o4IdDwBVifhQCgjtGb43khWFyBEocAJJ+z/nSW
> nigAnAv+H+l4eAjjGHvDYConIdASPx7t
> =8it2
> -----END PGP SIGNATURE-----

-- 
Brian Weis
Router/Switch Security Group, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Tue, 26 Jan 2010 15:58:16 -0800

inline...

>WG will be justified in not meeting that milestone.

Agree w/ Brian.

Gregory

---

From: Acee Lindem <[email-masked]>
Date: Tue, 26 Jan 2010 20:29:41 -0500

Hi Joel, Brian,
I have read the proposed KARP charter and, as OSPF WG co-chair, support the work. The only comment I have is that with RFC 5709, we have updated our authentication algorithms and are not ten year behind. 
Thanks,
Acee 
On Jan 18, 2010, at 12:33 PM, Joel M. Halpern wrote:

> While those comments are useful, and I want to explore some of the points in more detail below, I want to take this opportunity to ask whether anyone else has comments on the proposed charter.  (For that matter, has anyone else even read it carefully?)
> 
> Thank you,
> Joel M. Halpern
> 
> 
> I don't know that the work will always bew done on the same side of the fence.  That is, for some protocols we may agree to do the work in KARP, and for others we may agree to do with work in the specific protocol working group.  I would prefer that the charter didn't nail this down too tightly.
> 
> ...
> Minor point, but either we say "Define a framework", or we do not refer to and give a name for a single document.
> I think we have a slight disconnect here.  THis bullet was, I beleive, attempting to address the specific request from the meeting that we provide operational guidance (in cooperation with opsec and the operations area), on how operators should use these tools.
> What you have described is a different document.  I don't know whether we had agreed we needed that other document or not.
> 
>> What I had in mind for the guidance document was more of a work list and security tips/tricks for the teams doing the protocol gap analysis. So the guidance is more like the charter for those papers, and how to move through the process. Here is an outline I came up with, which should NOT be in this charter text, but may help you to better craft this item:
>> Guidance - more template for what a protocol gap analysis and design team for a specific category of Routing Protocols will do, i.e. the step by step instructions. Current in sections 4.1, and 4.4 of draft-lebovitz-kmart-roadmap. E.g.:
>> - Clearly list the category you are addressing, what protocols fall into that category, and justify ea proto's existence in said category
>> - go present in each protocols WG that the proto falls into said category, and that work is starting. Ask for volunteers. make sure we are cross sync'ing with the proto WG well.
>> - Form a design team that includes protocol designers from protos in that category + security guys.
>> - Look at current security mechanisms of ea protocol and compare to karp-threats-reqs document. Create a gap analysis
>> - using karp-framework, solve for the gaps, conceptually. This can include requirements listing, suggested fixes
>> - start a document for each protocol and apply the fixes needed for each protocol
>>      - final protocol design changes get made in protocol WGs, not KARP, but done based on docs coming out of KARP
>>      - cc the proto WG often

---

From: Brian Weis <[email-masked]>
Date: Wed, 27 Jan 2010 11:00:50 -0800

Hi Gregory,

Thanks much for your comments. See replies inline, and let me know if  
you disagree with any of resolution proposals.

> define more clearly where the work will be done?

It would be nice if we could define more clearly where the work will  
be done, but frankly I think this will end up being determined on a  
case-by-case basis, depending on the dynamics of the RP WG. Whenever  
possible we'd expect to do the work in KARP. I agree it would be good  
to clarify this in the charter.

> In a later phase, it is expected that a key management protocol  
> (KMP) will be defined for use by routing peers to automatically  
> negotiate keys and other connection parameters, and that this KMP  
> could be used by many, if not all, of the routing protocols. More  
> about the use of a KMP will be captured in the Framework document(s)  
> described below.

That's fine. But in the interests of brevity I'd prefer to incorporate  
this thought into the paragraph mentioning coordination with the  
security area.

> (I think we've decided to roll these into one document with two  
> major sections. Justification:  most of the requirements derive from  

It may be that time we might have more than one framework document  
("Define one or more frameworks"), so I'd prefer to not restrict this  
item to one named document in the charter.

> with, which should NOT be in this charter text, but may help you to  

Thanks for the additional information. I think there may be other  
guidance documents in scope too, so I'll change the charter to reflect  
that point.

> step by step instructions. Current in sections 4.1, and 4.4 of draft- 
> lebovitz-kmart-roadmap. E.g.:
> category, and that work is starting. Ask for volunteers. make sure  
> we are cross sync'ing with the proto WG well.

Specifying exactly *how* charter work items will be handled is  
probably more limiting than useful, so it might be better to omit  
details of forming design teams in the charter text.

Thanks!
Brian

> protocol's own WG, with the commitment of the KARP people to go  
> there and continue the work there.
>

---

From: Ross Callon <[email-masked]>
Date: Wed, 27 Jan 2010 15:36:49 -0500

Just a few comments (text that I am not commenting on deleted). These are as an interested individual (not in my role as routing AD), unless specified otherwise (see comment at the end). 

> It would be nice if we could define more clearly where the work
> will be done, but frankly I think this will end up being determined
> on a case-by-case basis, depending on the dynamics of the RP WG. 
> Whenever possible we'd expect to do the work in KARP. I agree it
> would be good to clarify this in the charter.

Where work is needed to improve the security of protocol "X", then we are going to need to determine on a case by case basis where the work will be done (where "we" probably means chairs of the KARP WG, chairs of the WG responsible for protocol "X", routing ADs, with input from the working groups and possibly security ADs). Where the work goes may depend upon details of what each specific piece of work actually is. Thus it seems futile to me to try to predict what will make sense at the time (I like the current somewhat vague wording). 

> details of forming design teams in the charter text.

I agree with Brian here -- reasonable people can figure out at the time whether Design teams are needed. Usually in the IETF a small group of people do the work, and the rest of the WG agrees with comments. In some cases it is less easy than this and more formality may be needed. 

> seems agressive to me. I'd say Nov is a better bet.

I agree with Gregory on this point, August seems mighty optimistic (ditto for the next milestone). 

As AD, I would suggest that the draft charter looks pretty good to me, and we need to get this settled quickly. I would like to get the WG chartered prior to the Anaheim IETF if reasonably possible, and it is coming up quickly. 

Thanks, Ross