Minutes IETF102: lisp
minutes-102-lisp-00

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