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

> -----Original Message-----
> From: behave-bounces@ietf.org 
> [mailto:behave-bounces@ietf.org] On Behalf Of Hadriel Kaplan
> Sent: Friday, April 25, 2008 6:57 PM
> To: Dan Wing; 'Tom Taylor'; 'IETFAVT WG'; behave@ietf.org
> Cc: 'MARJOU Xavier RD-MAPS-LAN'
> Subject: Re: [BEHAVE] [AVT] Working GroupLastCall: 
> draft-ietf-avt-app-rtp-keepalive-03.txt
> 
> 
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:dwing@cisco.com]
> >
> > >         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.
> 
> 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...)

> > 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.
> 
> 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.

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

> > > 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.
> 
> 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

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt