Minutes IETF103: lisp
minutes-103-lisp-00

IETF 103LISP Meeting Minutes

Monday, November 5, 2018
9:00 - 11:00, Morning Session I, 120 Minutes
Room: Boromphimarn 3

AGENDA

o WG Items

- LISP YANG Model - draft-ietf-lisp-yang-09
  10 Minutes (Cumulative Time: 15 Minutes)
 Reshad Rahman

Presented the changes between the two version
Mostly about mapping of VNI to VRFs
Updated the security section.
The yang a bit out of sync and need some updates
Need to add some changes due to bis documents and after that plan to ask for
WGLC. Once these changes finish would like to request a wg last call.

Discussions
Victor: Regarding the VNI references they need to be updated to instances as
soon as possible to be aligned with all the specs. Reshad: Yes Joel: You
mentioned VNI and use VNI in the mapping indexes but what's supposed to happen
if the VNI is the public Internet. If it is not a private network, the mappings
grouping and it looks this looks like a mandatory key and what value would
you'd put in? Reshad: You would have a default ID. Joel: You do not have an
instance ID for the public Internet. that's I'm a little confused. Dino: if you
encode an extended Eid with an instance ID and it's for the public Internet the
values . If you don't include the instance ID it's assumed to be zero because
it's unspecified. So we probably should note in the yang that zero is the value
for public Internet and we'll double-check the VPN document that formally
defines instant ID that zero means public Internet . Joel: OK Fabio: Reshad: in
the private version we have these changes and it will be published soon. do you
chairs or anybody in the room having an issue if after we've made those
corrections that I have mentioned that we start a WGLC Joel: after people read
it and comment .. seems entirely sensible. Fabio: there may be also something
that we need to look at this - is related with the scope of the pass or the the
shared key that is associated with the with the map registration because we
introduced the XT ID and so we have changed that scope Reshad: It is in the
private version Alberto's started making those changes but yes you're right.
Those changes have to go in maybe they won't go in in /10 but they'll go in in
/ 11.

- Update on 6830bis/6833bis documents
  20 Minutes (Cumulative Time: 35 Minutes)
  Albert Cabellos

Presented a short summary of changes on the Bis documents per areas of change

Scope of availability
LISP has changed to focus on use cases.
Removed global term.

LISP-Sec is mandatory to implement
Lisp control plane has security assumption that the
MS is secured and trusted
ETR has pre-configrured trust relationships with MS
LISP  Sec must be implemented for deployment who are concerned

Anti-replay attack for map-register
Nonce is autoincremented in each map register
Non is returned in map notify msg
ETR/MS must store the non in persistence storage

UDP and congestion Control
Follow guidelines from RFC8085 “UDP Usgae Guidelines”

Presented the different sections that have been modified to address the concers
raised during the telechats.

Discussions
Luigi: I had 2 comments.  On the reserved bits that they should be actually be
assigned according to the comments - if we say reserved they will not be used
in the future if they are assigned they can be used in the future Dino:
Wherever there are references to bits that are labeled then there is an
explanation for them say reserved and unassigned Luigi: okay it's not the
really compliant.  The second comment was just a clarification, I think we
should specify that the last nonce is by ETR because if we have two ETRs they
will both register to the main the same server. They can use different nonces.
Albert: so the nonces are indexed by bit. Luigi:  that's important message to
known by ETR, we generally speak about less but when you say it there. Albert:
Do you you mean it's the … Dino: Since the ETR can move and change our RLOCs
you want something that's persistent so the next this is why we had the XTR in
the spec to begin with but it since it was being used for NAT traversal we took
it out. We put it in the pub's pub because it had use but now to do the replay
attack we put the xtr ID back. Eric: I haven't read the spec on this but these
nonce can they actually get out of sync suppose that the XTR is sending nonce
to that map registry is never received by the map server.  Then moves and it
starts sending nonce three that's never received by the map server etcetera
right so the XTR can it keep on advancing the nonce is because it keeps on
moving. Then you know three days later and the map server shows up its advanced
far beyond you know and the map server still believes that nonce 2 - is the
next one that it should see. if so how do you resynchronize? So first of all
can you actually move that way or does it does it only advance when it gets a
map notify back? Albert: They will know that the map server is not responding
because it is not receiving the map notify. The nonce must be stored in
persistent storage to keep track of the state. Dino:  The map server always
accepts a nonce that's greater than or equal to the last one. Greater than not
equal so it doesn't have to be plus one a sequential Erik: Yeah it might be
detailed but does it actually advance the nonce it's gonna use only when it
gets to map notify because then you're advancing in lockstep. Dino: Are you
referring to the map notify as an acknowledgment to the map register? Erik: yes
Dino: Okay so that because that takes out the discussion about uncensored map
notifies. Since it's an acknowledgment to the map register the map notify copy
for nods from the map register and then when the next map registers sent it
could be sent +1 or +. Erik: The only way you could get messed up is if you
wrap around during the nonce number space. Luigi:  2 questions: If I register
to two different map servers I use the same nonce. Joel: You could choose to
use the same one that would be legal but you're not required to as I
understand. Dino: Yes this is true. Luigi: How do we choose the nonce at the
beginning you talk. Fabio: Since the space is 64-bit and we basically use a
particular modulo six module or two to the power of 64 we just pick one random
right then you start with the first one and then you keep going with their own
state there it just asked about. Dino: I could share with my implementation
does if an ETR comes up for the first time it doesn't have any persistent
storage it allocates a random number of that to 264 space and then it does +1
and it stores it in persistent store so if it crashes and comes back up it can
go where it left off someone.

- LISP EID Anonimity - draft-ietf-lisp-eid-anonymity-04
  10 Minutes (Cumulative Time: 45 Minutes)
  Padma Pillay-Esnault

Presented the draft and discussed the benefits and objectives
Anonymous to prevent tracking - Hiding in the crowd
Use case for mobility

Asked for WGLC after update to be posted.

Question
Prakash : Question on use case
Padma : Explained the use for mobility and how it canbe helpful
Luigi asked the room if ready to go to wglc. No one in room opposed.
Luigi : will send to the list for last call

- LISP Control Plane ECDSA Authentication and Authorization -
draft-ietf-lisp-ecdsa-auth-00
  10 Minutes (Cumulative Time: 55 Minutes)
  Dino Farinacci

Presented the draft and discussed the benefits
Benefits
Strong Elliptical curve crypto using DSA
Verify and invalidate single XTR
Can use the signature ID for registing an EID
Xtr public key to encrypting resulting.

Discussion
Luigi: it's only interesting but this means that maybe we will have to update
nthe specs somehow. Dino: yeah so I was hoping that we would do this
independently of those specs Luigi : Absolutely. You have to make sure that if
there is an update to the mains that in that case you have to declare that's my
point right Dino: Absolutely.  But with the deadline is we don't want we're not
trying to squeeze it in.

Fabio: …
Dino: Not ready to carry it forward …
Erik: Notion of being able to encrypt everything .. has anybody's looked at
what's the performance impact of using public key crypto for all? of that Dino:
I'm supposed to figure out a way of having some symmetric scheme if you're
gonna do. Erik: What is the performance impact? Dino: doing some performance
measurements on this

- Publish/Subscribe Functionality for LISP - draft-ietf-lisp-pubsub-01
  10 Minutes (Cumulative Time: 65 Minutes)
  Alberto Rodriguez Natal

Fabio Presented the diffs from -00 draft
Added Site-ID and xTR-ID definitions
IANA considerations and clarification in the security sections
Added rate limit for map-notifies sent to an xtr-is

Presented open items
Important aspect due to changes in 6833bis regarding nonce.
6833 introduced nonce for map-register and per xtr-ms pair.
Open question on map-request used for subscription and map-notifies for
publication? How to distinguish them from map-notify sent ot ack map-registers.

No questions

o Non WG Items

- Multi-Domain LISP - draft-moreno-lisp-underlay-00.txt (To Be Submitted)
  10 Minutes (Cumulative Time: 75 Minutes)
  Victor Moreno

Joel: I can interrupt you right there because looking at the draft I was left
confused. The first point I'd  make is that the comment you made just now about
having a mapping system or a portion of the mapping system that this site can
take responsibility for and therefore and it's only an intra site connectivity
works as long as this site is working. That's an important point to call out
that is not clearly called out in the draft. Having said that the converse a
lot of the this seems to actually make robustness and survivability worse. The
whole design of Lisp was to be extraordinarily scalable and that the mapping
system was extremely flexible. I'm left going… well this doesn't really improve
mapping system scale because the ability to delegate in any of the mapping
system inversions we've used gives you very good scaling already and this
introduces reencaps and additional specific points of failure along the
intersite paths. And if you didn’t do this it would have been more robust. I'm
left it's not that you can't do it that clearly works but except for the
mapping system and I think that could be done in simpler ways.  Most of this
looks like it actually undermines its own argument instead of bringing us
further forward. I think you need to focus on that more to if there's a benefit
than it needs to be much better explained before getting into the details Dino:
I think we missed messaging the benefit the idea wasn't we trying to make the
mapping system scale well those are three independent mapping systems that are
managed independently it's not a subtree of one versus the other. Joel: Why are
they managed independently? Dino:  Because these sites are not wholly owned by
one organization Joel: Okay if you're just worried about the mapping system
wouldn't it be simpler to see if there's a way to attach this set of mapping
system which has delegated some things to a larger mapping system and inject
all the information. Dino:  Because that's what we do today. You have to
coordinate with another organization Joel: You're gonna have to coordinate for
all the inter site stuff anyway and you don't have to coordinate if you can't
the other organization. It should be possible to solve this problem purely
inside of the mapping system. We entertain lots of mapping system alternatives
that's one of the nice properties of LISP without getting into the complexities
of adding tunnel routers to provide interconnection. I'm just I think by mixing
the two instead of increasing robustness it actually seems to decrease
robustness because now there are two points which if both of them fail you have
no intersect connectivity. As opposed to before where you have to fail all of
your connectivity to lose it. Victor: right now I think that one of the things
that we did in in basically coming to some of these I'm not gonna call them
conclusions but t ideas it's basically evaluated we could do is with DDT  with
a high degree of mobility. We want to reanchor basically the devices as they
move from one place to the other right which was not evident how we would
actually do with with DDT alone but you're right the DDT gives me a distributed
structure where I could actually emulate those mapping systems and but I don't
have a good way of rehoming a moving device right so well but it's the only
thing that's injected.

…
Joel: Actually the split horizons a little bit tricky because you have site
prefixes which are going to show up from the overlay into the local site
legitimately.

If there's been movement yeah but accidentally if there's something else going
on it's gonna be. I think you can make it work but it is a bit tricky

Victor: there's there's a couple of a couple of checks that we put in the draft
but yet for sure it's one of the trickier things

Joel: I'd hate to be put it trying to build logic that depends on the are locks
with which one receives the information is fragile

Victor: Yes we also suggested some checks and checks on the on the actual away
tables which basically indicated its mobility event

Dino: Had this exact same problem with the ID mobility. The question is .. is
there somebody spoofing you over there on that subnet or did the guy actually
move there Vistor: those procedures that those end systems are consistent with
the ad mobility procedures in that that's we try to basically make sure that we
don't reinvent things where we're not necessary.  the other thing that we do is
we relay events across the domain so here I have called out that we relay
mobility events that there's basically map notifications that that go back to
the departure sites.  We are going to also relay mobile notifications that go
towards the sources of multicast right so so basically we're relaying a lot of
the signaling.

Joel: in many ways this is behaving like one mapping system
Victor: Yes you could say that the only the only difference being if there is a
failure of one of them basically all the other sites remain unaffected ….