Subject: Re: [karp] Fwd: Re: Russ Housley's Discuss on draft-ietf-karp-design-guide-05: (with DISCUSS and COMMENT)

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Nov 2011 04:57:39 -0400

At 10:19 PM -0400 10/8/11, Joel M. Halpern wrote:
>Russ Housley raised a discuss as to whether the design guidelines 
>document should address the "common framework" for applying security 
>to routing protocols that is called for in our charter.
>
>there are multiple opinions on this.
>
>Russ asked what the WG's opinion is, which seems an appropriate question.
>
>So, folks, comments?
>
>Thank you,
>Joel

Sorry I missed this when  you posted it to the list.

I agree that we ought to be addressing the "common framework" as part 
of the design guidelines.

Steve

---

From: Sam Hartman <[email-masked]>
Date: Thu, 03 Nov 2011 17:18:26 -0400

>>>>> "Joel" == Joel M Halpern <[email-masked]> writes:

    Joel> Russ Housley raised a discuss as to whether the design
    Joel> guidelines document should address the "common framework" for
    Joel> applying security to routing protocols that is called for in
    Joel> our charter.

    Joel> there are multiple opinions on this.

    Joel> Russ asked what the WG's opinion is, which seems an
    Joel> appropriate question.

    Joel> So, folks, comments?

I think that the design guide does address common elements that
cross routing protocol boundaries.
I also believe that the process would not be served by delaying the
design guide in order to add significant text about a common approach.

If Russ believes this is just an issue of following process and is
overall happy with the progress we're making, I'd urge him to consider
whether the DISCUSS position is likely to improve the output of the WG
or just delay focusing on actually improving routing protocols and
getting automated key management. If Russ believes the approach we're
considering for the protocols we've actually looked at is somehow
flawed, or that we're missing common elements, then perhaps we should
give him as much time as he needs to present his concerns in IETF 82 so
we can understand them.

---

From: Russ Housley <[email-masked]>
Date: Mon, 7 Nov 2011 08:25:08 -0500

> design guide in order to add significant text about a common approach.

So, this is the part where we disagree.  I do not think the current document does a very good job at documenting common design elements.  By doing so now, the I think the WG will save a lot of time as each routing protocol is considered.  I am asking if others agree.  If there is not support for this position, then I will clear.

Russ

---

From: Sam Hartman <[email-masked]>
Date: Mon, 07 Nov 2011 14:16:14 -0500

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> So, this is the part where we disagree.  I do not think the
    Russ> current document does a very good job at documenting common
    Russ> design elements.  By doing so now, the I think the WG will
    Russ> save a lot of time as each routing protocol is considered.  I
    Russ> am asking if others agree.  If there is not support for this
    Russ> position, then I will clear.

If you put together some slides talking about the sort of elements
you're looking for and we had some discussion about what we think we can
do I know I'd be very interested in the presentation and discussion.

---

From: Russ Housley <[email-masked]>
Date: Thu, 10 Nov 2011 20:01:15 -0500

Sam:

I hope my note to Glen answers your question.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Nov 2011 03:46:03 -0500

Glen:

>> So, this is the part where we disagree.  I do not think the current document does a very
>> good job at documenting common design elements.  By doing so now, the I think the
>> WG
> 
> Mind elaborating what you mean by not documenting common design elements?

Since we know that manual key management must be supported, the WG has decided to specify a crypto key table.  Manual key management is populating the table, but this needs to be accomplished using an interface that protects the keying material from disclosure or alteration.

In addition, we want to specify automated key management.  A protocol to automatically populate the crypto key table will be used.  Several cases need to be considered:

1) pairwise keys -- IKEv2 and TLS already offer mechanisms that are directly applicable.

2) group keys --

2a) group keys distributed by a key center -- KeyProv offers mechanisms that are directly applicable, but additional attributes may be needed.

2b) group keying protocols -- new protocol work is needed for this approach to be employed.

A design guide ought to say what work needs to be done and when each of these cases ought to be employed.

Russ

---

From: Joe Touch <[email-masked]>
Date: Fri, 11 Nov 2011 04:31:15 -0800

> 1) pairwise keys -- IKEv2 and TLS already offer mechanisms that are directly applicable.

FWIW, based on other recent discussions, it would be useful to know 
whether such keys need to be unidirectional or can be bidirection, and 
whether multiple concurrent keys between the same two endpoints is 
expected (i.e., for separate assocations, not as a key rollover issue).

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Nov 2011 07:41:27 -0500

This seems reasoanble, clear, and something that we can act on.
Authors, can you do what is requested?

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 11 Nov 2011 11:02:06 -0500

Given your and Manav's concern, we will try to include time for 
discussing this at the meeting in Taipei.  I look forward to your note 
to the list, and hope other folks will respond to you  beteen your 
posting and our WG session.

Thank you,
Joel

On 11/11/2011 10:26 AM, Sam Hartman wrote:
>>>>>> "Joel" == Joel M Halpern<[email-masked]>  writes:
>
>      Joel>  This seems reasoanble, clear, and something that we can act
>      Joel>  on.  Authors, can you do what is requested?
>
> I actually kind of disagree with it.  I don't think this belongs in the
> design guide.  I'll have mail explaining my position to the list by the
> meeting.
>
> I'd prefer that a document that attempts to address this not get
> approved before we can discuss whether Russ is right.
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 11 Nov 2011 17:55:57 -0500

Joe:

> FWIW, based on other recent discussions, it would be useful to know whether such keys need to be unidirectional or can be bidirection, and whether multiple concurrent keys between the same two endpoints is expected (i.e., for separate assocations, not as a key rollover issue).

These are attributes that are stored in the crypto key table under the current draft.

Russ