LISP WG @IETF102

Minutes

Chairs went over the agenda and the WG document updates.

Chairs stressed the need for ALL authors to disclose IPR in a timely manner for documents to progress.  In some of the bis documents there are no disclosures but in the original documents there are IPR from Huawei. Therefore, the write up will state the original documents have IPR that may apply.


o Non WG Items

- LISP Data-Plane Telemetry - draft-farinacci-lisp-telemetry-00.txt
Presenter: Dino Farinacci

Dino presented a sneak preview of the draft.
LISP xTR can characterize performance of the underlay, more performance data enables more informed decisions. The -00- draft is identifying the desirable parameters. Use of RLOC probe.

Discussions
Erik: We should consider the coloring for packets for measurement of packet loss.
Dino: Good suggestion
Luigi: The only ETR that can ask you about the telemetry data is the one talking to you why? Why others cannot ask you about telemetry of data on a mapping?
Dino: We do not want to flood information to anybody that just request it. We want to actually sign map requests and validate them. If a source wants to make decisions unilaterally we do not need a management plane.

- LISP Control-Plane ECDSA Authentication and Authorization - draft-farinacci-lisp-ecdsa-auth-02.txt
 Presenter: Dino Farinacci

Dino: Presented a brief overview.
-	authenticate and authorize xTR using the mapping system
-	How to sign map-registers/requests.
-	How to store public-keys in MS and introduction of crypto-EIDs

Discussion:
Joel: how does that look up on the hash fit …. where it’s supposed to be the tree is based on delegation, just arbitrarily map it on the tree or ?
Dino: The hash that you look up is appended to an ascii string called hash. It is a distinguished name as the EID in the EID record and DDT can build hierarchy on any ascii character in any string.
Erik: I can secure it because we have 120 bits
Victor: have you considered multiple signatures
You may want to be crisp of what you want to be signatures
<missed name>: Terminology EID/signer EID is confusing



o WG Items

- LISP YANG Model - draft-ietf-lisp-yang-08.txt
Presenter: Reshad Rahman

Reshad: went over the changes between 07 and 08 (see slides)
Ready for WGLC
Need more input from the WG
For the chairs do we think after these changes that the document is ready
Joel: is the document stable or not?


o Non WG Items - continued

- LISP Control Plane for SRv6 Endpoint Mobility - draft-rodrigueznatal-lisp-srv6-00.txt
Presenter: Alberto Rodriguez-Natal

Alberto presented the use of LISP-control plane for SRv6 basic ideas but there are refinements underway for next version.
LISP is “where to go”
SRv6 is for “how to go”
Removed TE in version -01

Discussion:
Disjoint resolution Slides
Dino: Regarding to pub/sub MSMR even if the RLOC does not change but SR source route changes then it looks like a mobility that has to be signaled.
Alberto: that is in the next model. Here we assume that the SR path is computed and is from egress and it is disjoint.
Dino: This is sending a new precedent. In the EID mobility draft whenever the RLOC changes, we trigger map registers, pub/sub, data triggered SMRs. I do not remember if we say that if the contents of the RLOC record changes vs RLOC address changes.
Joel: What they put in the RLOC address is not the segment route, it is the label for the policy for the segment route to go ask the PCE.
Dino: I did not want to bring that up but that is another issue I have with two stage lookups
Joel: The policy did not change so there are no changes in the mapping system.
Dino: Not a criticism on SR. Look at this as just an EID mobility learnt over an MPLS cloud and the label switches for the underlay … that is the same case here where the RLOC does not change just the label changes because you have a new TE path. I do not know whether we have language about the characteristics of the underlay has changed.
Joel: you have to trigger something to indicate that here there is nothing to change in the MS. Don’t know how you would do it.

Joint resolution Slides

Dino: what if the SR policy does not change but the reachability of a segment change.
Darren dukes: PCE would then notice that change, compute a new path and notify the MSMR of the new path and that would then get distributed down to the ITR.
Dino: All ITRS?
Darren: All ITRs or all ITRs interested in this binding.

Open Questions:

Dino: I want you to give a statement about the 2-stage lookups.
Alberto: In the draft, we have both single and 2-stage look ups as separate options. There will be refinements as we go forward.
Dino: So, in the first model the SR is directly in the LCAF record.
Alberto: In the first model the information needed to compute the SR path in the underlay is in the LCAF.
Victor Moreno: Question on the single look up .. once you get the update from the PCE, is the thought to actually push the update to the ITRs or are you going to send a map notify the ETRs involved as well then let the SMR mechanism take place or is this restricted to pub/sub scenario only.
Alberto: when there is a change on the policy, the PCE will notify the Map-Server, MS will see the change in RLOC information and it can do pub/sub.
Victor: clear for pub/sub but not for SMR mechanism.
Dino/and Victor: Need to look at the EID mobility draft to see if this cover this specific case.
Dino: In reference to Luigi’s question on telemetry about why should the ETR give the information back to the ITR – this is a good example here where an ITR may have two RLOC records and two segment routes. So, you may want to RLOC probe twice to explore the different paths as these paths are sourced based you have this directionality problem.
Luigi:  You do not use the  lisp encapsulation but you do not say anything in the document. In principle, you could use it and benefit from all the functionality it comes with.
Alberto: Technically you could.
Luigi: Clarification in the document would be desirable.
Darren: Your question about doing LISP encap and SR traffic engineering may be on that needs to be looked at in there.
Dino: Back to ABC slides. Glad Luigi brought this up as it begs another question. Why can’t A, B, and C be RTRs and you encapsulate at each point and if you do that you get RLOC probing between each component of this source route, this is exactly what LISP TE is doing with ELPs. So, one can argue why do you need SRv6 because if you put that RTR topology in there, the underlay between A-B and B-C can be a combination of IPv6 and IPv4.
Victor: you brought an interesting scenario where you can have SRv6 with LISP and no traffic engineering and in that case, what are your thoughts of subsuming the PCE functionality into the MSMR.
Luigi: why PCE?  We could have PCE or the MS do it.


- Ground-Based LISP for the Aeronautical Telecommunications Network - draft-templin-atn-bgp-07.txt
Presenter: Fred Templin

Discussion
Dino: You said the planes are multihomed .. Do they use both links at the same time?
Fred: They can.
Dino: What is the addressing when they are using both at the same time.
Fred: They use the same EID over both links. You may have differentiated service code points for some traffic points.
Dino: Have you considered both BGP and LISP at the same time?
Fred: Yes
Luigi: About ICAO, how soon will we know their decision? Are they considering the solution right now?
Fred: ICAO is trying to push a solution adopted soon. But whether this solution is going to be a pure LISP or pure AERO or mobile IPv6 or a hybrid of those is still under process.
Brian: Have you considered to have the planes as a mesh network to relay packets
Fred: interesting idea. Are you thinking of air-to-air links? we think about that when we talk about drones but not so much about civil aviation airplanes.


-  A Decent LISP Mapping System - draft-farinacci-lisp-decent-00.txt
Presenter: Colin Cantrell

Joel: It seems there is a mix of at least two different sets of requests which come from different parties and it is confusing.  Map Registers that come from other ETRs. While the ETR is one of your DHT elements so it would not be sending Map-Registers. Their Map-Request which come from ITRs to Map-Requesters not Map-Servers and now who is going to prove work? Because the request has to go across the DHT to the authoritative node. Looks like he is going to ask the trusted party to end up doing work because the trusted party is getting besieged with requests which he has no way to ask for proof of work.
Colin: it would be agnostic to the message and theoretically scale it based on the actual computation requirements of each message. That is still something that is being thought out.
Joel: Doesn’t answer the question. My point is that Map-Requests come from ITRs to the edge of the mapping system. You haven’t talked about these entities and these are not asking for proof of work, so the proof of work is coming from the authoritative node. By the time you ask the authoritative node to ask for proof of work to somebody else then
a.	Seems to be the wrong question
b.	He is asking the wrong party – a trusted member of the MS and not the ITRs
Unless you are also changing things so that the ITR as members of the mapping system?
Colin: In a decentralized mapping system, the word trust is generally disregarded because anybody could be a malicious actor. This could mitigate that in the sense that even a Map-Server could be malicious.
Joel: Then you are talking about a very different DDoS that everybody else worries me.
Colin: There are a lot of different factors and do not have answers for all of them in this preliminary architecture to may be facilitate the idea of a potential use case.
Dino: Separate all the XTRs being part of the MS from DoS attacking the MS because we could protect DoS attacking the MS when it is not decentralized. Think of MS today and how we could use proof of work to slow down attackers
Joel: That is a major change .. not to the mapping system but to the interface which we have defined as stable. There is a difference between mapping system operation and we’ve structured this so the new mapping system is transparent through the external interfaces and changes to the external interfaces.  This looks like it takes changes to the external interfaces. It is not out of question but you want to make it clear if you want to present it here.
Colin: from what I understand we would not need to modify too much of packet structure you would be able to use existing and check for zero bits.
Joel: Need some extra messaging to about meeting constraints…
Colin: that would be exactly the message on the Map-Reply .. We were talking about using some high order bits .. 64 bits …
Dino: Right. The idea would be that the ETR would do the proof of work and the hash doesn’t have to be sent in the map register and only the nonce. We already send the nonce today. On the other side is guy who takes the nonce and hashes out the packet and determines if it is good/bad. Change the level of difficulty if we know we have a map notify which is an Ack for the register. The Map-Notify that you send back could have a difficulty value so as DoS attack increases the difficulty of proof of work increases.
Joel: All I am saying is that you need to put something in the messages so that you know what is the difficulty level you got to meet.
Victor:  Seems you have two things here the decentralization of the mapping system and this and you may need two separate documents.
Joel: There is assumption that this is an environment in which not only are the XTRs highly distributed but any XTR is perfectly ok to claim to be service any EID as long as no one else is claiming to do so
Colin: No. When you as a distributed ledger on top of this then there is a reputation system so that somebody’s claim is not just a claim out in the open abyss. You actually have a masterful verifiable trail of somebody’s trustworthiness that you can have a distributed trustless system by mathematical verification.
Joel: then you will need to give a lot more details on how this will work.
Joel: the relation of who is allowed to register and so on.
<Missed Name>: There is a lot of work going on and need to be careful how to separate the documents
Dino: Albert and his team has been doing a lot of work on how blockchain technology in general and there are ideas on how to enhance the mapping system to do prefix openness and allocation …
Rajiv: There was a need for DNS to begin with.
Relying on third party? Does that reduce the efficacy?
Colin: Not necessarily. DNS is just a convenient but it is possible not to rely of the DNS.
<Missed Name>:  possibility of being malicious on the other side.
Colin: With consensus, you do not have to talk to one node but to multiple. They give you a list of malicious addresses. This is why you do a full validation of the ledger on your local node to verify all the cryptography so even if they try to send malicious data it can be detected.
Rajiv: Assuming they do not have the majority.
Colin: Yes. This is what is called civil attack, which requires a lot of computation power for proof of work and validation of state.
Dino: People ask what is decentralized Internet? If you are using DNS, it depends on the third party. Where it is and who is managing it. I like to think of it this way and we use something like LISP Decent and every XTR is mapping system or a Map-Server. I like to think of it as a neighborhood of devices that have local connectivity If you do not have multicast you can still rely on DNS but where it is all local and trusted among that trust group of the neighborhood.
DNS is decentralized in a trusted environment
Joel: AFAIK none of the arguments for deployment for LISP match what you just described. DNS are usually scattered across the internet and not locally connected. If they service one data center (opposite case) then they are clustered and are under a single administrative control and don’t have a distributed trust problem. So be very careful describing the problem. Block chain have interesting properties.
Colin: Supply chain management, auditability and immutability of data so that’s where you create trust and where mathematics is used to verify the truth. So, in a sense you could call block chain or distributed ledger a truth layer of the internet which is something that we do not really have now. The truth is determined by global consensus and the more people we have validating and that consensus, the more you could consider that truth, so it give layers of abstraction that help give an improved frame of reference. There is a significant improvement that can be done.
Why decentralized internet? It makes it more robust and it removes it from central points of failure and also for central points of control. So, peer to peer networks are robust and have high percentage of uptime. We need fall back if a Map-Server gets put under a DDoS attack, you have a distributed mapping system now. There are trust issues associated with that but this is where the DLT hopefully can help. DLT relies on robust nature of peer to peer and sort of run less reliable on such network would require this distributed topology. The problem of getting the full mesh topology and what we have is what LISP is actually bridging for Nexus significantly. The decoupling of your routing locators and endpoint identifiers and being able to tie that to a cryptographic identity so that you can actually be reached and I can know somebody is somebody and that they can prove who they are by signing from the specific key in a signature chain and I can look up not just from the EID I can look up their whole track record if they validate it. It gives you a better auditable trail of events that you can use to create better selection bias.
Dino: I just want to add to your last point, the idea here is that crypto–EIDs give you Identity at the network layer and crypto-currency wallets gives you this identity that is very changeable because you have different set of parameters when you change it at the application layer. The question is – can the security of this application layer help the network being more secure and vice versa. LISP security helps the application be more secure.
Colin: That the idea with layers of abstraction, if you add a ledger layer on the OSI then that ledger layer can have an API that’s accessible from LISP layer or layer 3 which then be able to ask the ledger about certain things or certainly IDs or certain Map-Servers and be able to get actual data from there so that the network layer can be less spoofable and vice versa. When the ledger can actually recognize the IDs through that and have trust – they are going to know that nobody can spoof an ID. You can use a VPN or whatever but I know I am talking to the same EID and I see a cryptographic proof that this person is who they are based the distributed ledger.


- Overflow Time/ Discussion

Dino: what is the decision for the OAM document? Do we have or not an OAM document, if not are we losing the text we pulled out?
Luigi: It is not blocking the bis documents because there is no reference.
Sent an email to Dino and Albert on next steps.
Dino: We are not questioning the effort of building a separate document but it is the principle of having it in the third place.
Joel: We are trying to get everything else unstuck.
Dino: We are at a stalemate.
Joel: Moving forward without waiting for it.
Dino: We are losing text.
Joel: It can be recovered by somebody … but it doesn’t block getting to PS.
Albert: Is it part of the charter or not?
Joel: Yes, but it does not have to be part of getting to PS. We want it but where it was. If no one wants to write it what interest in the WG?
Dino: Not a question of interest in the work. People have implemented that text. It is going to be lost and the only way to retrieve it would be to go back to the experimental 6830.
Joel: No someone will write the RFC we want for standards track.
Albert: For the text if it is in the right context has value. The right context was the rest of the RFC.  If we separate the text then we lose the context and value. It is does not mean that if no one wants to do it that the text has no value rather that you lose value of the text.
Joel: Well this was not only the chairs arbitrarily deciding but the WG felt it is best to remove it and that’s why we are advancing without it.

Pointers to IETF102 LISP Session:
https://datatracker.ietf.org/meeting/102/session/lisp
https://www.youtube.com/watch?v=2aQsbTxPfsA