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

From: Gregory Lebovitz <[email-masked]>
Date: Mon, 1 Feb 2010 06:28:39 -0800

Brian,
Most of what I see in your responses is fine. I'll give some discussion
below, but please don't see my comments as blocking disagreement, accept for
this one point:

I believe we agreed that, in addition to the Routing AD(s), there would be a
Security AD explicitly listed as a governing AD for this WG, even though it
is a RTG WG, and a Security area person listed as an advisor. We said this
was very important because we wanted intentional/responsibility-tied
participation by SEC Area, and not just "security consultancy". As such,
could you please confirm that actual charter will look something like this,
so the commitment and relationship is clear to one and all:

Chair(s):

   - Joel Halpern
   - Brian Weiss

Routing Area Director(s):
   - Ross Callon
   - Adrian Farrell
Security Area Director(s):

   - Tim Polk <[email-masked]> <[email-masked]>
   - Pasi Eronen <[email-masked]> <[email-masked]>

Routing Area Advisor:   - Ross Callon    Security Area Advisor:

   - Tim Polk <[email-masked]> <[email-masked]>

For the remainder of the comments below, please take them as "explanation"
or "opinion" for you to consider in your final crafting of the charter, but
ones that need not be cleared with me before we finalize the charter. The
charter overall is in VERY good condition, and could ship as is (after
conclusion of the above). It is important to get the charter nailed asap so
we have a WG and not a BoF in Anaheim. Therefore, on these other topics,
this will be my last comment, they need not be resolved, and I trust the
chairs with the final text.

On Wed, Jan 27, 2010 at 11:00 AM, Brian Weis <[email-masked]> wrote:

> Hi Gregory,
>
> Thanks much for your comments. See replies inline, and let me know if you
> disagree with any of resolution proposals.
>
>
> On Jan 15, 2010, at 5:09 PM, Gregory M. Lebovitz wrote:
>
>  Great work guys. Inline...
>>
>>
>> At 07:01 PM 1/12/2010, Brian Weis wrote:
>>
>>> 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
>>>
>>
>> nit:
>> s/that vendors and operators can migrate to/to which vendors and operators
>> can migrate/
>>
>>  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.
>>>
>>
>> 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.

After talking more with Ross, seeing yours and Joel's comments, and after
the document authoring kick-off meeting discussions on this topic, I now
agree that we need to work it out on a case by case basis.

Perhaps the only improvement to the text would be to be explicit about the
fact that it could happen wherever. Possible new text that could be added at
the end of the paragraph in question:

"The actual protocol specification work could either be done in the
protocol's working group, or in KARP. This will necessarily be decided on a
case-by-case basis by the relevant chairs and ADs."

again, take it or leave it; I'm not blocking.

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

wfm

>
>
>  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
>>>
>>
>> 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
>>> draft-lebovitz-kmart-roadmap, although RFC 4393 may also be useful.
>>>
>>
>> s/-kmart/karp/
>>
>>
>>  - Identify deficiencies of each routing protocol in scope, and specify
>>> 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".
>>
>>
>>  - Define one or more frameworks describing the common elements for
>>> modern authentication in routing protocols.
>>>
>>
>> add:
>> This will be called the Framework document.
>>
>
> 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.

Sensible. In several of my comments I was trying to give WG-relevant names
to different things so that we would have a shared vocabulary and know what
each other were talking about more precisely. I did so based on the
difficulty from experience that I've had trying to clarify the difference
between all these things with many parties. I don't really care what name we
give any one thing, it could be FOO, just as long as we decide a name, and a
definition, and we all use it consistently so that we know what each other
are talking about. Possible text that would match this desire:

"This document will be called Framework (over time there could be more than
one such framework document)."

Again, not blocking, and no need to resolve before shipping charter.

>
>
>
>>
>>  - Publish guidance on how to create and use integrity keys used with
>>> 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:
>>
>
> 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.
>
>
>
>> 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.
>>
>
> 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.
>

Again, this was an attempt at clarification of a definition for shared
understanding. These are not routing-protocol-only people. Nor are these
security-only people. These are expected to be smallish teams of both
routing protocol and security experts working on the effort together. As
agreed above, the specification work may occur in either the rtg proto wg,
or in KARP, and will be decided on a case by case basis. I was hoping we
would give a name to all this, so that we don't have to keep typing this
entire paragraph over and over again each time we have this discussion.

again, not blocking. I leave it up to you.

Hth,
Gregory.

> Thanks!
> Brian
>
>
>
>>
>>  Goals and Milestones:
>>>
>>> Aug 2010 - Submit General Framework, General Requirements, and
>>> Priorities/Work-Plan documents to the IESG to be considered as
>>> Informational RFC
>>>
>>
>> seems agressive to me. I'd say Nov is a better bet.
>>
>>
>>  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
>>>
>>
>> Very aggressive. I'd start with Nov.
>>
>>
>>  Dec 2010 - Submit a document describing best best practices for creating
>>> and using protocol message authentication integrity keys as a BCP
>>>
>>
>> Seems reasonable.
>>
>>
>>  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
>>>
>>
>>
>> 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
>>>
>>
>>
>
> --
> Brian Weis
> Router/Switch Security Group, ARTG, Cisco Systems
> Telephone: +1 408 526 4796
> Email: [email-masked]
>
>
>
>

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks

---

From: Brian Weis <[email-masked]>
Date: Mon, 1 Feb 2010 11:46:53 -0800

Hi Gregory,

On Feb 1, 2010, at 6:28 AM, Gregory Lebovitz wrote:

> Brian,
> Most of what I see in your responses is fine. I'll give some  
> discussion below, but please don't see my comments as blocking  
> disagreement, accept for this one point:
>
> I believe we agreed that, in addition to the Routing AD(s), there  
> would be a Security AD explicitly listed as a governing AD for this  
> WG, even though it is a RTG WG, and a Security area person listed as  
> an advisor. We said this was very important because we wanted  
> intentional/responsibility-tied participation by SEC Area, and not  
> just "security consultancy". As such, could you please confirm that  
> actual charter will look something like this, so the commitment and  
> relationship is clear to one and all:

As the Routing Area Director for KARP, I believe Ross will own  
choosing the "responsible portions" portion of the charter. In any  
case, it would be very appropriate to have a Security Area Advisor. I  
expect that Ross will work with Tim & Pasi to identify someone willing  
to be that person.

Thanks,
Brian

> 	• Joel Halpern
> 	• Brian Weiss
> 	• Tim Polk <[email-masked]>
> 	• Pasi Eronen <[email-masked]>
> 	• Tim Polk <[email-masked]>
>
> For the remainder of the comments below, please take them as  
> "explanation" or "opinion" for you to consider in your final  
> crafting of the charter, but ones that need not be cleared with me  
> before we finalize the charter. The charter overall is in VERY good  
> condition, and could ship as is (after conclusion of the above). It  
> is important to get the charter nailed asap so we have a WG and not  
> a BoF in Anaheim. Therefore, on these other topics, this will be my  
> last comment, they need not be resolved, and I trust the chairs with  
> the final text.
>
>
>
> Thanks much for your comments. See replies inline, and let me know  
> if you disagree with any of resolution proposals.
>
>
> s/that vendors and operators can migrate to/to which vendors and  
> operators can migrate/
>
> 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  
> possible we'd expect to do the work in KARP. I agree it would be  
> good to clarify this in the charter.
>
> After talking more with Ross, seeing yours and Joel's comments, and  
> after the document authoring kick-off meeting discussions on this  
> topic, I now agree that we need to work it out on a case by case  
> basis.
>
> Perhaps the only improvement to the text would be to be explicit  
> about the fact that it could happen wherever. Possible new text that  
> could be added at the end of the paragraph in question:
>
> protocol's working group, or in KARP. This will necessarily be  
> decided on a case-by-case basis by the relevant chairs and ADs."
>
> 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.
>
>
> 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.
>
> 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.
>
> wfm
>
>
>
> (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
> can we create a name for these? How about "Protocol Gap Analysis".  
> Thus, the new text would be:
>
> 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.
>
> Sensible. In several of my comments I was trying to give WG-relevant  
> names to different things so that we would have a shared vocabulary  
> and know what each other were talking about more precisely. I did so  
> based on the difficulty from experience that I've had trying to  
> clarify the difference between all these things with many parties. I  
> don't really care what name we give any one thing, it could be FOO,  
> just as long as we decide a name, and a definition, and we all use  
> it consistently so that we know what each other are talking about.  
> Possible text that would match this desire:
>
> "This document will be called Framework (over time there could be  
> more than one such framework document)."
>
> 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:
>
> 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.
>
>
>
> 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.
> - 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
> add:  These we will call KARP Design Teams. These may well be very  
> close to the same teams that do the protocol gap analysis.
>
> 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.
>
> Again, this was an attempt at clarification of a definition for  
> shared understanding. These are not routing-protocol-only people.  
> Nor are these security-only people. These are expected to be  
> smallish teams of both routing protocol and security experts working  
> on the effort together. As agreed above, the specification work may  
> occur in either the rtg proto wg, or in KARP, and will be decided on  
> a case by case basis. I was hoping we would give a name to all this,  
> so that we don't have to keep typing this entire paragraph over and  
> over again each time we have this discussion.
>
> 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.
>