Subject: [tsvwg] New rev of IntServ MULTI_TSPEC

From: "James M. Polk" <[email-masked]>
Date: Thu, 16 Jul 2009 18:42:04 -0500

TSVWG

[with my individual hat on]

We have updated the ID for the Integrated Services extension for 
multiple bandwidths in a single message.

http://www.ietf.org/internet-drafts/draft-polk-tsvwg-intserv-multiple-tspec-01.txt

As the WG wanted from the preso given at IETF75 in TSVWG...

- we focused the proposal on Option#3 (leaving the TSPEC alone, and 
creating the new MULTI_TSPEC Object for all subsequent TSPECs in the 
PATH message)

- we have addressed the RSPEC issue - concluding there needs to be an 
RSPEC per TSPEC for Guaranteed Service. I explain this and show it as 
well in the ID now.

- with above conclusion means I can't just have a MULTI_TSPEC, but I 
have to limit that object for just the PATH message, and create a 
MULTI_FLOWSPEC for the RESV message. I explain this and show it as 
well in the ID now.

- we consolidated all the rules of usage into their own section, so 
there's only 1 place to have to look for this information.

- we streamlined part of the doc to flow better.

A number of folks commented specifically about there being 3 options 
proposed forward, that once we choose 1 (and the WG did), that the 
others remain in the doc so there isn't a discussion in the years to 
come about "why we didn't do *it8* another way".  We moved all the 
text for Options #1 and 2 to the appendix, but do not know if the 
existing section 2 - which talks about the pluses and minuses of each 
solution - should be all we say (i.e., thereby reducing the length of 
the doc, given the point is probably made about the other options).

We would like feedback on that issue, and others raised in the doc.

Comments are appreciated

BTW - we plan to ask the WG if this is worth taking on as a WG item, 
given all the discussion on the list and at the SF TSVWG meeting.

James

---

From: Lars Eggert <[email-masked]>
Date: Sun, 26 Jul 2009 15:20:12 +0200

Hi,

writing as an individual, with regards to the amplification attack I  
brought up as a comment from the mike at the last meeting, the draft  
now says:

>    A misbehaving Calling Node can include too many TSPECs in the
>    MULTI_TSPEC object, which can lead to an amplification attack. That
>    said, a bad implementation can create a reservation for each TSPEC
>    received from within the Resv message. The number of TSPECs in the
>    new MULTI_TSPEC object is limited, and the spec clearly states that
>    only a single reservation is to be set up per Resv message.

I think this text is inaccurate and maybe even misleading.

First, the issue isn't that a "misbehaving node" may include a few too  
many TSPECs in the packet - it's that an actively malicious attacker  
will cram as many TSPECs into an object as possible, in order to eat  
control plane cycles and data plane bandwidth.

Second, the number of TSPECs is limited in the draft, but the limit is  
17 (Section 3.2), which is a nice big amplification factor, esp.  
considering that the concern here isn't just dataplane bandwidth but  
also control plane overload. Yes, only a single reservation will be  
set up in the end, but the processing overhead goes up with the number  
of TSPECs.

Lars

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Sun, 26 Jul 2009 18:00:11 +0200

Hi Lars,

On 26 Jul 2009, at 15:20, Lars Eggert wrote:

> First, the issue isn't that a "misbehaving node" may include a few  
> too many TSPECs in the packet - it's that an actively malicious  
> attacker will cram as many TSPECs into an object as possible, in  
> order to eat control plane cycles and data plane bandwidth.

If you are not protected against malicious RSVP attackers, there are  
lots of very bad things you have to worry about (probably more  
worrisome than the cramming of many TSPECs in a message). For  
starters, the attacker can simply reserve all remaining bandwidth to  
all destinations. Hence the recommendation to implement neighbor  
authentication, which will protect you against malicious attackers.
So, I am not sure we need to worry too much about bad things that  
might be done maliciously specifically with the multi-Tspec.

Francois

>
> Second, the number of TSPECs is limited in the draft, but the limit  
> is 17 (Section 3.2), which is a nice big amplification factor, esp.  
> set up in the end, but the processing overhead goes up with the  
> number of TSPECs.
>
> Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Jul 2009 00:54:04 +0200

Hi,

> authentication, which will protect you against malicious attackers.

OK, but then you need to require use of RFC2747, which at the moment  
isn't even mentioned in the draft.

Lars

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 26 Jul 2009 18:02:58 -0500

>isn't even mentioned in the draft.

sorry for missing this.

I'll get it in the next rev.

James

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 27 Jul 2009 10:00:25 +0200

James, Lars,

> I'll get it in the next rev.

FYI, after going through similar discussions as part of the AD review  
of draft-ietf-tsvwg-rsvp-l3vpn, we agreed to include the following  
text in the Security Considerations section:

" To ensure the integrity of RSVP, the RSVP Authentication mechanisms  
defined in [RFC2747] and [RFC3097] SHOULD be used. Those protect RSVP  
message integrity hop-by-hop and provide node authentication as well  
as replay protection, thereby protecting against corruption and  
spoofing of RSVP messages."

I suggest you include same or similar text.

BTW, there may be more text from the security considerations of draft- 
ietf-tsvwg-rsvp-l3vpn that may be worth considering.

Francois

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Jul 2009 10:31:22 +0200

Hi,

the text below looks OK, but I really believe this needs to be a MUST  
here, because of the additional attack angle.

Lars

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Jul 2009 03:57:37 -0500

>I suggest you include same or similar text.

this is good, I will -- thanks Francois

>BTW, there may be more text from the security considerations of 
>draft- ietf-tsvwg-rsvp-l3vpn that may be worth considering.
>
>Francois
>
>
>>
>>James
>>
>>
>>>Lars

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Jul 2009 03:58:24 -0500

>here, because of the additional attack angle.

I can easily upgrade this to a MUST.