Subject: [BEHAVE] Working Group Last Call: draft-ietf-avt-app-rtp-keepalive-03.txt

From: Tom Taylor <[email-masked]>
Date: Wed, 23 Apr 2008 14:55:37 -0400

This is to announce Working Group Last Call for 
draft-ietf-avt-app-rtp-keepalive-03.txt. Assuming all goes well, the Last Call 
period will end on May 7.

Given the subject matter, the BEHAVE list is also copied on this message.

Tom Taylor for the Chairs.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 25 Apr 2008 10:03:07 +0300

Le Wednesday 23 April 2008 21:55:37 ext Tom Taylor, vous avez écrit :
> draft-ietf-avt-app-rtp-keepalive-03.txt. Assuming all goes well, the Last
> Call period will end on May 7.

I am fine with the document (especially, the conclusion). However, if I want 
to split hairs, I would argue that the 0-bytes packet stuff is slightly 
incorrect.

Namely, sending 0 bytes packet works for any RTP-capable transport protocol. 
Indeed, it works not only for UDP and DCCP, but also for UDP-Lite and 
RTP-framing-in-TCP. I would hence argue that is _not_ specific to 
UDP/DCCP/whatever, contrary to the claims thereto in the document.

-- 
Rémi Denis-Courmont

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 25 Apr 2008 16:00:55 -0400

Howdy,
In general I like the draft - it's short and to the point. :)
I have the following comments:

1) The recommended "fallback" mechanism of using an RTP packet with an unknown payload format has issues.  I *know* there are devices which can't handle it.  I know this because SBC's have been specifically requested by operators to block such packets, because they were causing issues for some RTP devices.  We can argue that RFC 3550 said a receiver MUST ignore such packets, but there is a big difference between handling error cases, and *testing* for such compliance by using it actively for a "feature".  For example on some devices it causes error logs to be generated. (on others, worse)

I recognize that this is probably unavoidable for any mechanism we pick, because the requirements are that it not be negotiated in SDP (right?).  But I think it warrants certain changes in the text of the draft, which I note here:
        a) Section 4.7 Recommendation section currently implies this is the recommendation, but that's not really true.  It should say "This method is recommended as a fallback, only if explicitly signaled methods such as [DRAFT-RTP-RTCP] or STUN through [DRAFT-ICE] are not possible."
        b) Section 5, page 8, last sentence should be changed from "...as it will always work." to "...as it will usually work."
        c) Security section 8 is wrong - it *does* imply security issues, clearly.  So I recommend you add "Using the mechanism in Section 4.7 could be perceived as an attack by the peer.  [RFC3550] explicitly stated devices MUST ignore unknown payload formats, however security devices may block such packets."  Or something like that I guess.

2) In some ways, the recommended fallback of RTP with an unknown payload type is simply the draft-ietf-avt-rtp-no-op packet, just without SDP negotiation, and no 4-byte payload - right?  One of the things I liked about that draft was it negotiated it in SDP. :)  I realize you're trying to not make that necessary, so can we at least give this a fixed defined payload type number??  I think giving up one of the few left (are there any?) is worth it for this, because we're not negotiating it in SDP.

3) I also still think there should be optional SDP for the empty RTP keeaplive, just so that "evil" middleboxes trying to protect devices can know they can let these things past.  I realize that can't be done in a BCP, so I think draft-ietf-avt-rtp-no-op-04 should *become* the empty RTP keepalive, and define the SDP. (I'm not sure why it expired)

4) This is basically a nit: like Remi, I'm not quite clear why Sections 4.1 and 4.2 UDP and DCCP transports are separate from each other or others, for zero-byte "packets".  With TCP, obviously a 0-byte segment is not exactly the same as a TCP keepalive, and for SCTP it has a native heartbeat, so maybe those differences explain it. (and I'm not sure how one forces a TCP stack to send a 0 byte segment from above the socket)  But as far as I know, all of them can handle receiving a 0-byte payload.  A nit, anyway.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom
> Taylor
> Sent: Wednesday, April 23, 2008 2:56 PM
> To: IETF AVT WG; [email-masked]
> Cc: Cullen Jennings; MARJOU Xavier RD-MAPS-LAN
> Subject: [AVT] Working Group Last Call: draft-ietf-avt-app-rtp-keepalive-
> 03.txt
>
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 25 Apr 2008 18:22:04 -0700

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hadriel Kaplan
> Sent: Friday, April 25, 2008 1:01 PM
> To: Tom Taylor; IETF AVT WG; [email-masked]
> Subject: Re: [AVT] Working Group LastCall: 
> draft-ietf-avt-app-rtp-keepalive-03.txt
> 
> 
> Howdy,
> 1) The recommended "fallback" mechanism of using an RTP 
> packet with an unknown payload format has issues.  I *know* 
> there are devices which can't handle it.  I know this because 
> SBC's have been specifically requested by operators to block 
> such packets, because they were causing issues for some RTP 
> devices.  We can argue that RFC 3550 said a receiver MUST 
> ignore such packets, but there is a big difference between 
> handling error cases, and *testing* for such compliance by 
> using it actively for a "feature".  For example on some 
> devices it causes error logs to be generated. (on others, worse)
> 
> I recognize that this is probably unavoidable for any 
> mechanism we pick, because the requirements are that it not 
> be negotiated in SDP (right?).  But I think it warrants 
> certain changes in the text of the draft, which I note here:
>         a) Section 4.7 Recommendation section currently 
> implies this is the recommendation, but that's not really 
> true.  It should say "This method is recommended as a 
> fallback, only if explicitly signaled methods such as 
> [DRAFT-RTP-RTCP] or STUN through [DRAFT-ICE] are not possible."
>         b) Section 5, page 8, last sentence should be changed 
> from "...as it will always work." to "...as it will usually work."

This draft is all about mechanisms to keep NAT mapping alive,
which is what this draft means by "work".  And sending a packet
will keep that binding alive -- always.

I do agree the existing wording is a bit awkward.  I would 
suggest:

  ... as it will always keep the NAT's mapping alive, but
  may cause undesirable behavior on the remote peer.

>         c) Security section 8 is wrong - it *does* imply 
> security issues, clearly.  So I recommend you add "Using the 
> mechanism in Section 4.7 could be perceived as an attack by 
> the peer.  [RFC3550] explicitly stated devices MUST ignore 
> unknown payload formats, however security devices may block 
> such packets."  Or something like that I guess.

I agree some text should be added to address you point, but
(going back to my point above that this draft describes how
to keep your NAT mapping alive), we don't care if a device
on the remote network drops the packet; the packet will have
already traversed our NAT and kept our NAT's mapping alive.

> 2) In some ways, the recommended fallback of RTP with an 
> unknown payload type is simply the draft-ietf-avt-rtp-no-op 
> packet, just without SDP negotiation, and no 4-byte payload - 
> right?  One of the things I liked about that draft was it 
> negotiated it in SDP. :)  I realize you're trying to not make 
> that necessary, so can we at least give this a fixed defined 
> payload type number??  I think giving up one of the few left 
> (are there any?) is worth it for this, because we're not 
> negotiating it in SDP.

I recall we asked for a fixed payload number for no-op a few
years ago, but were told 'no'.  Maybe that has changed; I
do think it would be useful for this situation, but it only
reduces the risk of a no-op packet being mis-identified as
some sort of attack packet.

> 3) I also still think there should be optional SDP for the 
> empty RTP keeaplive, just so that "evil" middleboxes trying 
> to protect devices can know they can let these things past.  
>
> I realize that can't be done in a BCP, so I think 
> draft-ietf-avt-rtp-no-op-04 should *become* the empty RTP 
> keepalive, and define the SDP. (I'm not sure why it expired)

Nobody seemed to need it.

-d

> 4) This is basically a nit: like Remi, I'm not quite clear 
> why Sections 4.1 and 4.2 UDP and DCCP transports are separate 
> from each other or others, for zero-byte "packets".  With 
> TCP, obviously a 0-byte segment is not exactly the same as a 
> TCP keepalive, and for SCTP it has a native heartbeat, so 
> maybe those differences explain it. (and I'm not sure how one 
> forces a TCP stack to send a 0 byte segment from above the 
> socket)  But as far as I know, all of them can handle 
> receiving a 0-byte payload.  A nit, anyway.
> 
> -hadriel
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 25 Apr 2008 21:57:10 -0400

> From: Dan Wing [mailto:[email-masked]]
>

Yup, I realize it achieves that goal, and *I* don't care if a SBC-type-thing blocks and discard the packet either, because it achieves that goal - but that doesn't mean it has no security implications if it goes direct, and this is a WG doc after all. :)

> some sort of attack packet.

It would do more than that.  It would let monitoring software (wireshark/whatever) identify it as a keepalive.  It may let QoS monitoring devices ignore it more easily.  It would let middleboxes detect it as a keepalive, instead of attack packets.  It would let DSP's have a way to off-load discarding of it.  It would let SRTP bump-in-the-wire chips or shims avoid calculating auth for it, on both generation and reception. (because auth won't matter)

If SDP negotiated it, that's possible too - but for this mechanism I think a defined number makes sense, especially if we don't want to use SDP.

> Nobody seemed to need it.

I find it odd that a WG BCP would recommend a mechanism (albeit a fallback one), that is not itself defined in a standards track doc anywhere.  Maybe it's just me though. :)

-hadriel

---

From: Colin Perkins <[email-masked]>
Date: Sat, 26 Apr 2008 15:35:11 +0100

On 26 Apr 2008, at 02:57, Hadriel Kaplan wrote:
...
> It would do more than that.  It would let monitoring software  
> (wireshark/whatever) identify it as a keepalive.  It may let QoS  
> monitoring devices ignore it more easily.  It would let middleboxes  
> detect it as a keepalive, instead of attack packets.  It would let  
> DSP's have a way to off-load discarding of it.  It would let SRTP  
> bump-in-the-wire chips or shims avoid calculating auth for it, on  
> both generation and reception. (because auth won't matter)
>
> If SDP negotiated it, that's possible too - but for this mechanism  
> I think a defined number makes sense, especially if we don't want  
> to use SDP.

Static payload types were deprecated over a decade ago. Negotiating a  
no-op payload type in SDP makes sense, but I really don't want to  
revisit static assignments.

> I find it odd that a WG BCP would recommend a mechanism (albeit a  
> fallback one), that is not itself defined in a standards track doc  
> anywhere.  Maybe it's just me though. :)

There were also concerns about having IPR on a no-op format, if I  
remember correctly. https://datatracker.ietf.org/ipr/854/

-- 
Colin Perkins
http://csperkins.org/

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 26 Apr 2008 12:11:43 -0400

> From: Colin Perkins [mailto:[email-masked]]
>

Yeah, I knew you'd say that. :)
I'd be happy if there were at least some SDP indication.  Even if the sender ignores the lack of it in received SDP and sends empty RTP anyway, it would be useful to have it indicate support for it and its PT in the SDP it sends.

> remember correctly. https://datatracker.ietf.org/ipr/854/

I thought that was Cisco's classic defensive patent statement, which other IETF RFC's have been OK with.  And I'm suggesting a different form of no-op: an empty one.  Regardless, if an empty RTP is covered by that IPR, then so is this keepalive draft, no?

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 26 Apr 2008 09:17:08 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: Friday, April 25, 2008 6:57 PM
> To: Dan Wing; 'Tom Taylor'; 'IETFAVT WG'; [email-masked]
> Cc: 'MARJOU Xavier RD-MAPS-LAN'
> Subject: Re: [BEHAVE] [AVT] Working GroupLastCall: 
> Yup, I realize it achieves that goal, and *I* don't care if a 
> SBC-type-thing blocks and discard the packet either, because 
> it achieves that goal - but that doesn't mean it has no 
> security implications if it goes direct, and this is a WG doc 
> after all. :)

I don't know how the IETF could say something like "sending a bogus
packet to a device might cause it to crash, due to a bug".  I mean,
nearly every implementation of every protocol has bugs in it, and
negotiating a payload type via SDP does _not_ cause the bugs to
go away -- some well-formed, legal RTP packet could still tickle a 
bug in an implementation.  RTP options, for example; or RTP options
combined with IP options (but, hey, everyone blocks IP options 
because those have all been found to be implemented too poorly...)

> (wireshark/whatever) identify it as a keepalive.  It may let 
> QoS monitoring devices ignore it more easily.  It would let 
> middleboxes detect it as a keepalive, instead of attack 
> packets.  It would let DSP's have a way to off-load 
> discarding of it.  It would let SRTP bump-in-the-wire chips 
> or shims avoid calculating auth for it, on both generation 
> and reception. (because auth won't matter)
> 
> If SDP negotiated it, that's possible too - but for this 
> mechanism I think a defined number makes sense, especially if 
> we don't want to use SDP.

All great reasons, in my opinion.  Perhaps this can be re-visited.

> I find it odd that a WG BCP would recommend a mechanism 
> (albeit a fallback one), that is not itself defined in a 
> standards track doc anywhere.  Maybe it's just me though. :)

I agree that sending an RTP payload type that was not negotiated 
in SDP is hard to justify in this document; afterall, you're Not 
Supposed To Need To Do That.  But, pragmatically, you need to send 
*something*, or else the call will get torn down by the NAT.  I am
all for additional pragmatism.

-d

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 26 Apr 2008 13:05:59 -0400

> because those have all been found to be implemented too poorly...)

Absolutely agree - and I'm not suggesting that "crash/bug" wording, nor that this means we shouldn't use this mechanism. :)  For pragmatic reasons I agree with (and condone) sending the empty RTP.  I think it will be very popular (though I prefer RTCP muxing, but that appears to be a higher bar for folks).
I just think the security section shouldn't claim it has "no" implications.

My argument is:
(a) we have a defined mechanism for announcing dynamic payload types in SDP.
(b) devices use that mechanism to indicate what they expect to receive.
(c) we're ignoring that standardized announcement SDP mechanism and sending something they didn't indicate they expect to receive.
Therefore (d) bad things may happen, due to the mechanism we're choosing.

This isn't analogous to "legal RTP packets could still tickle bugs".  That analogy breaks down because they're *legal* RTP packets conforming to the SDP mechanism we have in place for announcing them, and so on.

This new mechanism is more analogous (although not identical) to the debate SIP WG had about sending STUN messages in the SIP port without any prior negotiation of support.  Some argued legacy SIP servers should ignore it because it didn't conform to SIP ABNF and 3261 said to ignore it, and that if they didn't they were just poor designs.  But that was not the issue in debate.  We all agreed that was true.  But the real issue that finally convinced people (I think) was that legacy SIP security devices would blacklist UA's sending the STUN, *because* it wasn't legal SIP.

> All great reasons, in my opinion.  Perhaps this can be re-visited.

My spidey sense tells me we won't get a static payload for it.  So I'd be happy with SDP indication.

> all for additional pragmatism.

Me too.  So I think a wholesome-and-pragmatic way to do this is simply revive rtp-no-op, redefine it as the empty RTP packet, with a defined SDP, and WGLC it quickly.  Then this BCP can point to that draft, and say "one could send rtp-no-op even if the peer does not indicate support for it in SDP, but one should still include its indication in the SDP".  I don't think that's very hard to accomplish.

-hadriel

---

From: Colin Perkins <[email-masked]>
Date: Sun, 27 Apr 2008 15:27:17 +0100

On 26 Apr 2008, at 17:11, Hadriel Kaplan wrote:
> I'd be happy if there were at least some SDP indication.  Even if  
> the sender ignores the lack of it in received SDP and sends empty  
> RTP anyway, it would be useful to have it indicate support for it  
> and its PT in the SDP it sends.

Sure, I have no argument with that.

> I thought that was Cisco's classic defensive patent statement,  
> which other IETF RFC's have been OK with.  And I'm suggesting a  
> different form of no-op: an empty one.  Regardless, if an empty RTP  
> is covered by that IPR, then so is this keepalive draft, no?

Possibly - you'd have to ask Cisco.

-- 
Colin Perkins
http://csperkins.org/

---

From: Stephen Casner <[email-masked]>
Date: Sun, 27 Apr 2008 10:16:33 -0700 (PDT)

> Sure, I have no argument with that.

I'd be willing to have my arm twisted for defining a static PT because
I could be convinced that this is a special case.  However, it seems
to me that it would not help the backwards compatibility problem at
all.  Old receivers that were unprepared for it, or that implemented
strict conformance requirements, would still have a problem.  It seems
that the SDP negotiation at least lets a new sender know that an old
receiver might fail.

                                                         -- Steve