Re: [BEHAVE] [AVT] Working Group LastCall: draft-ietf-avt-app-rtp-keepalive-03.txt

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Hadriel Kaplan
> Sent: Friday, April 25, 2008 1:01 PM
> To: Tom Taylor; IETF AVT WG; [e-mail]
> Cc: Cullen Jennings; MARJOU Xavier RD-MAPS-LAN
> Subject: Re: [AVT] Working Group LastCall: 
> draft-ietf-avt-app-rtp-keepalive-03.txt
> 
> 
> 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."

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

_______________________________________________
Behave mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/behave