Subject: Re: [MMUSIC] Concerns about draft-alexander-congestion-status-preconditions-00 [DDOS]

From: "Corey Alexander" <[email-masked]>
Date: Mon, 01 Aug 2005 16:31:18 -0500

James M. Polk wrote:
> - how this can be used as a DDOS from two otherwise trustworthy UAs in a 
> network or in between networks;

UAs utilizing this approach must be authenticated, authorized, and 
trusted.  A UA should only be listening for probe packets to the 
specific port number(s) associated with the session media being admitted 
prior to receiving an answer, so the window for a DDOS attack to a 
specific UA should be minimal.  Worst case, it is no worse than a DDOS 
attack utilizing other RTP formats to a specific UA.

-- 
Corey W. Alexander

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

---

From: "Corey Alexander" <[email-masked]>
Date: Mon, 01 Aug 2005 16:30:27 -0500

James,

Thank you for the concerns, comments and questions.  There were numerous 
comments during the session that we've noted and are considering, so 
please be aware that the answers being provided are in the context of 
the current version of the draft.

James M. Polk wrote:
> - how long does the RTP Probe "stay up", taking otherwise valuable 
> bandwidth (no advice given)

We did not want to address the details of the probe mechanism this in 
this draft, but unfortunately, neither this nor any of the three related 
drafts currently give a definitive answer to this question.  I'll 
address it here, at least providing our current line of thought in the 
context of your question.

First, as to valuable bandwidth - we agree that bandwidth is valuable,
hence development of an admission control approach - the probe packets 
are currently defined to be 44 bytes.  While they certainly take up 
bandwidth at this minimal size, it is much less than if they were to 
mimic the attributes of the preferred media for a session.  The probe 
packets may mimic attributes of specific codecs, but for the very reason 
described - bandwidth is valuable - this is not the preferred approach.

As to how long to probe, the probe flow need only be generated long 
enough to determine whether congestion is present along the network 
path.  In the context of draft-babiarz-tsvwg-rtecn-04.txt, this would 
require a minimum of four probe packets that, if generated at 20ms 
intervals, equates to a delay of 80ms in each direction.  Once the 
congestion level is determined based on these four probe packets, 
probing may be terminated, and the precondition either passed or failed.

That said, implementations may choose to keep the probe flow up after 
precondition success, until either (a) the dialog is answered, in which 
case the probe flow would be terminated prior to starting media flow, or 
(b) the dialog is terminated, for whatever reason.  [This is the context 
of the the 503 Final Response comment you provide, which I'll address 
separately.]  The reason an implementation may want to continue probing 
after preconditions are met would be to avoid over-subscription, should 
congestion occur after precondition success but before answer.

Responses to your other concerns will follow in individual messages.

Thanks again,
Corey

-- 
Corey W. Alexander

---

From: "Corey Alexander" <[email-masked]>
Date: Mon, 01 Aug 2005 16:32:36 -0500

James M. Polk wrote:
> - how this can work at all when RTP packets take potentially different 
> routes between source and destination (dual-homing anyone?), therefore a 
> false sense of accomplishment will be likely in larger and larger networks;

First, although this is not the focus of this question, I would like to 
make it clear that the probe packets will be generated with the same 
parameters (destination IP/port, source IP/port, and DSCP) as the 
associated media whose admission status is being determined.  Hence, the 
probe packets are handled and routed the same as their associated media 
packets within the network.

It is accepted that once sent, the application no longer has control of 
how and where the individual packets are routed.  However, if some of 
the packets do take different paths than others, the underlying 
Real-time ECN method still works.  Some of the packets may indicate 
congestion along a different path through the network than that taken by 
others that do not indicate congestion.  So regardless of whether the 
packets take a single route or multiple routes through the network, 
there will still be an indication of congestion when the packets arrive.

-- 
Corey W. Alexander

---

From: "Corey Alexander" <[email-masked]>
Date: Mon, 01 Aug 2005 16:34:54 -0500

James M. Polk wrote:
> - I don't understand why the M line codecs are listed (0, 4, 18) when 
> the a=des line codec (104 in their examples) is used for probing; I 
> might not be up on RTP probing to understand this one yet;

This is an area that will likely change.  Our intention was to tie the 
precondition directly to the use of our probing mechanism.  In doing so, 
we deemed that we could omit having an explicit a=rtpmap line for our 
probe format, hence the specification of the payload-type value for the 
probe on the a=des line.  But we thought it okay to include the M= and 
a= line data for the valid media codecs.  One reason for this was in 
case an implementation wished for the packets in the probe stream to 
take on more attributes of the session media then just address/port and 
DSCP values, e.g., packet sizes.

We acknowledge that this was confusing; the approach of tying the 
precondition directly with the probing mechanism - versus specifying the 
probe format in an a=rtpmap line - is being re-considered after your 
comments and the feedback received today in the WG, as is the suggestion 
made this afternoon that we re-use the 'qos' precondition defined in RFC 
3312.  All of this will have an impact on this particular concern.

-- 
Corey W. Alexander

---

From: "Corey Alexander" <[email-masked]>
Date: Mon, 01 Aug 2005 16:37:37 -0500

James M. Polk wrote:
> - I don't like the 503 Response use when it isn't a problem with any SIP 
> element that caused the error condition;

We certainly are not tied to any specific response for the scenario this 
is meant to address.  There was an historic reason why we had selected 
the 503 response here, but I believe it no longer applies.  Perhaps a 
better choice is a 488 (Not Acceptable Here) response with an 
appropriate warning code, say 370 (Insufficient Bandwidth).

-- 
Corey W. Alexander