Subject: [karp] Progressing draft-ietf-karp-threats-reqs-05.txt

From: Gregory Lebovitz <[email-masked]>
Date: Thu, 31 May 2012 08:03:38 -0700

Note to Chairs and AD:
 The issues noted below are minor text clarifications, and NOT so
substantive -- and not at all contentious -- that an AD or IETF review
should wait for them. Please proceed with the review process, and we'll
roll these minor clarifications into a draft with any final AD / IETF
review comments.

Thanks,
Gregory

On Thu, May 31, 2012 at 7:57 AM, Gregory Lebovitz <[email-masked]>wrote:

> Hello, Uma. Thanks for your input.
>
> No, I don't believe it's too late. It looks like these are all fairly
> minor clarification issues, and no major content debates, which gives me
> great hope that we are very near completed!!
>
> Please find comments inline below. Let me know if the proposed resolution
> text for each point is ok. Once agreed, I'll issue draft-06.
>
> Manav, could you please address the last issue ASAP?
>
> Note to community:  I have updated the karp-threats-reqs issue tracker
> (google doc, public access) with ID's for the noted items below.
>
> Thanks again for the review,
> Gregory
>
>
> On Fri, May 18, 2012 at 5:00 PM, Uma Chunduri <[email-masked]>wrote:
>
>> **
>> Dear Authors,
>>
>> I read this version and the document is in good shape.
>>
>> If, it's not too late, I have few comments on the 05 version.
>>
>>
>> 1.a) Page 4: Section 1.  Introduction
>>     Third Bullet:
>>     "   o  Create specifications for cryptographic validation of routing
>>       message content."
>>     "The third bullet is being addressed in the SIDR
>>    working group."
>>    Though we can understand what SIDR is doing -  "routing message
>> content" just doesn't imply BGP message?
>>    I can understand what you are trying to say, but IMO, what is said is
>> not representative.
>>
>>
>
> How about this:
> NEW: The third bullet is being addressed in other efforts within the IETF.
> *For example, BGP message content validity is being addressed in the SIDR
> working group.*
> *
> *
> *(Tracker ID 08)*
>
>
>>   b) 7. Sec 2.4:
>>    "Message content validity (routing database validity).  This work
>>       is being addressed in other IETF efforts, like SIDR."
>>
>>    I am not sure "routing database" above is synonymous to BGP. Be
>> explicit calling out, as this can wrong impression on SIDR scope.
>>
>
> How about this:
> NEW: This work is being addressed in other efforts within the IETF. *For
> example, BGP message content validity is being addressed in the SIDR
> working group.*
> *
> *
> *(Tracker ID 08)*
>
>
>>
>>
>> 2. Section 1, Last paragraph, unnecessary ending quote.
>>
>
> Got it. Tracker ID 09.
>
>
>>
>> 3. Section 1.1, Page 6:
>>    "If session or traffic
>>       keys are being used, KMP is responsible for generating them and
>>       determining when they should be renewed."
>>
>>    This is not necessarily the only way as it sounds. KMP can also be
>> used for only master key generation and
>>    traffic keys are generated from the same by the master key consumer.
>> And also determining when the keys should
>>    be renewed may not be KMP function. So I am not quite you define KMP
>> this way.
>>
>
> Understood. How about this:
>
> NEW:   In some routing protocols traffic keys are derived by the routing
> protocol from session / master keys. In this case, KMP is responsible for
> the session / master key generation. In other cases, there are only traffic
> keys (and no session / master keys), and KMP is responsible for the traffic
> key generation.
>
> tracker ID 10.
>
>
>>
>>
>> 4. Sec 2.2:
>>    "However,in the spirit of incremental
>>    deployment, we first addressed issues like cryptographic algorithm
>>    agility, replay attacks, and TCP session resetting in the base TCP-AO
>>    protocol, and then later began work to layer key management on top of
>>    it."
>>    Though authors might have worked on AO, but the above can be better
>>    represented how TCP-AO is planned to be evolved.
>>
>
> TCP-AO's published RFC contains "cryptographic algorithm
>    agility, replay attacks, and TCP session resetting". And it is true
> that after AO's RFC published, the community began work on the key
> management for it. So I think the sentence is ok. No change.
>
>
>>
>> 5. Sec 2.3, Page 13, Point 7.
>>    " For example, designers should aim to re-use the key management
>>        protocol that will be defined for BGP's TCP-AO key establishment
>>        for as many other routing protocols as possible."
>>
>>        Why this should be BGP's TCP-AO ?? I presume, TCP-AO is a generic
>> protocol
>>        and any TCP-based pair wise RP or client/server can use this.
>> It's better to
>>        say "other routing protocols with similar
>> [characteristics/properties] as possible"
>>
>
> Understood. How about this:
> NEW:  For example, designers should aim to re-use the key management
> protocol that will be defined for BGP, which will establish keys for
> TCP-AO, for as many other routing protocols with similar characteristics
> and properties as possible.
>
> tracker ID 11
>
>
>
>
>>
>>
>> 6. Section-4 Page 20
>>    >>document(s)."
>>    Extra ending quote.
>>
>
> Got it. ID 09
>
>
>>  7."   21.  Given the number of routers that would require the new
>>         authentication mechanisms in a typical ISP deployment, solutions
>>         can increase their appeal by minimizing the burden imposed on
>>         all routers in favor of confining significant work loads to a
>>         relatively small number of devices.  Optional features or
>>         increased assurance that engenders more pervasive processing
>>         loads MAY be made available for deployments where the additional
>>         resources are economically justifiable."
>>      What is the requirement?
>>
>
> We've been back and forth on this requirement since its original
> insertion, i.e. you are not the only one with this question. I'm going to
> let my co-author, Manav, handle this question. I've entered it on the
> tracker as ID 12. Manav, could address this ASAP?
>
> Thanks again, Uma, for the detailed review,
> Gregory
>
>
>
>>
>> --
>> Uma C.
>>
>>
>>  ------------------------------
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Gregory Lebovitz
>> *Sent:* Thursday, May 10, 2012 11:04 AM
>> *To:* [email-masked]; Brian Weis; Bhatia, Manav (Manav)
>> *Subject:* Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt
>>
>> Hey all,
>> This version -05 addressed all the known content issues (a total of 6)
>> that were brought to our attention during the 2nd WG LC.
>>
>> Brian - I think we are ready to go back for IESG approval.
>>
>> FYI, we started a simple GoogleDoc tracker for this last version. It is
>> located here:
>>
>>
>> https://docs.google.com/document/d/10lSS99Rq3wCDKgyrNuv-9dxbbInOIIVDb_BWaPxrm9Q/edit
>>
>> Hope it helps,
>> Gregory
>>
>> On Thu, May 10, 2012 at 10:53 AM, <[email-masked]> wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories. This draft is a work item of the Keying and Authentication for
>>> Routing Protocols Working Group of the IETF.
>>>
>>>        Title           : Keying and Authentication for Routing Protocols
>>> (KARP) Overview, Threats, and Requirements
>>>        Author(s)       : Gregory Lebovitz
>>>                          Manav Bhatia
>>>        Filename        : draft-ietf-karp-threats-reqs-05.txt
>>>        Pages           : 32
>>>        Date            : 2012-05-10
>>>
>>>   Different routing protocols exist and each employs its own mechanism
>>>   for securing the protocol packets on the wire.  While most already
>>>   have some method for accomplishing cryptographic message
>>>   authentication, in many cases the existing methods are dated,
>>>   vulnerable to attack, and employ cryptographic algorithms that have
>>>   been deprecated.  The "Keying and Authentication for Routing
>>>   Protocols" (KARP) effort aims to overhaul and improve these
>>>   mechanisms.
>>>
>>>   This document does not contain protocol specifications.  Instead, it
>>>   defines the areas where protocol specification work is needed and a
>>>   set of requirements for KARP design teams to follow.  RFC 6518,
>>>   "Keying and Authentication for Routing Protocols (KARP) Design
>>>   Guidelines" is a companion to this document; KARP design teams will
>>>   use them together to review and overhaul routing protocols.  These
>>>   two documents reflect the input of both the IETF's Security Area and
>>>   Routing Area in order to form a mutually agreeable work plan.
>>>
>>>   This document has three main parts.  The first part provides an
>>>   overview of the KARP effort.  The second part lists the threats from
>>>   RFC 4593, Generic Threats To Routing Protocols, that are in scope for
>>>   attacks against routing protocols' transport systems, including any
>>>   mechanisms built into the routing protocols themselves, which
>>>   accomplish packet authentication.  The third part enumerates the
>>>   requirements that routing protocol specifications must meet when
>>>   addressing those threats for RFC 6518's "Work Phase 1", the update to
>>>   a routing protocol's existing transport security.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> This Internet-Draft can be retrieved at:
>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt
>>>
>>> The IETF datatracker page for this Internet-Draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/
>>>
>>> _______________________________________________
>>> karp mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/karp
>>>
>>
>>
>>
>> --
>> ----
>> IETF related email from
>> Gregory M. Lebovitz
>>
>>
>
>
> --
> ----
> IETF related email from
> Gregory M. Lebovitz
>
>

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