Re: [Apn] why it is necessary to differentiate the security concern for 5G Vertical Networks from the grand Internet ( was RE: Application-Aware Networking (APN) focused interim

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 11 June 2021 16:53 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A293A1071; Fri, 11 Jun 2021 09:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.5
X-Spam-Level: **
X-Spam-Status: No, score=2.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 0txkTQjsyrQd; Fri, 11 Jun 2021 09:53:18 -0700 (PDT)
Received: from relay.sandelman.ca (minerva.sandelman.ca [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7A33A106F; Fri, 11 Jun 2021 09:53:17 -0700 (PDT)
Received: from dooku.sandelman.ca (cpe788a207f397a-cmbc4dfb96bb50.sdns.net.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id A185C1F47B; Fri, 11 Jun 2021 16:53:12 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 152451A02D3; Fri, 11 Jun 2021 12:53:11 -0400 (EDT)
Received: from dooku (localhost [127.0.0.1]) by dooku.sandelman.ca (Postfix) with ESMTP id 136491A00D8; Fri, 11 Jun 2021 12:53:11 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "rtgwg\@ietf.org" <rtgwg@ietf.org>, "apn\@ietf.org" <apn@ietf.org>
In-reply-to: <CO1PR13MB49209D61044189A1CD10EEFAA9389@CO1PR13MB4920.namprd13.prod.outlook.com>
References: <PH0PR13MB4922A88EFE55FA2398651301A9239@PH0PR13MB4922.namprd13.prod.outlook.com> <c78e1bae-042b-e0bb-be4a-c2223d039b11@sandelman.ca> <PH0PR13MB4922EF9BAC0CCC4BB8CC38E6A93B9@PH0PR13MB4922.namprd13.prod.outlook.com> <13268.1622832941@localhost> <PH0PR13MB4922C32FD7938D6C6391C98FA93B9@PH0PR13MB4922.namprd13.prod.outlook.com> <362.1622914856@localhost> <CO1PR13MB49209D61044189A1CD10EEFAA9389@CO1PR13MB4920.namprd13.prod.outlook.com>
Comments: In-reply-to Linda Dunbar <ldunbar@futurewei.com> message dated "Mon, 07 Jun 2021 14:56:15 -0000."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Fri, 11 Jun 2021 12:53:11 -0400
Message-ID: <112022.1623430391@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/AdvapAgHw3OhfvNR6azQbCwN-NU>
Subject: Re: [Apn] why it is necessary to differentiate the security concern for 5G Vertical Networks from the grand Internet ( was RE: Application-Aware Networking (APN) focused interim
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jun 2021 16:53:22 -0000

Linda Dunbar <ldunbar@futurewei.com> wrote:
    > Closed Loop Networks still have nodes from different vendors, like UPFs
    > can be from vendor A and B, routers connecting the edge servers to UPFs
    > can be from Vendor X/Y/Z.  Therefore, Closed Loop Networks still need
    > standardization. E.g. IETF DETNET is used for closed loop networks.

I never argued that there shouldn't be standardization.
I'd sure like you to go far beyond where you are proposing.
I'm asking for something more specific in the requirements.

    > If using RSVP+Diffserv, extension is needed to represent finer grade of
    > services. I assume that APN is meant to address those extensions.  The
    > draft-peng-apn-scope-gap-analysis has more detailed analysis.

}   Application-aware Networking (APN) is introduced in
}   [I-D.li-apn-framework] and [I-D.li-apn-problem-statement-usecases].
}   APN conveys an attribute along with data packets into network and
}   make the network aware of fine-grain user group-level and application
}   group-level requirements.

how is the "user" or "application" identified by the classifier, if end
stations are not involved?  Destination address can sometimes identify the
application, but it can't identify the user.

But the document says that the CPE is going to look at 5-tuple:
}5.  Basic Solution and Benefits
}
}   With APN, at the edge node, i.e. CPE, of the SD-WAN (see Figure 2),
}   the 5-tuple, plus information related to user or application group-
}   level requirements is constructed into a structured value, called as
}   APN attribute.

section 6.1 explains why you can't use flow-label, but a stack of MPLS labels
seems to work just fine, and it's got many more bits than DSCP.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [