Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

"FIGURELLE, TERRY F" <tf2934@att.com> Thu, 07 June 2018 20:27 UTC

Return-Path: <tf2934@att.com>
X-Original-To: 5gangip@ietfa.amsl.com
Delivered-To: 5gangip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76376129385 for <5gangip@ietfa.amsl.com>; Thu, 7 Jun 2018 13:27:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.61
X-Spam-Level:
X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ZPNS5qc8m0PF for <5gangip@ietfa.amsl.com>; Thu, 7 Jun 2018 13:27:36 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 1F79D126F72 for <5gangip@ietf.org>; Thu, 7 Jun 2018 13:27:36 -0700 (PDT)
Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w57KQSb4008994; Thu, 7 Jun 2018 16:27:33 -0400
Received: from flpd657.enaf.ffdc.sbc.com (sbcsmtp9.sbc.com [144.160.128.153]) by m0083689.ppops.net-00191d01. with ESMTP id 2jfbevrh9h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Jun 2018 16:27:32 -0400
Received: from enaf.ffdc.sbc.com (localhost [127.0.0.1]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w57KRVUH092765; Thu, 7 Jun 2018 13:27:31 -0700
Received: from zlp25942.vci.att.com (zlp25942.vci.att.com [135.213.94.170]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id w57KRP9O092627; Thu, 7 Jun 2018 13:27:26 -0700
Received: from zlp25942.vci.att.com (zlp25942.vci.att.com [127.0.0.1]) by zlp25942.vci.att.com (Service) with ESMTP id E743B4013620; Thu, 7 Jun 2018 20:27:25 +0000 (GMT)
Received: from CAFRFD1MSGHUBAG.ITServices.sbc.com (unknown [130.4.169.164]) by zlp25942.vci.att.com (Service) with ESMTPS id C1E854013621; Thu, 7 Jun 2018 20:27:25 +0000 (GMT)
Received: from CAFRFD1MSGUSRJI.ITServices.sbc.com ([169.254.8.176]) by CAFRFD1MSGHUBAG.ITServices.sbc.com ([130.4.169.164]) with mapi id 14.03.0399.000; Thu, 7 Jun 2018 13:27:25 -0700
From: "FIGURELLE, TERRY F" <tf2934@att.com>
To: Luigi Iannone <ggx@gigix.net>
CC: Saleem Bhatti <saleem@st-andrews.ac.uk>, 5GANGIP <5gangip@ietf.org>
Thread-Topic: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt
Thread-Index: AQHT9DfHwkPUzrWJV0ytbWZFi+Hn6qRF3DQAgAD/4oCADPpHkIABRvUAgAAqIJA=
Date: Thu, 07 Jun 2018 20:27:25 +0000
Message-ID: <1AFE10CF28AE8B4C9663445736B8034D3826B3AA@CAFRFD1MSGUSRJI.ITServices.sbc.com>
References: <CAC8QAcfuk6e+JPuKC4sw=FPYSgO3Tkr5mjSRJeOzvjxUSc9xFw@mail.gmail.com> <B300114A-8838-4FE2-8FA9-95BA4CD07089@st-andrews.ac.uk> <C42C02FB-4452-4D4F-A826-F24D401BB76D@gigix.net> <1AFE10CF28AE8B4C9663445736B8034D3826A13C@CAFRFD1MSGUSRJI.ITServices.sbc.com> <F5E27567-7D26-4C10-9327-AF7A6FA3712B@gigix.net>
In-Reply-To: <F5E27567-7D26-4C10-9327-AF7A6FA3712B@gigix.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.10.54.7]
Content-Type: multipart/alternative; boundary="_000_1AFE10CF28AE8B4C9663445736B8034D3826B3AACAFRFD1MSGUSRJI_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-07_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1805220000 definitions=main-1806070216
Archived-At: <https://mailarchive.ietf.org/arch/msg/5gangip/PcEjBFGy_h7Z2P8iB9Uk_bUEiz4>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt
X-BeenThere: 5gangip@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Discussion of implications of the upcoming 5th Generation \(fixed and\) Mobile communication systems on IP protocols." <5gangip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/5gangip>, <mailto:5gangip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/5gangip/>
List-Post: <mailto:5gangip@ietf.org>
List-Help: <mailto:5gangip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/5gangip>, <mailto:5gangip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2018 20:27:42 -0000

Security that leverages/enforces GTP:

Many operators have GTP aware firewalls that track GTP-C and operate on GTP-C and GTP-U. They can detect and drop spoof packets, not allow access to EPC from unknown elements. Do IE filtering, translation or insertion to deal with 3GPP release deltas (often used with IPX). They may have IPS too (we do) for both GTP networks and APN/APN-IPX DNS. We have a specific APN DNS implementation towards IPX with several protection systems.

Most mobile operators have an isolated “Gn/S5 network” and an IPX DMZ approach for “Gp/S8”. Thus an inside and outside view of encapsulated mobility traffic. A lot can depend on their trust domains and how they handle or get transport. Many drop S1-U straight onto their “Gn/S5 network” and once you remove encapsulation the “security experts” come out of the woodwork to complain about stuff.

We still refer to our inside network as Gn-VRF but its really an MPLS VPN over our common backbone (CBB) network. I would assume we’d create another MPLS VPN just for mapped traffic and add interworking functions to go from backhaul to MMT•-VRF (Mobility Mapped Traffic)• and to EPC/5G-core elements. Normally we’d drop traffic straight onto CBB Internet after UPF/PGW-U for consumer general purpose APN but if there is mapping on this side too then I need to think about that towards services.

Just kidding around with the trade marks 😊

I or somebody else (I am retiring) would need to do a lot of work to duplicated functionality for our end-to-end CoS/QoS treatment. We currently can mark inside and outside GTP packet uniquely for treatment on transport, EPC, CBB and to/from services. We do have trust relationships with service partners and can honor ingress markings but also support other methods for managing service flows. We do support dedicated bearers and they can make before use.

We do a lot with roaming restrictions for both inbound and outbound roaming and we do learn roaming network capabilities.

We also use IPsec VPN for any untrusted backhaul.

From: Luigi Iannone <ggx@gigix.net>
Sent: Thursday, June 07, 2018 3:14 AM
To: FIGURELLE, TERRY F <tf2934@att.com>
Cc: Saleem Bhatti <saleem@st-andrews.ac.uk>; 5GANGIP <5gangip@ietf.org>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt




On 6 Jun 2018, at 23:58, FIGURELLE, TERRY F <tf2934@att.com<mailto:tf2934@att.com>> wrote:

Switches may be impact and any layer2 element is impacted if they are optimized for GTP. Why? Because at layer2 hashing across multiple fibers is sensitive to traffic. With GTP they use  TEID to get good hashing over fibers in a bundle. This is typically just configuration and mostly we use switch/router instead of pure switch. We had same challenges with load balancers and firewalls but all now scale and hash for GTP.

Said another way, mobile operators have been supporting GTP for a very long time. Over that time it is likely some optimizations were leveraged to improve layer2 systems in the paths for  traffic.

How complex are those optimisations? Cannot be adapted to any other encapsulation solution (usually is just a hash….)



They also likely have security solution for GTP traffic too.

Security is a broad term, can you be more specific?

Ciao

L;




So those gaps need to be closed.

From: 5gangip <5gangip-bounces@ietf.org<mailto:5gangip-bounces@ietf.org>> On Behalf Of Luigi Iannone
Sent: Tuesday, May 29, 2018 1:33 AM
To: Saleem Bhatti <saleem@st-andrews.ac.uk<mailto:saleem@st-andrews.ac.uk>>
Cc: 5GANGIP <5gangip@ietf.org<mailto:5gangip@ietf.org>>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

Hi,




On 28 May 2018, at 19:16, Saleem Bhatti <saleem@st-andrews.ac.uk<mailto:saleem@st-andrews.ac.uk>> wrote:

There is some text which is incorrect - on page 4:

----
   Furthermore, ILNP demands a change in the way local (e.g., within a
   LAN) communication is carried out, needing all of the devices to
   support ILNP.  This in turn may raise heavy deployability issues.
----

This is not true - "all devices" do *not* need to be updated, but only those end-systems that wish to use ILNPv6. Switches

Switches clearly do not need to be changed since they are L2.



and routers

You need to implement the ILCC in your first hop router.

Then you need new ICMP messages, and few other tricks here and there in existing stuff.
Other solutions are more clear because introduce new entities and protocol, so either you have it or you don’t.

Yet, may be the last sentence can be soften deleting  “heavy”.

Ciao

L.




do not need to be updated, as ILNPv6 is backwards compatible with IPv6. It is possible to run an ILNPv6 node in a LAN which also has non-ILNPv6 nodes.

Cheers,
--/Saleem




On 25 May 2018, at 15:50, Behcet Sarikaya <sarikaya2012@gmail.com<mailto:sarikaya2012@gmail.com>> wrote:

Hi all,

We have submitted the gaps draft. Those who have contributed text are listed as co-authors.
Please send your comments to the list.

Regards,
Dirk& Behcet

A new version of I-D, draft-xyzy-atick-gaps-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-xyzy-atick-gaps
Revision:       00
Title:          Gap and Solution Space Analysis for End to End Privacy Enabled Mapping System
Document date:  2018-05-25
Group:          Individual Submission
Pages:          10
URL:            https://www.ietf.org/internet-drafts/draft-xyzy-atick-gaps-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dxyzy-2Datick-2Dgaps-2D00.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=JHCjCG90b48mXx2Mli_4FNx3qy80mb6fi-Kr4Z2dAu8&e=>
Status:         https://datatracker.ietf.org/doc/draft-xyzy-atick-gaps/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dxyzy-2Datick-2Dgaps_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=t5QGiu_jAW_cH1P0JkFVW2ESNVahK7obQU0waTiM2wY&e=>
Htmlized:       https://tools.ietf.org/html/draft-xyzy-atick-gaps-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dxyzy-2Datick-2Dgaps-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=5znCd2jz7p4APVeDGBdJR8QIV90W9mTYFft0Ud_kLrg&e=>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xyzy-atick-gaps<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dxyzy-2Datick-2Dgaps&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=CLW3JOJZwQYB-apye4JxkAsH1Kl-Z5_IPqaj31fsX4I&e=>


Abstract:
   This document presents a gap and solution analysis for end-to-end
   privacy enabled mapping systems.  Each of the identifier locator
   separation system has its own approach to mapping identifiers to the
   locators.  We analyse all these approaches and identify the gaps in
   each of them and do a solution space analysis in an attempt to
   identify a mapping system that can be end to end privacy enabled.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=pnlPaw7b14RkC63Q6o1vR1d9DPP7T-GkJxgti99nE6E&e=>.

The IETF Secretariat

_______________________________________________
5gangip mailing list
5gangip@ietf.org<mailto:5gangip@ietf.org>
https://www.ietf.org/mailman/listinfo/5gangip<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=XBUCO8KnEDmfXcxVrQBRrbx98CQRqJmRkKwwYbOpVqg&e=>

_______________________________________________
5gangip mailing list
5gangip@ietf.org<mailto:5gangip@ietf.org>
https://www.ietf.org/mailman/listinfo/5gangip<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwQFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=J5-PU3DJmZhSj-6OvHFxPeu4aAW27BIBzAhnulGrcdI&s=XBUCO8KnEDmfXcxVrQBRrbx98CQRqJmRkKwwYbOpVqg&e=>