Subject: Re: [5gangip] 16 Nov 2017, 5gangip meeting, IETF100, ILNP slides

From: Erik Kline <[email-masked]>
Date: Mon, 4 Dec 2017 19:11:26 +0900

I dearly hope we're not talking about giving mobile devices a single
IPv6 address (or a single NID).

On 17 November 2017 at 00:07, Ca By <[email-masked]> wrote:
>
> On Thu, Nov 16, 2017 at 12:11 AM Saleem Bhatti <[email-masked]>
> wrote:
>>
>>
>> slides for today's meeting:
>>
>>
>> https://www.dropbox.com/s/uh9sl7ctvo5raln/20171116_ilnp_5gangip_singapore-x.pdf?dl=0
>>
>> Cheers,
>> --/Saleem
>>
>
>
> These results look very promising !
>
> CB
>>
>>
>> _______________________________________________
>> 5gangip mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/5gangip
>
>
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Dec 2017 09:35:05 -0800

Why would that be such a bad thing? Using ID/Locator separation it is rather encouraged. But with ILNP and ILA putting locators in addresses to make them multi-homed means you may need multiple addresses. I think less is better.

Dino

> On Dec 4, 2017, at 2:11 AM, Erik Kline <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 4 Dec 2017 09:52:11 -0800

> Why would that be such a bad thing? Using ID/Locator separation it is rather encouraged. But with ILNP and ILA putting locators in addresses to make them multi-homed means you may need multiple add…
For ILA we will support both prefix assignment as well as singleton
addresses. Singleton addresses does not necessarily mean single
addresses, in fact hosts may be assigned millions of such addresses.
The value of doing that is to provide much strong privacy guarantees.
For instance, single use addresses, that is each connection gets a
unique source address, mitigates cross connection correlations based
on addresses as well specific geo location inference (assuming that on
the network prefix of the provider is the only fixed and predictable
part of the address).

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Dec 2017 09:58:59 -0800

> addresses, in fact hosts may be assigned millions of such addresses.

If you are saying that an ILA node has one ID and that the locator part can change and be used for the same TCP connection, for example, that would be a good thing.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Mon, 4 Dec 2017 10:11:22 -0800

> If you are saying that an ILA node has one ID and that the locator part can change and be used for the same TCP connection, for example, that would be a good thing.
Dino,

No, an ILA node can have millions of indentifiers assigned to it. An
identifier identifies a node, but that does no imply a 1-1
correspondence between nodes and identifiers. This no different than a
multihomed host can already have multiple addreses assigned to it. All
the indentifiers of a physical node would normally share the same
locator.

The control plane does need a way to efficiently manage addresses. For
instance, if a device moves then all of its identifiers need to be
assigned the new locator. That we would want to be in one operation so
the control plane of the local network maintains identifier groups to
associate identifiers that have some share properties (like assigned
to the same UE).

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 4 Dec 2017 10:26:15 -0800

> identifier identifies a node, but that does no imply a 1-1

Right, I understand that. But I wanted to keep the number of addresses down so I think an ILA node that has a single ID is a huge feature. It will help debugging greatly.

> the indentifiers of a physical node would normally share the same

I am asking if there can be a many-to-1 relationship between different locators to the SAME ID.

> assigned the new locator. That we would want to be in one operation so

I think that is an architectural bug. The whole point of an ID is that it stays constant and is agnostic to moves.

> associate identifiers that have some share properties (like assigned

So let me ask again with an example if ILA can do this (same question to Saleem):

(1) A UE is assigned one ID (with the single SIR-prefix).
(2) The UE is multi-homed to two different provider networks. Therefore there is an opportunity for multiple locators.
(3) Can a TCP connection to one or more remote IDs have packets sent from the UE with different locators at the same time for the same or different TCP connection?

Dino

---

From: Tom Herbert <[email-masked]>
Date: Mon, 4 Dec 2017 13:48:54 -0800

> Right, I understand that. But I wanted to keep the number of addresses down so I think an ILA node that has a single ID is a huge feature. It will help debugging greatly.

There's no requirment to use more than one identifier or address. In
fact, in the datacenter use case we are assigning each task it's own
IP. But, in public mobile networks trying to force a single /128
address seems like a non starter at this point. Being esay to debug,
would also mean being easy to break privacy and security :-)

> I am asking if there can be a many-to-1 relationship between different locators to the SAME ID

Each identifier maps to at least one locator. In the multihomed
scenario suggested below two networks could map an identifier to
different locators, where the locator is relative to the location of
the node relative to the perspective network.

> I think that is an architectural bug. The whole point of an ID is that it stays constant and is agnostic to moves.
The identifier is constant. The transport and application only see the
SIR address which is a globally visible representation of an
identifier. When an identifier moves, the locator it maps to moves.
This is exactly the same principle in virtual networking: a node is
identified by virtual address but the underlay delivers packets a a
physical address for the virtual address. If the VM is migrated, the
physical address can change but virtual address is unafected.

> (2) The UE is multi-homed to two different provider networks. Therefore there is an opportunity for multiple locators.

If the identifier space is shared between provider networks then each
can have its own locator mapping for the identifier.

> (3) Can a TCP connection to one or more remote IDs have packets sent from the UE with different locators at the same time for the same or different TCP connection?

Yes, locators are only relevant in destination addresses. Each remote
identifier would be separately mapped to a corresponding locator.

Tom

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 4 Dec 2017 23:11:52 +0000

Erik and Dino;

> On 04 Dec 2017, at 17:35, Dino Farinacci <[email-masked]> wrote:
> 

ILNP supports multiple simultaneous NIDs.

Being able to control the value of the Locator(s) in the packet from the end system has some advantages also, e.g. an ILNP node can then exercise some control over multihoming/multipath connectivity by use of different Locator values. This allows, for example, network (IP) layer soft handover (amongst other things), e.g. you could do an IP-layer soft-handover moving between, say, an 802.11 cell and 5G, or across to another sub-network technology which may or may not support a soft-handover. Of course, it will probably be possible to engineer such a soft-handover (or multipath) solution for any 2 (or any N) technologies. I have a personal preference for an end-to-end approach, both for the control-plane and the user/data-plane.

As others have already noted in various emails, a purely end-to-end approach may not be desirable for either the user/data-plane and/or the control-plane, for various reasons.

There have been some arguments for an incremental approach, which I can sympathise with for the reasons given by their respective proponents: something that is too radically different is likely to be too disruptive for interworking with existing systems, which is an important requirement.

So far, the messages on the list make good arguments for various approaches from different perspectives. Perhaps if there was a list of prioritised requirements, that would help to work out where the lines can be drawn. I have to say that I do not know what all the requirements are for the scenario being considered, let alone what the priorities might be.

Cheers,
--/Saleem

---

From: Tom Herbert <[email-masked]>
Date: Mon, 4 Dec 2017 16:52:07 -0800

> So far, the messages on the list make good arguments for various approaches from different perspectives. Perhaps if there was a list of prioritised requirements, that would help to work out where t…
Saleem,

One of the concerns I have with making this an end-to-end solution is
that it could expose locators to end users and other third parties.
Locators might reveal fairly accurate geo location of UEs (down to a
microcell for instance) in which case they become sensitive privacy
information. I have hypothesized the "stalker exploit" to hightlight
the dangers of this.

Tom

---

From: sothy shan <[email-masked]>
Date: Tue, 5 Dec 2017 08:46:02 +0100

Hello All,

On Tue, Dec 5, 2017 at 12:11 AM, Saleem Bhatti <[email-masked]>
wrote:

> > Why would that be such a bad thing? Using ID/Locator separation it is
> rather encouraged. But with ILNP and ILA putting locators in addresses to
> make them multi-homed means you may need multiple addresses. I think less
> is better.
> >
> > Dino
> >
> Being able to control the value of the Locator(s) in the packet from the
> end system has some advantages also, e.g. an ILNP node can then exercise
> some control over multihoming/multipath connectivity by use of different
> Locator values. This allows, for example, network (IP) layer soft handover
> (amongst other things), e.g. you could do an IP-layer soft-handover moving
> between, say, an 802.11 cell and 5G, or across to another sub-network
> technology which may or may not support a soft-handover. Of course, it will
> probably be possible to engineer such a soft-handover (or multipath)
> solution for any 2 (or any N) technologies. I have a personal preference
> for an end-to-end approach, both for the control-plane and the
> user/data-plane.
>
> As others have already noted in various emails, a purely end-to-end
> approach may not be desirable for either the user/data-plane and/or the
> control-plane, for various reasons.
>
> There have been some arguments for an incremental approach, which I can
> sympathise with for the reasons given by their respective proponents:
> something that is too radically different is likely to be too disruptive
> for interworking with existing systems, which is an important requirement.
>
> So far, the messages on the list make good arguments for various
> approaches from different perspectives. Perhaps if there was a list of
> prioritised requirements, that would help to work out where the lines can
> be drawn. I have to say that I do not know what all the requirements are
> for the scenario being considered, let alone what the priorities might be.
>

I like the statement. We need to create a  requirement document!!!!

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 5 Dec 2017 17:24:14 +0900

Assigning a limited number of /128s is a bad thing for the reasons listed
in RFC 7934.

On Tue, Dec 5, 2017 at 2:35 AM, Dino Farinacci <[email-masked]> wrote:

> >> On Thu, Nov 16, 2017 at 12:11 AM Saleem Bhatti <[email-masked]
> >
> >> wrote:
> >>>
> >>>

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 5 Dec 2017 09:27:00 +0000

Tom;

> On 05 Dec 2017, at 00:52, Tom Herbert <[email-masked]> wrote:
> 

I agree that (topological and/or geographical) location privacy is important to support. The exposure of location should not be a problem with ILNP.

The IP-level stalker needs to be perturbed by having both identity privacy and location privacy.

As the ILNP Locator is not part of the end-to-end state, localised Locator values could be used by the end-system (UE) initially [1], which have no topological significance. The localised Locator can be re-written on the fly for location privacy [2] (or even for some form of traffic engineering, e.g. herding flows to specific egress points [3]).

If something more elaborate is required, then a mechanism that is akin to (but not equivalent to) a Tor-like scenario is also possible for ILNP [4].

For [2], [3], and [4], the underlying mechanism requires some state to be present on the network path. Minimally, a Locator look-up table would be required, and (selected) on-path routers would need to re-write Locator values in the IP-level packet header only. However, checksums would not need to be recomputed, as ILNP Locators are not end-to-end state, and so ILNP does not include the Locator in the TCP pseudo-header. No tunnelling is required.

In support of location privacy, ILNP also supports identity privacy with the use of "private" or "ephemeral" Identifier values [5], and would certainly be compatible with Identifier values generated ala RFC8064/RFC7217.

In summary, identity privacy and location privacy can be used together in ILNP, whilst maintaining end-to-end integrity in the user/data-plane, but would not be purely end-to-end in the control plane, allowing operators a flexible level of control, without tunnelling.

Cheers,
--/Saleem

[1] Section 2 of RFC6748.
[2] Section 7 of RFC6748.
[3] Section 5 of RFC6748.
[4] Section III.C of MILCOM 2011 paper, https://goo.gl/kqmT42 or http://dx.doi.org/10.1109/MILCOM.2011.6127596
[5] Section 3.1 of RFC6741.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 5 Dec 2017 05:50:21 -0800

> can have its own locator mapping for the identifier.

Okay, and if it is not, roaming with session survivablility is limited.

> identifier would be separately mapped to a corresponding locator.

Well I would think they would be relevant for source addresses because providers still may want to use uRPF rules to avoid locator spoofing.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 5 Dec 2017 05:55:35 -0800

> Assigning a limited number of /128s is a bad thing for the reasons listed in RFC 7934.

Does that mean assigning one is better or assigning too many (subjective reference) is a bad thing?

To me, it sounds like you can’t get any simpler by having a single device have a single ID. And the fact it can map to multiple locators is a capability happening at the lower layers below the transport layer.

Dino

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 5 Dec 2017 15:07:31 +0100

> (subjective reference) is a bad thing?

The way I understand it, is that it is bad to assign one or two
addresses to an end node, but it is much better to assign a higher
number of addresses, only limited by a huge number, and ideally to
delegate prefixes of length that is less 64 (this prefix thing is me
adding to the phrase, he did not say it).

I can understand that requirement very well.

But I cant understand how to fit that requirement in the id-loc paradigm.

 From what I read, it seems to me that id-loc introduces one or two
translators between two ends.  If so, then the requirement would be to
make sure that an unlimited number1 of identifiers and locators are
glued to end1, a similarly unlimited number2 to end2, and to each
translator.

Alex

> 
> To me, it sounds like you can’t get any simpler by having a single
> device have a single ID. And the fact it can map to multiple locators
> is a capability happening at the lower layers below the transport
> layer.
> 
> Dino
> 
>> On Tue, Dec 5, 2017 at 2:35 AM, Dino Farinacci
>> <[email-masked]> wrote: Why would that be such a bad thing?
>> Using ID/Locator separation it is rather encouraged. But with ILNP
>> and ILA putting locators in addresses to make them multi-homed
>> means you may need multiple addresses. I think less is better.
>> 
>> Dino
>> 
>>> I dearly hope we're not talking about giving mobile devices a
>>> single IPv6 address (or a single NID).
>>> 
>>>> On Thu, Nov 16, 2017 at 12:11 AM Saleem Bhatti
>>>> <[email-masked]> wrote:
>>>>> 
>>>>> 
Cheers,
>>>>> _______________________________________________ 5gangip
>>>>> mailing list [email-masked] 
>>>> _______________________________________________ 5gangip mailing
>>>> list [email-masked] 
>>> _______________________________________________ 5gangip mailing
>>> list [email-masked] 
>> _______________________________________________ 5gangip mailing
>> list [email-masked] 
> _______________________________________________ 5gangip mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 5 Dec 2017 06:25:37 -0800

> On Dec 5, 2017, at 6:07 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

With LISP, the host can select by itself a long random number as a ephemeral-EID. Or it can be provisioned with a crypto-EID (associated with a key-pair). And a sub-layer in the network layer worries about assigning locators to those EIDs. 

Dino

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 5 Dec 2017 14:43:36 +0000

Alex;

Different id-loc schemes work in different ways.

In ILNP, there are no translators required between Identifier values and Locator values.

Cheers,
--/Saleem

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 5 Dec 2017 15:55:22 +0100

Le 05/12/2017 à 15:43, Saleem Bhatti a écrit :
> Alex;
> 
>> On 05 Dec 2017, at 14:07, Alexandre Petrescu 
>> <[email-masked] <mailto:[email-masked]>> 
>> wrote:
>>

So, in ILNP: make sure an unlimited number (or a number whose limit is 
very high) of Identifier values and of Locator values are glued on each 
end node.  For example, do not glue only one id on an end node and, 
similarly, do not glue only one locator on an end node.

Alex

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 5 Dec 2017 07:21:45 -0800

Ditto for LISP.

Dino

> On Dec 5, 2017, at 6:43 AM, Saleem Bhatti <[email-masked]> wrote:
> 
> Alex;
> 
>> On 05 Dec 2017, at 14:07, Alexandre Petrescu <[email-masked]> wrote:
>>

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 5 Dec 2017 15:08:38 +0000

Alex;

> On 05 Dec 2017, at 14:55, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
>>> On 05 Dec 2017, at 14:07, Alexandre Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> So, in ILNP: make sure an unlimited number (or a number whose limit is very high) of Identifier values and of Locator values are glued on each end node.  For example, do not glue only one id on an end node and, similarly, do not glue only one locator on an end node.

For ILNPv6 node IDs (NIDs), generation of NID values follows the same schemes as is possible for IPv6 (RFC6741, Section 2).

For ILNPv6 Locator (L64) values, the value is an IPv6 routing prefix. This could be a localised prefix (RFC6748, Section 2), or a global prefix (RFC6741, Section 3).

To answer your question directly, there are not unlimited values for NIDs or L64s.

However, you can have as many as you need, subject to the same constraints of IPv6, as above.

Cheers,
--/Saleem

---

From: Tom Herbert <[email-masked]>
Date: Tue, 5 Dec 2017 08:57:54 -0800

Saleem,

Intermediate devices often attempt to verify TCP/UDP checksum in
packets (for instance in checksum offload or LRO), and also a locator
in a destination address icould be corrupted in flight so that
misdelivery to the wrong host could entail.  So we really want the
transport layer checksum to be valid in the packet at all times. ILA
uses checksum neutral mapping (idea borrowed from RFC6296) to
accomplish this. Any transport checksum is always valid, no DPI is
required to fix checksums in L4 headers, and no change to transport
layer implementation is needed. If a locator is corrupted and packet
is misdirected then the packet will be dropped at the wrong receiver
when the transport checksum fails.

Tom

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 5 Dec 2017 17:42:56 +0000

Tom;

> On 05 Dec 2017, at 16:57, Tom Herbert <[email-masked]> wrote:
> 

That is a fair point.

Indeed, the existing TCP checksum code does not work for ILNPv6 packets. The fix is relatively straight forward (excluding the Locator by zeroing the top 64 bits of the IPv6 address fields before evaluating the checksum), but that is not deployed in existing code.

However, let me offer some discussion points ;-)

Firstly, I do not know how much on-path/non-end-system TCP checksumming is performed. So, I do not know how big a problem it is that you highlight. It would be interesting to find out - does anyone know, or have any pointers?

Secondly, if there is an error in the Locator value for an ILNPv6 packet, then, modulo any on-path checksum validation (my first point above), the situation is no worse than for an error in the IPv6 prefix for an IPv6 packet. Again, I do not know what the scale of such a problem would be, and so how much it would matter in reality.

Thirdly, the offloading issue: this is a very interesting point. It is not clear to me how much offload processing is used currently, or what its longevity is. If you have a chance, have a look at the two articles below:

---- Windows ----

1) Why Are We Deprecating Network Performance Features (KB4014193)? (Microsoft TechNet, 13 June 2017)
   https://blogs.technet.microsoft.com/askpfeplat/2017/06/13/why-are-we-deprecating-network-performance-features-kb4014193/

The bottom line is that Windows is deprecating offload processing, with the availability of security patches being at least one of the concerns, e.g. timeliness of security patches for NIC firmware.

---- Linux ----

2) "This page describes the reasons why Linux engineers currently feel that full network stack offload (TCP Offload Engine, TOE) has little merit." (The Linux Foundation, 19 July 2016)
https://wiki.linuxfoundation.org/networking/toe

Some similar issues flagged for Linux, in terms of offload processing of TCP, including, security issues, but also issues of code maintenance. Indeed, as well as security, the Linux-specific page has an interesting point on performance, which is probably the main reason for using offload processing:

  "Each TOE NIC has a limited lifetime of usefulness, because system hardware rapidly catches up to TOE performance levels, and eventually exceeds TOE performance levels. We saw this with 10mbit TOE, 100mbit TOE, gigabit TOE, and soon with 10gig TOE."

----

Of course, I have deliberately picked two specific articles to support my point, but, for balance, I would be interested to know how much TCP offload processing (including TSO/GSO in Linux) is actually used, and what the trend is for its continued use going forward. If anyone has such information, that would be very interesting.

Cheers,
--/Saleem

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 5 Dec 2017 17:45:32 +0000

May be a unrelated question ..

In ILA where is the mapping table, id-2-loc (Aka HoA-CoA) maintained; it
is not clear how that state get distributed through out the network, or
how the look up happens. Can the authors point me to that text or some
slides?

Sri

On 12/5/17, 7:21 AM, "5gangip on behalf of Dino Farinacci"
<[email-masked] on behalf of [email-masked]> wrote:

>>><[email-masked]> wrote:
>>>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 5 Dec 2017 10:39:55 -0800

> Firstly, I do not know how much on-path/non-end-system TCP checksumming is performed. So, I do not know how big a problem it is that you highlight. It would be interesting to find out - does anyone…
Extremely common when you consider NIC checksum offload. Other on-path
TCP checksum verification is not ordinarily done in datapath, however
could be done as part of debugging when packets are being captured.

> Secondly, if there is an error in the Locator value for an ILNPv6 packet, then, modulo any on-path checksum validation (my first point above), the situation is no worse than for an error in the IPv…
Since IPv6 does not contain a header checksum, the pseudo header
checksum in the packet is the only mechanism defined in IP to detect
corruption in the addresses. This is what the checksum is required in
UDPv6.

> Thirdly, the offloading issue: this is a very interesting point. It is not clear to me how much offload processing is used currently, or what its longevity is. If you have a chance, have a look at…
TOE is not relevant. Specifically stateless offloads like checksum
offload, LRO, and GRO are relevant. Checksum offload is ubquitous in
that it supported by probably every NIC now. There are RX two
variants: one which parses the packets and returns an indication that
the checksum is validated, and one that returnes the ones complement
checksum. The former breaks if the checksum is incorrect in the
on-the-wrire packet. For TX, there is also a protocol generic method
as well as a protocol specific one so the situation is analogous.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 5 Dec 2017 10:53:47 -0800

> how the look up happens. Can the authors point me to that text or some
Sri,

See attached slides. Slide 6 shows general topology, 7 datacenter
virtualization, 8 mobility network. The general topology is the same
in these use cases, the roles and names are different. I believe that
locator addresses would be the equivalent of CoA and a SIR address is
equivalent of a HoA (although SIR addresses don't need a default
location).

Tom

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 5 Dec 2017 19:03:59 +0000

Thanks Tom; I will review the slides.

Sri

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 5 Dec 2017 11:38:12 -0800

If ILNP used ILA’s checksum workaround, would the protocols be essentially the same? Would ILNP benefit from ILA and ILA could benefit from ILNP’s Redirect message?

Dino

> On Dec 5, 2017, at 9:42 AM, Saleem Bhatti <[email-masked]> wrote:
> 
> Tom;
>

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 5 Dec 2017 20:18:54 +0000

Dino;

> On 05 Dec 2017, at 19:38, Dino Farinacci <[email-masked]> wrote:
> 

Sort answer: No.

It is possible that the RFC6296 trick that is used by Tom for ILA could be applied to an ILNPv6 NID value, to take account of the combined L64 and NID. However, when the L64 changes for an existing session (e.g. due to mobility or multihoming), that would mean changing the NID value, which would break end-to-end state invariance.

Cheers,
--/Saleem

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 5 Dec 2017 20:12:06 +0000

Tom;

Anywhere that the TCP checksum is evaluated, that code will have to be updated for evaluating the correct checksum for ILNPv6 packets.

Cheers,
--/Saleem

> On 05 Dec 2017, at 18:39, Tom Herbert <[email-masked]> wrote:
>

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 5 Dec 2017 21:21:50 +0000

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Monday, December 04, 2017 10:11 AM
To: Dino Farinacci <[email-masked]>
Cc: Erik Kline <[email-masked]>; Ca By <[email-masked]>; [email-masked]
Subject: Re: [5gangip] 16 Nov 2017, 5gangip meeting, IETF100, ILNP slides

Dino,

No, an ILA node can have millions of indentifiers assigned to it. An identifier identifies a node, but that does no imply a 1-1 correspondence between nodes and identifiers. This no different than a multihomed host can already have multiple addreses assigned to it. All the indentifiers of a physical node would normally share the same locator.

The control plane does need a way to efficiently manage addresses. For instance, if a device moves then all of its identifiers need to be assigned the new locator. That we would want to be in one operation so the control plane of the local network maintains identifier groups to associate identifiers that have some share properties (like assigned to the same UE).

[Uma]: That's correct and this can be done in 3GPP architecture - where absolute knowledge of UE/subscriber to LOC and many more are and can be tied together.. without anybody complaining privacy issues :)

---

From: Tom Herbert <[email-masked]>
Date: Tue, 5 Dec 2017 14:02:24 -0800

Saleem,

How would an on-path device determine that a packet uses ILNP so that
it can apply ILNP specific TCP/UDP checksum handling?

Tom

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 5 Dec 2017 22:32:37 +0000

Tom;

> On 05 Dec 2017, at 22:02, Tom Herbert <[email-masked]> wrote:
> 

An ILNPv6 packet contains a Nonce header (RFC6744).

Cheers,
--/Saleem

---

From: Tom Herbert <[email-masked]>
Date: Fri, 8 Dec 2017 10:04:49 -0800

Saleem,

You might want to look at how Generic Receive Offload (GRO) will work
with ILNP in LInux. GRO creates jumbo TCP packets from smaller packets
received on a flow in order to improve performance. In order to do
this the TCP checksum must be veried and this is done well before the
actual TCP processing occurs. This is a good software analogue of HW
offload mechanisms and might provide some insights on ILNP/checksum
handling.

Tom

---

From: Saleem Bhatti <[email-masked]>
Date: Sat, 9 Dec 2017 11:58:46 +0000

> On 08 Dec 2017, at 18:04, Tom Herbert <[email-masked]> wrote:
> 

Thanks for the tip, Tom.

Cheers,
--/Saleem

---

From: Erik Kline <[email-masked]>
Date: Fri, 15 Dec 2017 16:26:24 +0900

> information. I have hypothesized the "stalker exploit" to hightlight

I think the only thing we should use to the identifier for is for
forwarding the /64 the carrier has allocated to the UE.  In other
words, the locator can change all it wants and the operator's routing
system maintains a table entry that says "this /64 -> that
identifier".

With this system, the identifier doesn't have to leak outside of the
provider's network, and the control plane can be something other than,
say, ILNP ICMPv6 messages, and the UE gets its prefix(es).

---

From: Saleem Bhatti <[email-masked]>
Date: Fri, 15 Dec 2017 09:51:36 +0000

Erik;

> On 15 Dec 2017, at 07:26, Erik Kline <[email-masked]> wrote:
> 

I have a different model in my head.

The UE gets a /64 from the provider after some other form of service-level authentication as it is might be done today, e.g. IMEI, ICCID, etc. That /64 is its Locator. There should be nothing to stop the UE from getting multiple Locators, perhaps from different providers (e.g. dual SIM handset or some such).

The UE then generates Identifier values as required (e.g. ala RFC8064/RFC7217, or SLAAC if identity privacy is not a concern). The UE can use multiple Identifiers simultaneously if required. The UE binds an Identifier to a Locator value for new communication sessions, i.e. the I-L binding is dynamic, and a UE could use many I-L pairs over time. 

The Identifier value remains stable for any end-to-end sessions, but the Locator value can change as much as it wants.

The ephemeral Identifier value gives identity privacy, without loss of end-to-end session state. The mutable Locator value gives location privacy.

(This is pretty much a summary of what ILNP does.)

Cheers,
--/Saleem

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 15 Dec 2017 11:01:48 -0800

If you used LISP, the entire 128 bits of an IPv6 address is allocated to the UE as a crypto-EID. You can use fd::/8 and get 120 bits for a hash (that does a pretty good job reducing collisions). And then transport checksums do not have to change (or need the ILA checksum mechanism) when deploying ILNP. So you can anonymized host addresses on the RAN and then they can be encrypted and encapsulated over the EPC/Internet.

This is way simpler and there is no dynamic allocation of addresses. You factory install the crypto-EID when key-pairs are created.

If we don’t have simple solutions, 3GPP will make a complexity judgement call on IPv6.

Dino

> On Dec 15, 2017, at 1:51 AM, Saleem Bhatti <[email-masked]> wrote:
> 
> Erik;
>

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 18 Dec 2017 09:26:54 +0000

Dino;

> On 15 Dec 2017, at 19:01, Dino Farinacci <[email-masked]> wrote:
> 

Dynamic generation of I-values, dynamically-learned L-values, and dynamic binding of I-L values by the end-system (e.g. the UE) gives the greatest agility across the I/L namespace for enabling improved privacy, in my view, compared to factory-installed EIDs (as well as allowing more flexible communication). Somewhere, someone will have those original factory-installed EID/I-values, and they are fixed values (I am assuming, if they are factory installed).

Use of cryptographically-verifiable I-values could be useful for validating a sender of a packet (e.g. ala RFC3972 Cryptographically Generated Addresses (CGA)), as you have described above, but that might be counter to identity privacy. ILNP can use any mechanism for generating node Identifier values as IPv6 uses for generating interface ID values, e.g. SLAAC/EUI64 (if privacy is not a concern), or RFC4941 (privacy extensions for SLAAC), or RFC3972 (CGA), or RFC8064/RFC7217, or anything else.

In response to your comparison of ILNP with LISP, in my view:

a) I would argue that a patch to update a checksum computation for ILNP is easier to deploy and less disruptive than installing LISP infrastructure, which would need to include all the state signalling/management for EID-RLOC mappings and tunnel management. The checksum issue has been discussed previously on the list. To be fair, ILNP requires updates to the end-system/UE stack -- including TCP and UDP code (also previously discussed on the list, I believe) -- which includes the checksum update. However, these can be rolled out as regular OTA updates to the end-system/UE.

b) The LISP EID-RLOC mapping points and mapping state (including the tunnel management), increase the attack surface, and the possibility of additional attack vectors, compared to ILNP.

c) In general (i.e. not specifically for LISP), I believe that anywhere you add or introduce additional entities within the network infrastructure for controlling end-to-end flows, you increase the complexity in the network (including increased overhead, e.g. signalling and/or tunnels, management), and increase the attack surface for a population of users (as well as potentially having more centralised points of failure, and potential performance bottlenecks).

If LISP was not being added to the existing stack, but replacing something else in the stack, e.g. perhaps replacing GTP, then perhaps that might be considered more acceptable to those folk who are the gatekeepers for the current stack? (A complete guess on my part.)

I am sure the points above can be debated, especially as LISP and ILNP present a different idea of what I-values and L-values are, and how they are used: LISP and ILNP have different system architectures.

> If we don’t have simple solutions, 3GPP will make a complexity judgement call on IPv6.

I agree that a simple solution is better (for some definition of "simple", e.g. less complexity, less overhead, or some other).

There is already a lot of complexity as others on the list have commented. I would prefer less complexity, but perhaps others would find a little bit more complexity is acceptable, if it enables more/new control functionality.

There is a trade-off, in my view, between control/management functionality for data/user flows that might be introduced into the network, and the potential additional privacy & security attack surface the generates for end-to-end communication.

I agree there will need to be a judgement call made by some body of people. However, I do not have any idea how I might second-guess the "what/why/when" of that judgement call -- the trade-off -- might be.

Cheers,
--/Saleem

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 18 Dec 2017 18:44:55 +0000

[sorry to interject - only a brief comment]

Hi Saleem,

Your analysis is spot-on, especially #a included.

But I would note Tom's earlier excellent comments/analysis (multiple times in this list) on the complexity and expectations on host based solutions for hosts, applications and servers out there. 

I see/heard the perpetuating discussions on 3GPP about this (host or network based solution) on multiple aspects. 

> I agree there will need to be a judgement call made by some body of people. However, I do not have any idea how I might second-guess the "what/why/when" of that judgement call -- the trade-off -- m…

Sure. It's essentially a trade-off and also what's deployed out there too perhaps.

--
Uma C.

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Saleem Bhatti
Sent: Monday, December 18, 2017 1:27 AM
To: Dino Farinacci <[email-masked]>
Cc: Erik Kline <[email-masked]>; Cameron Byrne <[email-masked]>; [email-masked]; Tom Herbert <[email-masked]>
Subject: Re: [5gangip] 16 Nov 2017, 5gangip meeting, IETF100, ILNP slides

Dino;

Cheers,
--/Saleem

>>>> One of the concerns I have with making this an end-to-end solution 
>>>> is that it could expose locators to end users and other third parties.
>>>> Locators might reveal fairly accurate geo location of UEs (down to 
>>>> a microcell for instance) in which case they become sensitive 
>>>> privacy information. I have hypothesized the "stalker exploit" to 
>>>> hightlight the dangers of this.
>>>> 
>>>> Tom
>>> 
>>> words, the locator can change all it wants and the operator's 
>>> routing system maintains a table entry that says "this /64 -> that 
>>> identifier".
>> 
>>> provider's network, and the control plane can be something other 
>>> than, say, ILNP ICMPv6 messages, and the UE gets its prefix(es).
>> 
>> 
>> 
>> 
>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 18 Dec 2017 11:15:19 -0800

> But I would note Tom's earlier excellent comments/analysis (multiple times in this list) on the complexity and expectations on host based solutions for hosts, applications and servers out there.

Yes, a proposal that requires changes to every transport protocol for
every OS for every client and server on the Internet seems to
constitute "boiling the ocean".

It might be worthwhile to take a look at how MP-TCP is unfolding. This
is similar to ILNP in its need to change TCP stack on both clients and
servers, athough MP-TCP only is concerned with only one transport
protocol. With the exception of iOS, MP-TCP hasn't been widely adopted
for a number of reasons. The answer to slowness in adoption is to run
MP-TCP proxies in the network that bring in a whole bunch of
complexity, break E2E, and force single path through the proxy which
is exactly the opposite of what MP-TCP endeavours to do.

Tom

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 18 Dec 2017 19:21:07 +0000

there's a lot of middleboxen out there already that do various things that
may or may not be helpful but aren't pure e2e -
putting mptcp proxies there too is not any more or less bad or good -

some quantification of this is needed - e.g. of a useful study is
http://www1.icsi.berkeley.edu/~narseo/papers/mobi307f-vallinarodriguez.pdf
i'm sure the stats have moved on since then tho...

of course, designing for stateful middleboxen is unpopular in some circles

On Mon, Dec 18, 2017 at 7:15 PM, Tom Herbert <[email-masked]> wrote:

> > But I would note Tom's earlier excellent comments/analysis (multiple
> times in this list) on the complexity and expectations on host based
> solutions for hosts, applications and servers out there.
>

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 18 Dec 2017 19:27:44 +0000

sorry, sent before i mentioned - this paper provides a novel take on
multipath:

*Low-Latency Routing on Mesh-Like Backbones
<https://dl.acm.org/authorize?N41521>*
Nikola Gvozdiev (University College London (UCL)), Stefano Vissicchio
(University College London (UCL)), Brad Karp (University College London
(UCL)), Mark Handley (University College London (UCL))
linked from here:
https://conferences.sigcomm.org/hotnets/2017/program.html

i think it behoves us to think of this since one of the ways we might
actually hit 5g latency targets is to do this sort of thing (as well as
path diversity and multi-everything at radio level too)

---

From: Tom Herbert <[email-masked]>
Date: Mon, 18 Dec 2017 11:33:07 -0800

> putting mptcp proxies there too is not any more or less bad or good -
They clearly break TCP authentication header (RFC5925) among other
things. That is bad.

> of course, designing for stateful middleboxen is unpopular in some circles
That's because stateful middleboxes break E2E, prevent multi-homing,
and tend to ossify transport protocols and features to be only what
middleboxes support.

Stateless and transport protocol agnostics mechanisms like ILA don't
have these issues.

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 18 Dec 2017 19:44:05 +0000

Tom;

> On 18 Dec 2017, at 19:15, Tom Herbert <[email-masked]> wrote:
> 

There are two parts to "boiling the ocean" in this case:

a) getting the mods into the relevant code-bases, e.g. OS kernels, checksum code on NICs etc

b) getting the mods-deployed to the end-system/UE

For a), getting TCP and UDP mods into the code-bases is challenging, in the first instance, as we have discussed previously on the list. I totally accept that, and I am working on that. I am grateful for your comments on those issues in previous emails on this list.

However, once a) is in place, then b) is relatively straight-forward, I would argue.

> for a number of reasons.

My feeling is that MP-TCP has other problems (e.g. security concerns, backwards compatibility concerns), which may also causing deployment/adoption delay.

> The answer to slowness in adoption is to run

That could well apply to MP-TCP, but there is no "ILNP-proxy" plan, so I am not sure how that part of your analogy carries across to ILNP?

Cheers,
--/Saleem

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 18 Dec 2017 19:49:16 +0000

Uma;

> On 18 Dec 2017, at 18:44, Uma Chunduri <[email-masked]> wrote:
> 

Agreed - Tom's points have been well made on the list in previous emails.

> Sure. It's essentially a trade-off and also what's deployed out there too perhaps.

Do you have a feeling for which way this is going, and what the key factors are in considering the trade-off?

Or is that the discussion is in a bit of stalemate, and just waiting for a "compelling solution" proposition to tip the balance?

Cheers,
--/Saleem

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 18 Dec 2017 08:27:36 -0800

> dynamically-learned L-values, and dynamic binding of I-L values by the end-system (e.g. the UE) gives the greatest agility across the I/L namespace for enabling improved privacy, in my view, compared to factory-installed EIDs (as well as allowing more flexible communication). Somewhere, someone will have those original factory-installed EID/I-values, and they are fixed values (I am assuming, if they are factory installed).

As you know an EID can and is a dynamic I-value. So we can have it many ways. 

> Use of cryptographically-verifiable I-values could be useful for validating a sender of a packet (e.g. ala RFC3972 Cryptographically Generated Addresses (CGA)), as you have described above, but that might be counter to identity privacy. ILNP can use any

Not if you rotate addresses. Just like a Bitcoin address of a wallet can be changed for each transaction. We could do the same at the network layer. That is use a different EID for each transport connection opened. 

> mechanism for generating node Identifier values as IPv6 uses for generating interface ID values, e.g. SLAAC/EUI64 (if privacy is not a concern), or RFC4941 (privacy extensions for SLAAC), or RFC3972 (CGA), or RFC8064/RFC7217, or anything else.

Yep correct. But my point was having more bits for the ID. 

> a) I would argue that a patch to update a checksum computation for ILNP is easier to deploy and less disruptive than installing LISP infrastructure, which would need to include all the state signalling/management for EID-RLOC mappings and tunnel

ILNP will have to do the same signaling. 

> management. The checksum issue has been discussed previously on the list. To be fair, ILNP requires updates to the end-system/UE stack -- including TCP and UDP

Right - and I was just staying to require less to change. Changing eNodeBs will be less than changing UEs. You can’t argue with this point. Agree?

> code (also previously discussed on the list, I believe) -- which includes the checksum update. However, these can be rolled out as regular OTA updates to the end-system/UE.
> 

Everything is vulnerable to attacks. Let’s leave it at that. There is no solution that is going to claim it is totally secure. So there really is no point to argue it. More secure isn’t totally secure, period. 

> c) In general (i.e. not specifically for LISP), I believe that anywhere you add or introduce additional entities within the network infrastructure for controlling end-to-end flows, you increase the complexity in the network (including increased overhead, e.g. signalling and/or tunnels, management),

Yes - but there is no such thing as a free lunch. You are adding a lot of features that carriers CAN monetize with LISP. 

How is ILNP (and ILA) going to deliver IPv4 packets and get packets through IPv4 NATs. You will need address-family CGNs to make it work. That is complexity at the data-plane (which is typically more expensive than at control-plane)  added not to mention the attack surface and forwarding bottlenecks that come Ali g with CGNs. 

> and increase the attack surface for a population of users (as well as potentially having more centralised points of failure, and potential performance bottlenecks).
> 

It can do both Saleem. 

> There is already a lot of complexity as others on the list have commented. I would

Complexity in LTE. We need to replace it with the least amount of mechanism for the most benefits we bring at the first shot deployment of such mechanisms. 

> I agree there will need to be a judgement call made by some body of people. However, I do not have any idea how I might second-guess the "what/why/when" of that judgement call -- the trade-off -- m…

Right and it will come down to what is economical. 

Dino

---

From: Tom Herbert <[email-masked]>
Date: Mon, 18 Dec 2017 12:13:42 -0800

Saleem,

That is only true if the change does not require action by the OS to
configure or enable it. For instance, it's pretty straightforward to
get code into Linux kernel. Android will eventually re-base and
upgrade to the latter kernel (2-3 yrs.). If the feature doesn't
require configuration then great, it's just starts to work (there are
countless networking optimizations like this). But if the feature
requires the OS vendor to enable it and/or a new application API is
needed then your at the mercy of Android developers to do it. Maybe
they like your feature maybe they don't. If they do it's at least a
couple more years for them to integrate, test, and deploy...

> That could well apply to MP-TCP, but there is no "ILNP-proxy" plan, so I am not sure how that part of your analogy carries across to ILNP?

How does ILNP work between a UE that supports the protocol and a
server on the Internet that doesn't support it?

Tom

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 18 Dec 2017 20:14:52 +0000

Dino;

> On 18 Dec 2017, at 16:27, Dino Farinacci <[email-masked]> wrote:
> 

Aha ... OK. So, then the question is how many bits are considered enough.

> ILNP will have to do the same signaling. 

No. ILNP does not use tunnels. The signalling is directly between communicating hosts only - no additional state in the network, no new network entities.

> Right - and I was just staying to require less to change. Changing eNodeBs will be less than changing UEs. You can’t argue with this point. Agree?

I agree there will be fewer places that code updates will required. However, the places where the LISP updates need to go are perhaps more critical for an operator than end-systems. As Uma notes in another email, the "host-based" vs "network-based" debate is ongoing! :-)

> Everything is vulnerable to attacks.

Agree.

> Let’s leave it at that. There is no solution that is going to claim it is totally secure. So there really is no point to argue it. More secure isn’t totally secure, period. 

OK, but having an increased attack surface with additional unknowns, especially in the core infrastructure, is another aspect that would need to be considered.

I certainly will not claim that ILNP is totally secure.

> Yes - but there is no such thing as a free lunch. You are adding a lot of features that carriers CAN monetize with LISP. 

I agree. (I agreed with that in different words in my email - that sometimes additional complexity might be considered acceptable because it gains you something.)

> How is ILNP (and ILA) going to deliver IPv4 packets and get packets through IPv4 NATs. You will need address-family CGNs to make it work. That is complexity at the data-plane (which is typically mo…

If native IPv4 (i.e. not tunnelled in IPv6 or ILNPv6) is a strong requirement, then I agree that ILNP's focus on IPv6 would not work. There are ILNP RFCs for ILNPv4 - RFCs 6745/6/7 extending IPv4 for ILNP operation - but the engineering solutions presented have a low possibility of deployment in their current from, in my view.

>> If LISP was not being added to the existing stack, but replacing something else in the stack, e.g. perhaps replacing GTP, then perhaps that might be considered more acceptable to those folk who ar…

OK. :-)

> Right and it will come down to what is economical. 

I agree - that features clearly and consistently amongst the anecdotes I am hearing: one of the high priority requirements for a solution seems to be whatever has the lowest monetary cost for deployment.

Cheers,
--/Saleem

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 18 Dec 2017 14:56:22 -0600

> Aha ... OK. So, then the question is how many bits are considered enough.

More is necessary but never sufficient. :-)

> No. ILNP does not use tunnels. The signalling is directly between communicating hosts only - no additional state in the network, no new network entities.

I didn’t say it does. But signaling of some sort is required to map ID to Locator. 

> I agree there will be fewer places that code updates will required. However, the places where the LISP updates need to go are perhaps more critical for an operator than end-systems. As Uma notes in…

We, as architects, need to evaluate all holistic solutions. If the goal is to affect the cost to the fewest to benefit the more, then you know the tradeoffs between “should it go in the host or the router”. 

I have tried both and have failed (and succeeded) with either. And sometimes both is required. :-)

> I agree. (I agreed with that in different words in my email - that sometimes additional complexity might be considered acceptable because it gains you something.)

Right - understand. 

> If native IPv4 (i.e. not tunnelled in IPv6 or ILNPv6) is a strong requirement, then I

The hosts (UEs and servers) may be originating and consuming IPv4 packets but that wasn’t my point. It’s the infrastructure with middle boxes that are usually IPv4. So it is just natural we have an enormous underlay to deal with. And doing IPv6 native end-to-end may not happen until 6.5G. :-)

But doing IPv6 in the hosts can happen a lot sooner than in the core network (this is evidence of the progress of the last 10-15 years of host OS support AND deployment). 

Dino 

> agree that ILNP's focus on IPv6 would not work. There are ILNP RFCs for ILNPv4 - RFCs 6745/6/7 extending IPv4 for ILNP operation - but the engineering solutions presented have a low possibility of deployment in their current from, in my view.
> 

Dino

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 18 Dec 2017 21:33:47 +0000

Tom;

> On 18 Dec 2017, at 20:13, Tom Herbert <[email-masked]> wrote:
> 
> countless networking optimizations like this).

OK, agreed.

> But if the feature

Yes, I agree that minimising new configuration is important, especially if the configuration would require some manual intervention.

ILNPv6 can work for existing IPv6 binaries without recompiling, unless the program directly use address bits as part of the application control or application state. For example, we have iperf working over IPv6 (the IPv6 binary without recompiling), as iperf can use names. However, for example, apache web server would probably not work straight out of the box, because its configuration files use IPv6 values directly.

> server on the Internet that doesn't support it?

The UE falls back to IPv6.

Cheers,
--/Saleem

---

From: Tom Herbert <[email-masked]>
Date: Mon, 18 Dec 2017 13:42:00 -0800

> The UE falls back to IPv6.
I don't follow. Isn't ILNP already run over IPv6?

Tom

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 18 Dec 2017 21:50:36 +0000

Tom;

> On 18 Dec 2017, at 21:42, Tom Herbert <[email-masked]> wrote:
> 

ILNPv6 uses the IPv6 packet format, so it can be seen as a superset of IPv6. However, ILNPv6 end-systems must interpret the address fields in the IPv6 header differently than for IPv6: ILNPv6 end-systems see a 64-bit Locator and a 64-bit identifier, rather than a 128-bit address. An end-system can spot an ILNPv6 packet by the presence of the Nonce header. So, if the UE does not see a Nonce header in the packet from the server, it knows it should use "vanilla" IPv6, and not ILNPv6.

Cheers,
--/Saleem

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 18 Dec 2017 21:51:08 +0000

Dino;

> On 18 Dec 2017, at 20:56, Dino Farinacci <[email-masked]> wrote:
> 

Yes, quite :-)

> I didn’t say it does. But signaling of some sort is required to map ID to Locator. 

ILNP signalling is only for Locator Updates, e.g. for mobility, or multihoming/multipath, and not for Identifier to Locator mappings.

> We, as architects, need to evaluate all holistic solutions. If the goal is to affect the cost to the fewest to benefit the more, then you know the tradeoffs between “should it go in the host or the…

It depends on the cost function, and I do not believe the cost function is simply "the number of nodes to be updated". (That would be a very interesting point for debate, but better, perhaps, in person at IETF101 than on the list?)

> 
> I have tried both and have failed (and succeeded) with either.

OK.

> And sometimes both is required. :-)

Agreed!

> The hosts (UEs and servers) may be originating and consuming IPv4 packets but that wasn’t my point. It’s the infrastructure with middle boxes that are usually IPv4. So it is just natural we have an…

I have to say that I have not given much consideration to moving along IPv4 as part of this.

> But doing IPv6 in the hosts can happen a lot sooner than in the core network (this is evidence of the progress of the last 10-15 years of host OS support AND deployment). 

Yes, agreed. (ILNPv6 runs over an IPv6 core network - its only the end-systems that need to be updated - so there is nothing that needs to be done in the core for supporting ILNPv6.)

Cheers,
--/Saleem

---

From: Tom Herbert <[email-masked]>
Date: Mon, 18 Dec 2017 16:31:00 -0800

Saleem,

ILA can run on end hosts as well as in network devices. Not using
encapsulation or extension headers maximizes interoperability with
deployed networks and existing mechanisms like ECMP and segmentation
offloads. For instance, packets with extension headers can still cause
problems and some network operators don't trust UDP and rate limit it
(although that problem may be less now that QUIC is getting traction).
Fewer on-the-wire protocol mechanisms also means better performance.
We use ILA on host servers to virtualize data centers and that works
well to get some optimizations. For mobile networks I tend to think
this is better served by mechanisms within the provider network. A
given network can implement efficient and seamless mobility using
solely the devices under their control. There are no dependencies on
transport stacks, host OSes, or applications, No need to worry about
OS release cycles or business motivations and priorities of OS
vendors.  It is much easier to provide SLA's for both performance and
privacy if all the elements are under control of the provider, and
this also eliminates many attack vectors on the mobility
infrastructure.

Tom

---

From: Saleem Bhatti <[email-masked]>
Date: Tue, 19 Dec 2017 09:26:13 +0000

Tom;

On 19 Dec 2017, at 00:31, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

Saleem,

ILA can run on end hosts as well as in network devices.

OK.

Not using
offloads.

Agreed.

For instance, packets with extension headers can still cause
problems and some network operators don't trust UDP and rate limit it
(although that problem may be less now that QUIC is getting traction).

Agreed.

Not necessarily. It is the layering and the interaction between the protocols that can impact performance, in my view. However, I agree that fewer is better, as it should mean less complexity, at least, and could also improve performance.

solely the devices under their control.

This all depends on the type of end-user. I am sure that there will be many end-users today with mobile hand-sets for which what you have described will work just fine: a single user, one hand-set, one-provider (at a time), one service (this fits the needs for a lot of users today).

There may be other users that want more flexibility, or more sophisticated service mixes. Some users may want some control of services themselves, or want control of configuration of services themselves.

There are no dependencies on
transport stacks, host OSes, or applications, No need to worry about
OS release cycles or business motivations and priorities of OS
vendors.

In terms of OS stacks, apps etc, once the code-base exists, I think that the hand-set providers will *usually* keep things up-to-date in a timely manner, as it is in their interests to keep the users happy.

 It is much easier to provide SLA's for both performance and
privacy if all the elements are under control of the provider,

I agree that such a system would provide useful service to a lot of users, as it does today. However, it may also restrict the flexibility and control available to some users who may want it.

I cannot claim to understand the commercial aspects of such networks, or to have any particular insight into corporate strategy for future systems from a commercial perspective.

As a *user* of *today's networks* I can say that the things I (personally) might value (for example security and privacy, selection of one or more service providers, service mixes), are things that I would like to have some (configuration) control over (at least), but such things may not be possible today - I am stuck with what I get and have to trust the providers/suppliers. (Even my home broadband ISP gives me some control over various aspects of service configuration.)

A *developer* for (near) *future networks* might want to access more than just an end-to-end bit pipe. It might be that by offering more than just a bit-pipe, new developers are encouraged to innovate, and there are new business models which appear that are attractive to service providers, network operators, and equipment vendors. This is all guesswork on my part, but such access would be an exciting outcome, in my view.

and

On the whole, I agree that exposing fewer system interfaces to end-users could help reduce the attack surface, but protective measures would still need to be in place. Of course, having fewer network entities would also help reduce the attack surface! :-)

Cheers,
--/Saleem

Tom