Subject: [karp] [Fwd: re: Draft KARP BoF charter]

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 04 Nov 2009 18:38:10 -0500

Held up due to who knows what confusion in the tools...

-------- Original Message --------
Subject: re: Draft KARP BoF charter
Date: Wed, 4 Nov 2009 15:30:07 -0500
From: Francois Le Faucheur <[email-masked]>
To: [email-masked] <[email-masked]>
CC: Le Faucheur Francois <[email-masked]>

Hi,

Here is a couple of small suggestions on the draft KARP BOF charter as
per:
http://www.ietf.org/mail-archive/web/karp/current/msg00049.html

* I understand the KARP scope includes protocols that can easily be
considered as "routing protocols" (e.g. BGP, OSPF, ISIS, ) as well as
protocols that are not really "routing protocols" (e.g. RSVP-TE, LDP,
BFD). Would it be appropriate to bring up in the charter another term
for the "non-routing protocols"? Could the charter mention "routing
protocols and signaling protocols"?

* Can KARP aim at addressing RSVP in general (as opposed to just RSVP-
TE)?

Thanks.

Francois

PS: I didn't follow the KARP activity so apologies if this has already
been discussed.

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Thu, 05 Nov 2009 01:12:27 -0800

inline...

>protocols and signaling protocols"?

This seems like a very reasonable distinction to me. Anyone object?

There may be two or three distinctions to make:
  - Routing Protocols
  - Signaling Protocols
  - Discovery Protocols

Now, LDP and BGP and MDCP are a signaling, a routing and  adiscovery 
protocol respectively. All run over TCP, with similar transaction 
models, so once we are done with TCP-AO, then we have succeeded in 
providing authentication for them all. It may be similar for some of 
the link-local broadcasting type protocols, which would include OSPF, 
IS-IS and PIM-SM, among others.

>* Can KARP aim at addressing RSVP in general (as opposed to just RSVP-

"Can it?" is a question that could be read in many ways:
  - "Is it possible?" Sure, anything is possible, given enough time, 
money and resource, and we are smart people who can do anything we 
put our minds to.
  - "Should it be our first priority?" No, I don't think so. We have 
far more demand from the PIM and OSFP and IS-IS communities than I've 
heard from the RSVP community. And the threat landscape is much much 
broader for those than for RSVP.
  - "Should it be on the very first KARP charter?" Not sure. I can 
see the answer going either way. Personally, I'd rather see us 
charter narrowly, and succeed, then add more things to the charter, 
than to try to take on too much right at the start.
  - "Is there a good reason why -TE is there, but not RSVP in 
general?" This I don't know the answer to. Anyone else have the 
background or thoughts?

Hope that helps,
Gregory.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Nov 2009 07:41:27 -0500

My personal read on why RSVP-TE rather than just RSVP...
RSVP is a host-to-host protocol that happens to be proxyable, and is 
processed by routers.  RSVP-TE is a router-router protocol.

Is that really a good reason for doing one and not the other?  I have no 
idea.

Joel

Gregory M. Lebovitz wrote:
...
> money and resource, and we are smart people who can do anything we put 
> our minds to.
>  - "Should it be our first priority?" No, I don't think so. We have far 
> more demand from the PIM and OSFP and IS-IS communities than I've heard 
> from the RSVP community. And the threat landscape is much much broader 
> for those than for RSVP.
>  - "Should it be on the very first KARP charter?" Not sure. I can see 
> the answer going either way. Personally, I'd rather see us charter 
> narrowly, and succeed, then add more things to the charter, than to try 
> to take on too much right at the start.
>  - "Is there a good reason why -TE is there, but not RSVP in general?" 
> This I don't know the answer to. Anyone else have the background or 
> thoughts?
> 
> Hope that helps,
> Gregory.

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Thu, 05 Nov 2009 09:48:02 -0800

At 05:37 AM 11/5/2009, Francois Le Faucheur wrote:
>Joel, Gregory,
>
>Let me clarify my input re RSVP:
>         * I have the impression that some of KARP general objectives of
>modernizing/enhancing/facilitating-deployment of security for 
>routing/ signaling/discovery protocols are applicable to RSVP. Perhaps, this
>could translate into a nice group keying solution among RSVP/RSVP-TE
>routers (not sure about applicability to hosts).
>         * I personally would like to see that happen sooner than later.
>         * I understand there are competing priorities
>         * when RSVP-TE is considered by KARP, I recommend that RSVP is
>considered at the same. If a common solution cannot be devised to
>address all RSVP requirements (let's say because of the "host" aspect
>brought up by Joel, just as an example), then I would suggest the WG
>documents applicability & restrictions of the mechanism for RSVP (e.g.
>continuing on with the previous example, that may be to limit
>applicability of the KARP mechanism to securing RSVP on routers and
>exclude Hosts).

Francois,
Speaking as an individual contributor here (i.e. not a BoF shepherd 
or any other role), I think your suggestion is 100% reasonable and support it.

We did pretty much the same thing during the TCP-AO effort. Yes, 
TCP-AO could be used by hosts for any number of different 
applications. However, when we looked at the requirements and 
priorities and such we focused on the solution required to secure 
BGP/LDP/MSDP, and excluded every other application, where including 
it would have taken us into more requirements or different solution spaces.

I understand you suggesting the same thing, i.e. in as much as we can 
solve authentication for RSVP while doing RSVP-TE, let's do so. 
Otherwise, we'll push it off until later.

Gregory.

>Thanks for considering this input.
>
>Francois
>
>On 5 Nov 2009, at 13:41, Joel M. Halpern wrote:
>
>>Is that really a good reason for doing one and not the other?  I
>>have no idea.
>>
>>Joel
>>
>>>far more demand from the PIM and OSFP and IS-IS communities than
>>>I've heard from the RSVP community. And the threat landscape is
>>>much much broader for those than for RSVP.

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Thu, 05 Nov 2009 09:51:39 -0800

>Thanks for considering this input.

PART II - now let me ask a different question altogether:  why should 
we spend time on RSVP-TE/RSVP at all? Why is it important to solve 
now? By way of prioritizing, what protocols do you believe is more 
important for us to focus on in KARP than it/them? (by answering the 
last question, anything you do not list as more important we will 
assume to be less important).

Others please feel free to weigh in on this too.

Gregory

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Thu, 05 Nov 2009 11:07:04 -0800

At 10:49 AM 11/5/2009, Francois Le Faucheur wrote:

>On 5 Nov 2009, at 18:51, Gregory M. Lebovitz wrote:
>
>>PART II - now let me ask a different question altogether:  why
>>should we spend time on RSVP-TE/RSVP at all?
>
>RSVP-TE is deployed in many SP Core.
>RSVP is deployed in some enterprise network and also considered by
>some SP for Video reservation & admission control.
>My perception is that in practice, the current RSVP security
>mechanisms are not easily deployable because they depend on either
>static key provisioning (which is operationally painful) or IKE key
>negotiation (which is somewhat heavy for some). An easy-to-deploy
>option (e.g. some dynamic group key distribution approach) would be a
>good practical step forward.
>
>>Why is it important to solve now?
>
>I would personally like this problem to be solved now because it would
>increase the security of the current deployments I talked about above.
>Now, I won't argue that it is the most important security painpoint to
>solve. It is not.
>
>I seem to remember from a cursory scan of the KARP archive that
>someone (or perhaps it was even in the charter) argued that there is
>higher priority/urgency to enhance security at trust boundaries as
>compared to enhance security within a trust domain because the inner
>of the trust domain can always be somewhat protected/isolated from the
>evil outside world via conventional protection mechanism (while a
>device at the edge of the trust domain is fully exposed). That seems
>like a reasonable argument to me. If that logic is followed by the
>working group, it would suggest that RSVP/RSVP-TE be taken on in the
>lower priority batch, since the deployments are currently
>predominantly intra-domain.

(I know I'm pushing a bit here, I hope you don't mind...)
And what other intra-domain protocols would you place ahead of it, if 
any? OSPF? IS-IS? RIP?

Gregory.

>Francois
>
>
>>By way of prioritizing, what protocols do you believe is more

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 5 Nov 2009 14:37:52 +0100

Joel, Gregory,

modernizing/enhancing/facilitating-deployment of security for routing/ 
signaling/discovery protocols are applicable to RSVP. Perhaps, this  

Francois

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 5 Nov 2009 19:49:42 +0100

Francois