Re: [rtcweb] UDP transport problem

cowwoc <cowwoc@bbs.darktech.org> Fri, 14 February 2014 16:46 UTC

Return-Path: <cowwoc@bbs.darktech.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056AB1A02A3 for <rtcweb@ietfa.amsl.com>; Fri, 14 Feb 2014 08:46:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hB_qkyxPwO7F for <rtcweb@ietfa.amsl.com>; Fri, 14 Feb 2014 08:46:28 -0800 (PST)
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id CF6F31A02FA for <rtcweb@ietf.org>; Fri, 14 Feb 2014 08:46:22 -0800 (PST)
Received: by mail-ob0-f174.google.com with SMTP id uy5so14156625obc.19 for <rtcweb@ietf.org>; Fri, 14 Feb 2014 08:46:21 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=NQpTb+rGbpQwCnrlra6zAjwCShdMQgjqeN3KSL2Kj1Y=; b=hFPvoYJMCNpDkS5V6htKO2bRgF5RvxcURIQ/R3Pc5o0V0zMmXE24JDYobv2fRIvzid z30lqY94skwfVbndYQUIHy5iGgwem1ORUeXBMFafywko2Sab6wBhtZ95xXZ7cO5UPMJR M82qHIQl3XUDas44W9zmmN2BxQJy+0I7HKOK+zGawj7FiZ5bM0QYsamgBUxNti+3OoId +ZaS8StZL4Ib7PHgycyH1M+89PiRyY66EuydIuZlwNCl9WhO5I19ob5SBHOklQGELc2K E0HbHygOxuZuwaYQVCzhfMnDQQnc/cy/SGnhb8pmR2ZBuQwWxrDS7kZvN+51JOkATUUq FRig==
X-Gm-Message-State: ALoCoQlii6uJ5oyX6+06FcdGPBOUnqZwt8t2o3ipYNJbs7M/4oiYiJ6Zx3IriAlp374hx0OGpO2W
X-Received: by 10.182.33.102 with SMTP id q6mr7383862obi.8.1392396381164; Fri, 14 Feb 2014 08:46:21 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id tr10sm17569420obb.6.2014.02.14.08.46.19 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 08:46:20 -0800 (PST)
Message-ID: <52FE4851.3000206@bbs.darktech.org>
Date: Fri, 14 Feb 2014 11:46:09 -0500
From: cowwoc <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CAD6AjGRiQ1UF5n3JG9HPRQFM+TD54Xz-dpTn5u9bX+__BMfesQ@mail.gmail.com> <52FDEE06.1030003@jesup.org> <CAD6AjGRSVHTK7apQ1x3j0pE=dkeFeXBKc0U3z4GkCTywVvckTA@mail.gmail.com>
In-Reply-To: <CAD6AjGRSVHTK7apQ1x3j0pE=dkeFeXBKc0U3z4GkCTywVvckTA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000709040700070400090005"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/9fHjhsJA5CuoIJPf6QREHzsv60k
Subject: Re: [rtcweb] UDP transport problem
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 16:46:31 -0000

On 14/02/2014 9:42 AM, Cb B wrote:
> Right. The source port will be a function of the amp server such as 
> 53, 123, 19... all very common. The destination port is of the 
> spoofers choosing.
>
> But, as the us-cert advisory notes, there are several impacted 
> appilication ports. Well-known webrtc fixed ports would help for a 
> white list.
>
> Creating a blacklist of just 53, 123, 19 makes us still behind the 
> curve on whatever is next.
>

Which is why we will never be able to stop DDoS attacks:

 1. With dumb firewall rules that rely upon port numbers alone.
 2. Unless the destination address is able to communicate back to the
    source (or as close as possible to the source) that it does not wish
    to continue receiving (any) packets from it, and in so doing pushes
    the problem back as far as possible to the source.

Gili