Re: [Spud] No. Operators don't need SPUD for mobile network management

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 21 July 2016 15:27 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A04F12D0B4 for <spud@ietfa.amsl.com>; Thu, 21 Jul 2016 08:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.588
X-Spam-Level:
X-Spam-Status: No, score=-5.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 N1EQET7jtFHx for <spud@ietfa.amsl.com>; Thu, 21 Jul 2016 08:27:43 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBFB12D76C for <spud@ietf.org>; Thu, 21 Jul 2016 08:27:22 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7439EA2; Thu, 21 Jul 2016 17:27:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1469114840; bh=TOAM5ikHEVCOLOwvKmI0hlWwhIwUgjeqN190CdrWPLE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=L+/sePCnIxUALzQZw8N3OOQPdDuWkrYwKHEtBgluCDsWgGP4R4g5h/STIoWwpJIF3 Qf0NJK9Quvs4HMtON1wGFnGVbRkgR6UB9IRzE0EykeWh99yDnLSv4IhNSAr7orVFXk 5ybl2TI+PfJXlK/K1EulKpZ95B5aYWpu69zrciCk=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6B212A1; Thu, 21 Jul 2016 17:27:20 +0200 (CEST)
Date: Thu, 21 Jul 2016 17:27:20 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: "Eggert, Lars" <lars@netapp.com>
In-Reply-To: <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com>
Message-ID: <alpine.DEB.2.02.1607211724010.2309@uplift.swm.pp.se>
References: <43a39476-9327-87ef-204c-d7c614a80669@tele.no> <alpine.DEB.2.02.1607211643150.2309@uplift.swm.pp.se> <0f504f66-1df8-e2da-b55a-3e44e67d0912@tele.no> <alpine.DEB.2.02.1607211712500.2309@uplift.swm.pp.se> <3F114FAB-6F70-4908-939C-1DA5661B2113@netapp.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/fRMvJ_pmec1BrXSjF-mvigM0RpI>
Cc: Frode Kileng <frodek@tele.no>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Spud] No. Operators don't need SPUD for mobile network management
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jul 2016 15:27:46 -0000

On Thu, 21 Jul 2016, Eggert, Lars wrote:

> Why is the first packet arriving at a middlebox for which it has no 
> binding not treated as such a "connection establishment packet"? Why 
> does a bit need to be set for it to be treated as such?

Because you still want to allow incoming connections to the customers from 
the Internet.

If there are no flags, I can't differentiate an incoming new connection 
Internet->UE (that I want to allow), from a backscatter packet (that I 
want to drop).

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se