Re: [karp] Clearing your DISCUSS on draft-ietf-karp-threats-reqs

[Gregory Lebovitz <[e-mail]>]

I'm about to post -07 of the threats-reqs document. The authors have
addressed all issues raised on Sean's second round of DISCUSS during IESG
review, and Sean has now signed off. The details are all inline below.
(cc'ing the KARP mail list so we have a public record of the DISCUSS issues
and their resolutions.)

Let's publish!!

Gregory

On Sun, Dec 16, 2012 at 10:37 PM, Bhatia, Manav (Manav) <
[e-mail]> wrote:

> **
> Hi,
>
> I am in complete agreement with everything that Gregory has written here
> and especially the part about getting the document delayed for this long
> without radically improving the readability or the content of the document
> ! :-)
>
> I am ok, as i had said earlier, with the latest version -07 and i think we
> should just get it outta our door now!
>
> I would also concur with Greg on including Brian as a co-author, if thats
> acceptable to Brian!
>
> Cheers, Manav
>
>  ------------------------------
> *From:* Gregory Lebovitz [mailto:[e-mail]]
> *Sent:* Monday, December 17, 2012 11:31 AM
> *To:* Brian Weis
> *Cc:* Gregory Lebovitz; Bhatia, Manav (Manav); Sean P. Turner
>
> *Subject:* Re: Clearing your DISCUSS on draft-ietf-karp-threats-reqs
>
> Brian, Manav & Sean,
> Boyz, let's get this thang done!! :-)
>
> I think it most direct to comment inline to this original email, even
> though the last correspondance on the thread was actually Dec 1.
>
> I'm also wondering, Sean, why did you send your comments to Brian, and not
> to Manav and I, the authors? Although at this point I think Brian has put
> so much work into this document that you ought to be on the author list
> too. (see my comment at the end, below, about Brian and author
> recognition). No accusation here, Sean. Just curious.
>
> Comments inline below...
>
>
> On Wed, Nov 21, 2012 at 5:54 PM, Brian Weis <[e-mail]> wrote:
>
>> Hi Gregory and Manov,
>>
>> Almost done, but Sean has a couple remaining issues. I've attached a
>> version with proposed edits to deal with them. Please correct or say you
>> can live with them. I've added some explanatory text inline.
>>
>> On Nov 13, 2012, at 2:46 PM, Sean Turner <[e-mail]> wrote:
>>
>> > Just got two left.  Maybe I can do this quicker here and you can tell
>> me if I'm just not getting it (entirely possible):
>> >
>> > 1) s4 #3: Algorithm agility means that the protocol doesn't hard code
>> an algorithm in.  That's covered here, but there's also this:
>> >
>> >  Additionally, more than one algorithm MUST be specified.
>> >
>> > which could be a whole lot more - is it two MTI algorithms?  I don't
>> want people to misinterpret this later down the road.  Maybe an example
>> would clear this up: "(i.e., one mandatory to implement algorithm and one
>> or more backup algorithms to guide transition)."
>>
>> I think it's time to capitulate on two mandatory to implement algorithms.
>> But it is important to specify two algorithm, so it makes sense to me to
>> specify more than one but only mandate one.
>>
>
> Ok. I don't agree, but I'm willing to let this go for the sake of getting
> the document done.
>
> The only way to be sure implementations can really move between multiple
> algorithms, and do so with interoperability,  is for them to actually have
> multiple algorithms implemented, and test both during bake-offs. I know
> from experience, the hard way, with both IKEv1 and IKEv2. Two MTI's is the
> only way to ensure this.
>
> However, I think the text proposed in -07 is about as strong as you can
> get without actually mandating two MTI's:
>
>         Mandating support for two algorithms (i.e., one
>         both redundancy, and a mechanism for enacting that redundancy.
>    mandatory
>         to implement algorithm and one or more backup
>         algorithms to guide transition) provides both redundancy, and a
>         mechanism for enacting that redundancy.
>
> I will not block on this issue. The -07 text may stand.
>
>
>
>>
>> >
>> > 2) s4 #5: I'm confused whether the SHOULD in the first paragraph is for
>> intra-session replay and the MUST is for inter-session?  It's probably also
>> worth defining what the two are in the terminology section.
>> >
>> > Anyway let me give this a shot and see what you think:
>> >
>> > Terminology:
>> >
>> >  Replay Attacks: For non-TCP based protocols like OSPF [RFC2328],
>> >  IS-IS [RFC1195], etc., two routers are said to have a session up
>> >  if they are able to exchange protocol packets (i.e., the peers
>> >  have an adjacency).  Messages replayed during an adjacency are
>> >  intra-session replays while message replayed between two peers
>> >  who re-establish an adjacency after a reboot or loss of
>> >  connectivity are inter-session replays.
>> >
>> >
>> > 5. Routing Protocols (or the transport or network mechanism
>> >    protecting routing protocols) SHOULD be able to detect and
>> >    reject replayed messages both intra-session and inter-session.
>> >
>> >    Packets captured from one session MUST not be able to be re-sent
>> >    and accepted during a later session (i.e., inter-session replay).
>> >    Additionally, replay mechanisms MUST work correctly even in the
>> >    presence of routing protocol packet prioritization by the router.
>>
>> I mostly implemented this, except I think the proper Terminology addition
>> is "Replayed Messages" not "Replay Attacks" so I've  reworded it to meet
>> that term.
>>
>
>
> Do I think the new text in -07 for these two points is better? Yes, albeit
> marginally. Do I think the document, as a whole will be more successful
> because of it? Not at all. I'd have rather seen this published 3 months
> ago. But that's the past now. Changes approved.
>
>
>
>>
>> >
>> > is this a little clear for the last paragraph?:
>> >
>> >    For protocols like OSPF [RFC2328], IS-IS [RFC1195], BFD [RFC5880],
>> >    and RIP [RFC2453] that currently share the same authentication and
>> >    message integrity key on a broadcast segment, it is important that
>> >    an integrity check associated associated with a message fail if an
>> >    attacker has replayed the message with a different origin.
>>
>> This mostly makes sense to me, but I did reword it. I retained the
>> initial sentence.
>>
>
> I approve the text in -07 on this point. (Again, I don't think it will
> make the document any more successful; I think we are WAY beyond the point
> of truly material critique).
>
>
>>
>> >
>> > and now for a bunch of nits:
>> >
>> > 1)  s2.3: Step 4: Still having issues with the following but I think
>> you're getting closer:
>> >
>> > Measurably, we
>> > would like to see an increase in the number of surveyed
>> > respondents who report deploying the updated authentication and
>> > integrity mechanisms in their networks, as well as a sharp rise
>> > in usage for the total percentage of their network's routers.
>> >
>> > I think they're trying to say this:
>> >
>> > We would like to see a measurable increase in the number of surveyed
>> > respondents who report [ISR2008] deploying ....
>>
>> I wrote something similar to this.
>>
>
> fine. (Again, will NOT make the document materially more successful.)
>
>
>> >
>> > 2) 2.3: step 4: r/(iBGP/(iBGP)
>> >
>> > 3) s2.4: If you mention Confidentiality as a non-goal.  It would also
>> be good to also include non-repudiation:
>> >
>> >  o  Confidentiality and non-repuidation of the packets on the wire.
>> >     Once this roadmap is realized, we may revisit work on
>> >     confidentiality and non-repudiation.
>>
>> This is truly a non-goal, but should always be a non-goal. I don't ever
>> want to revisit work on "non-repudiation". How about if we add it to the
>> list of non-goals, but remove half-promises about possibly working on them
>> in the future? Or was this a hot button to someone?
>
>
> The text about confidentiality was indeed a hot button to the folks that
> tried to get us to work on confidentiality in this go around. It was
> compromise text, that we leave the door open for work later. (And this is a
> difficult side effect of doing IETF last calls, and then letting the IESG
> do their reviews:  IESG can push / demand for things to change that were
> the result of WG tussles, negotiations, and compromises, and then the doc
> gets changed and published without the WG really okaying those changes.)
>
> Personally, I don't care. But as a document editor, trying hard to
> neutrally include as much input as reasonably possible from the WG, I feel
> I'd be failing that minority if we just cut the text behind the scenes at
> the last minute.
>
> Attached is an XML -07a with the following:
>
> "The following goals are considered out-of-scope for this effort:
>  o  Confidentiality of the packets on the wire. Once this roadmap is
> realized, work on confidentiality may be considered.
>
>  o Non-repudiation of the packets on the wire.
>
>  o Message content validity... "
>
>
>>
>> > 4) s3.3, INTERFERENCE: denial of receipt is one of the non-repudiation
>> so maybe:
>> >
>> >   DENIAL OF RECEIPT (non-repudiation)
>>
>
> fine.
>
>
>> >
>> > 5) s5 #6: r/MUST not/MUST NOT
>>
>
> This was actually s4 #5, I think. Fine.
>
>
>
>> >
>> > 6) s4 #7: I think it's true that any good policy would require a key
>> changed ... r/Keys may need to/Keys need to
>>
>> This is a hot button I think, so I suggest we leave the existing text.
>>
>
> Agreed. Further, changing it wouldn't make the document more successful.
> And Sean listed it as a "Nit". Text unchanged.
>
>
>>
>> >
>> > 7) s4 #14: Maybe: r/immediately verifiable by/immediately and
>> independently verifiable by
>>
>
>
> Fine.
>
>
>
>> >
>> > 9) s4 #19: I think the 1st and 3rd sentences are duplicated.  And "some
>> benefit" is a little squishy:
>> >
>> > 19.  Every new KARP-developed security mechanisms MUST support
>> >        incremental deployment.
>> >
>> >        Proposed solutions MUST
>> >        support an incremental deployment method that provides some
>> >        benefit for those who participate.
>>
>> There a purpose for each of the lines here. I do suggest changing
>> "provides some benefit" to "that benefits" to make it sound less squishy.
>>
>
> Fine (again, will not make a difference to the documents success either
> way).
>
> Brian, I'd like to ask your approval to add you to the author/editor list,
> given all the work you've done on this over the last year and a half. Do
> you approve? Assuming so, I've added you in the -07a, and touched up the
> Acknowledgements accordingly. You'll want to double check your details
> under the Author's Addresses section (I pouched them from RFC6411). Once
> done you can send me the -07b xml and I'll publish it (or feel free to
> publish it yourself, either way is fine).
>
> Glad to move this to publishing!! Thanks to you all for your hard work.
>
> Do you guys mind if I send this email to the WG, so Sean's and our
> comments become a matter of the open process record?
>
> Gregory
>
>
>>
>> Let me know,
>> Brian
>>
>>
>>
>>
>> >
>> > spt
>> >
>> > On 11/7/12 3:11 PM, Brian Weis wrote:
>> >> Hi Sean,
>> >>
>> >> Just a gentle reminder ... looks like the DISCUSS hasn't been cleared
>> yet: <
>> http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ballot/>. I
>> know this week is busy but maybe early next week you could take care of it?
>> >>
>> >> Thanks!
>> >> Brian
>> >>
>> >> On Oct 29, 2012, at 2:14 PM, Sean Turner <[e-mail]> wrote:
>> >>
>> >>> Got this I'll get to it hopefully by tomorrow, but definitely by
>> Friday.
>> >>>
>> >>> spt
>> >>>
>> >>> On 10/25/12 12:51 PM, Brian Weis wrote:
>> >>>> Hi Sean,
>> >>>>
>> >>>> You had a lengthy DISCUSS on draft-ietf-karp-threats-reqs, mostly as
>> a result of Steve Kent's SecDir review. I have worked extensively with the
>> authors, and we believe that all of the comments have been resolved in -06.
>> We also re-checked Steve's actual SecDir review and considered comments
>> that you may not have entered in your DISCUSS. Please let us know if
>> there's any more information that you need to clear your DISCUSS, and I'll
>> be happy to provide it.
>> >>>>
>> >>>> I would ask if you could work through this soon, so that we can move
>> on in KARP. I apologize for not reaching out sooner, but I misunderstood
>> the process at this point. Diffs are here: <
>> http://tools.ietf.org/rfcdiff?url2=draft-ietf-karp-threats-reqs-06.txt>.
>> >>>>
>> >>>> Thanks,
>> >>>> Brian
>> >>>>
>> >>
>> >>
>>
>>
>>
>
>
> --
> ----
> IETF related email from
> Gregory M. Lebovitz
>
>


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