Re: [BEHAVE] [AVT] Working GroupLastCall: draft-ietf-avt-app-rtp-keepalive-03.txt
"Dan Wing" <dwing@cisco.com> Sat, 26 April 2008 16:17 UTC
Return-Path: <behave-bounces@ietf.org>
X-Original-To: behave-archive@optimus.ietf.org
Delivered-To: ietfarch-behave-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F22A28C19D; Sat, 26 Apr 2008 09:17:08 -0700 (PDT)
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0383A3A6B9E; Sat, 26 Apr 2008 09:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id at4KBQwRTOhW; Sat, 26 Apr 2008 09:17:04 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C9F853A6A31; Sat, 26 Apr 2008 09:17:04 -0700 (PDT)
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Apr 2008 09:17:09 -0700
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3QGH9Ah013382; Sat, 26 Apr 2008 09:17:09 -0700
Received: from dwingwxp01 ([10.32.240.194]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m3QGH8nO022743; Sat, 26 Apr 2008 16:17:08 GMT
From: Dan Wing <dwing@cisco.com>
To: 'Hadriel Kaplan' <HKaplan@acmepacket.com>, 'Tom Taylor' <tom.taylor@rogers.com>, 'IETFAVT WG' <avt@ietf.org>, behave@ietf.org
References: <480F8629.8080202@rogers.com><E6C2E8958BA59A4FB960963D475F7AC30BD05E899F@mail.acmepacket.com><097c01c8a73b$efe6f9a0$c2f0200a@cisco.com> <E6C2E8958BA59A4FB960963D475F7AC30BD05E8BAB@mail.acmepacket.com>
Date: Sat, 26 Apr 2008 09:17:08 -0700
Message-ID: <0b0f01c8a7b8$fa1e2600$c2f0200a@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC30BD05E8BAB@mail.acmepacket.com>
Thread-Index: Acilc5CY4IIjoR3jTRKh0H3OXBO5CQBkyupwAA0KnAAAAKSo4AADwIZg
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3945; t=1209226629; x=1210090629; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20<dwing@cisco.com> |Subject:=20RE=3A=20[BEHAVE]=20[AVT]=20Working=20GroupLastC all=3A=09draft-ietf-avt-app-rtp-keepalive-03.txt |Sender:=20; bh=5l6S4pDsAH7Mxog1woB+VRFCG2BcTEuZ8PZe/xTl9Dg=; b=CaquVVMOX6PGEcS5CNcLpnd1TMltJdqLv6xZ/3kXKJFASj8AfTO4te473E 6tU3Ac2QeY3VeNCLglBhrmfKL3L2LbctgNGtTLGQpv6sCyJFb6QGYIbfSYcA tNiW2PSLVO;
Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
Cc: 'MARJOU Xavier RD-MAPS-LAN' <xavier.marjou@orange-ftgroup.com>
Subject: Re: [BEHAVE] [AVT] Working GroupLastCall: draft-ietf-avt-app-rtp-keepalive-03.txt
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: behave-bounces@ietf.org
Errors-To: behave-bounces@ietf.org
> -----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 _______________________________________________ Behave mailing list Behave@ietf.org https://www.ietf.org/mailman/listinfo/behave
- [BEHAVE] Working Group Last Call: draft-ietf-avt-… Tom Taylor
- Re: [BEHAVE] Working Group Last Call: draft-ietf-… Rémi Denis-Courmont
- Re: [BEHAVE] [AVT] Working Group Last Call: draft… Hadriel Kaplan
- Re: [BEHAVE] [AVT] Working Group LastCall: draft-… Dan Wing
- Re: [BEHAVE] [AVT] Working Group LastCall: draft-… Hadriel Kaplan
- Re: [BEHAVE] [AVT] Working Group LastCall: draft-… Colin Perkins
- Re: [BEHAVE] [AVT] Working Group LastCall: draft-… Hadriel Kaplan
- Re: [BEHAVE] [AVT] Working GroupLastCall: draft-i… Dan Wing
- Re: [BEHAVE] [AVT] Working GroupLastCall: draft-i… Hadriel Kaplan
- Re: [BEHAVE] [AVT] Working Group LastCall: draft-… Colin Perkins
- Re: [BEHAVE] [AVT] Working Group LastCall: draft-… Stephen Casner
- Re: [BEHAVE] [AVT] Working Group LastCall: draft-… Xavier Marjou
- Re: [BEHAVE] [AVT] Working Group LastCall: draft-… Dan Wing