Subject: [Tsvwg] draft-behringer-tsvwg-rsvp-security-groupkeying: Scope?

From: Bob Briscoe <[email-masked]>
Date: Thu, 26 Jul 2007 12:49:37 +0100

Michael,

Last night I read this draft, which you will be presenting today in tsvwg.

It was a useful tutorial for me, because I wasn't aware of all the group 
keying work for signalling that you describe.

1/ First a classic (picky?) security question: You talk about one RSVP node 
trusting the next. A future draft needs to answer the question "Trust to do 
what?"

You seem to imply you mean "Trust to maintain the integrity of RSVP 
messages and to maintain the next link in the chain of integrity checking". 
And later you implicitly add "Trust to keep the contents of the RSVP 
messages secret"

But, as this is a key management draft, you probably mean trust in message 
integrity _and_ semantics, ie "Trust to do all the things the RSVP protocol 
says you will do", e.g. things like traffic policing on behalf of others 
[RFC2210], protecting downstream RSVP nodes from overload [RFC2209] etc.

2/ WG Scope

2.1 PCN: Second, your draft is very relevant to the PCN working group. In 
PCN, the next RSVP hop is deliberately very distant from the previous one 
in IP hop terms. On Tue I raised this point and referred to your draft in 
my review of the PCN architecture:
<http://www1.ietf.org/mail-archive/web/pcn/current/msg00584.html>
(long - scroll right to the last para).
After yesterday's mtg, the PCN WG chairs are about to put this draft to the 
list for consideration as a WG item.

The PCN WG scope is currently restricted to one domain. So only message 
integrity is relevant (so a node receiving a message knows it didn't come 
from some random user spoofing the neighbouring RSVP router).

The PCN charter also says multi-domain should be kept in mind where it 
might change anything done for single domain. You'll see I also refer to 
the problem of trust in the semantics of reservation messages in my 
currently individual draft on solving (some) PCN security problems in a 
multi-domain scenario:
<draft-briscoe-re-pcn-border-cheat-00.txt>

2.2 NSIS: I guess your draft is just as relevant to NSIS as to RSVP, but to 
remain concrete, you will probably want to just say that the scope is wider 
but focus on one signalling system.

Bob

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Jul 2007 14:26:22 +0200

Hi

Bob Briscoe wrote:
> It was a useful tutorial for me, because I wasn't aware of all the 
> group keying work for signalling that you describe.
>
> 1/ First a classic (picky?) security question: You talk about one RSVP 
> node trusting the next. A future draft needs to answer the question 
> "Trust to do what?"
>
> messages and to maintain the next link in the chain of integrity 
> checking". And later you implicitly add "Trust to keep the contents of 
> the RSVP messages secret"
>
> But, as this is a key management draft, you probably mean trust in 
> message integrity _and_ semantics, ie "Trust to do all the things the 
> RSVP protocol says you will do", e.g. things like traffic policing on 
> behalf of others [RFC2210], protecting downstream RSVP nodes from 
> overload [RFC2209] etc.
>
The term "trust" is always confusing.

In short: You want to deal with a modified threat model in RSVP where 
you would like to protect the communication between  RSVP nodes when 
they traverse non-RSVP nodes.

> 2/ WG Scope
>
> 2.1 PCN: Second, your draft is very relevant to the PCN working group. 
> In PCN, the next RSVP hop is deliberately very distant from the 
> previous one in IP hop terms. On Tue I raised this point and referred 
> to your draft in my review of the PCN architecture:
> After yesterday's mtg, the PCN WG chairs are about to put this draft 
> to the list for consideration as a WG item.
>
> The PCN WG scope is currently restricted to one domain. So only 
> message integrity is relevant (so a node receiving a message knows it 
> didn't come
> might change anything done for single domain. You'll see I also refer 
> to the problem of trust in the semantics of reservation messages in my 
> currently individual draft on solving (some) PCN security problems in 
> a multi-domain scenario:
I also think that PCN is a good use case for Michael's draft.
> 2.2 NSIS: I guess your draft is just as relevant to NSIS as to RSVP, 
> but to remain concrete, you will probably want to just say that the 
> scope is wider but focus on one signalling system.
>
No; it is isn't relevant based on how NSIS works. It does provide this 
functionality already but in a different way.

Ciao
Hannes

> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pcn

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Thu, 26 Jul 2007 07:42:46 -0500

Hi,

> I also think that PCN is a good use case for Michael's draft.

Group keying should come in handy for any form of "aggregation" where  
RSVP nodes are separated by an aggregation cloud and where the  
Aggregator does not know ahead of time what is the Deaggregator. So  
besides PCN, it should also be applicable to RFC3175 and RFC4860.

Cheers

Francois

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 26 Jul 2007 13:54:28 +0100

Hannes,

At 13:26 26/07/2007, Hannes Tschofenig wrote:
>>2.2 NSIS: I guess your draft is just as relevant to NSIS as to RSVP, but 
>>to remain concrete, you will probably want to just say that the scope is 
>>wider but focus on one signalling system.

ref? I'm interested.

bob

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Jul 2007 15:47:50 +0200

Hi Francois,

> besides PCN, it should also be applicable to RFC3175 and RFC4860.
I agree with you.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Jul 2007 15:50:22 +0200

Hi Bob,

Bob Briscoe wrote:
>> No; it is isn't relevant based on how NSIS works. It does provide 
>> this functionality already but in a different way.
>
> ref? I'm interested.
>
The functionality was dumped into the main specification:
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-14.txt

Let me know if you need a bit of background.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Jul 2007 15:50:29 +0200

Hi Bob,

Ciao
Hannes