Minutes IETF103: lisp
minutes-103-lisp-01

IETF 103LISP Meeting Minutes

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

Agenda Bashing: Sharon Barakai couldn't make it ot Bangkok so the "Automotive
Network" is cancelled.

o WG Items

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

Presented the changes between latest two versions (09 & 10)
Mostly about mapping of VNI to VRFs and an updated the security section.
The YANG document is a bit out of sync and need some updates.
Need to add some changes due to bis documents.
Once these changes finish would like to request a WG Last Call.

Discussion
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 IID. 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 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? This will push people
to read and comment the document. Joel: After changes have been made going for
WGLC and make people read the document seems entirely sensible. Fabio: There
may be also something that we need to look at. Is related with the scope of the
password or the shared key that is associated with the with the map
registration because we introduced the xTR-ID and so we have changed that scope
in 6833bis. That needs to be reflected in this document. 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 version 10 but they'll go in
version 11.

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

Presented a short summary of changes on the two bis documents per areas of
change. Main changes can be summarized as follows: Scope of applicability has
change to focus on precise use-cases, not on global deployment. Hence, the term
"global" has been removed. LISP-Sec is now Mandatory To Implement. It is not
mandatory to use, but deployers that feel concerned can use it. Nonce
manipulation has been changed, it has to be incremented by one for each new
Map-Register, so to avoid replay attack for Map-Register. ETR/MS must store the
nonce in persistent storage. Concerning UDP and congestion Control,
implementers need to follow the guidelines from RFC8085 “UDP Usage Guidelines”.

Discussion
Luigi: I had 2 comments.  On the reserved bits that they should be actually be
assigned according to the comments Med's comment on the mailinglist. If we say
reserved they will not be used in the future. If they are unassigned they can
be used in the future. Dino: Wherever there are references to bits that are
labeled "R" 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 same server, they can use
different nonces. Albert: The nonces are indexed by xTR-ID. Dino: Since the ETR
can move and change our RLOCs you want something that's persistent so this is
why we have the xTR-ID in the specs. It was being used only for NAT traversal
we took it out. But now, to deal with 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 etc. So, the xTR can keep on advancing
the nonce because it keeps on moving. Then you know three days later and the
Map-Server shows up and the nonce advanced far beyond the stored
last-seen-nonce value. If so how do you resynchronize? Can you actually move
that way, or does the nonce advance only 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 the last one, so it doesn't have to be plus one. Erik: But does it
actually advance the nonce it's going to use only when it gets to Map-Notify,
because then you're advancing in lockstep. Dino: Since it's an acknowledgment
to the Map-Register the Map-Notify copy for nonce from the Map-Register and
then when the next Map-Register is 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: 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? Fabio: Since the space is 64-bit and we basically
use modulo two to the power of 64 we just pick one random. 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 2 to the
power of 64 space, and then it does +1 and it stores it in persistent storage
so if it crashes and comes back up it can go where it left off someone.

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

Presented the draft and discussed the benefits and objectives.
Make EID private and not trackable.

Asked for WGLC after update to be posted.

Question
Prakash : Question on use case.
Padma : Explained the use for mobility and how it can be 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, namely:
- Strong Elliptical curve crypto using DSA.
- Verify and invalidate single XTR.
- Can use the signature ID for registering an EID.
- xTR public key to encrypting resulting.

Discussion
Luigi: It's interesting, but this means that maybe we will have to update the
specs somehow. Dino: 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 main specs then in that case you have to clearly state it. Fabio: Do you
think there will be such changes? Dino: There will be at least a bit stating
whether the Map-Record is encrypted or not. Most likely there will be packet
format changes. We need more work on this, right now we will just keep it WG
document. Fabio: There is no dependency between this one and anonymity. Dino:
They are complementary. Erik: Notion of being able to encrypt everything is
interesting. Has anybody looked at what's the performance impact of using
public key crypto for all? Dino: I'm supposed to figure out a way of having
some asymmetric scheme if you're going to do. Erik: you can imagine to use a
session key. But what is the impact on performance? Dino: Doing some
performance measurements encrypting Map-Register using chacha. I will report 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 version of the document.
Added Site-ID and xTR-ID definitions.
Changed IANA considerations and clarification in the security sections.
Added rate limit for Map-Notify sent to an xTR-ID
Because of the important changes in 6833bis regarding nonce, there is an open
question on Map-Request used for subscription and Map-Notify used for
publication? How to distinguish them from Map-Notify sent to acknowledge
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

Describing the problem of having multiple domains that you concatenate with
LISP.

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, therefore the intra site connectivity works as long as
this site is working. That's an important point to call out, which 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. This doesn't really improve Mapping System scalability,
because the ability to delegate in any of the Mapping System version we've used
gives you very good scaling already and this introduces re-encaps and
additional specific points of failure along the inter-site paths. And if you
didn’t do this it would have been more robust. It's not that you can't do it.
It 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 
more if there's a benefit than it needs to be much better explained before
getting into the details. I see how you can make it work, I do not see why.
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. But, you
have to coordinate with another organization. Joel: You're going to have to
coordinate for all the inter site stuff anyway and you don't have to coordinate
if you can't reach 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 thinking that 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 inter-site connectivity. As opposed to before where you
have to fail all of your Internet connectivity to lose it. Victor: One of the
things that we did in coming to some of these ideas, was that we thought we
could do is with DDT as is. One of the things that happens in these networks is
that there is a high degree of mobility. We want to re-anchor basically the
devices as they move from one place to the other. It was not evident how we
would actually do with DDT alone but you're right the DDT gives me a
distributed structure where I could actually emulate those Mapping Systems.
But, I don't have a good way for rehoming a moving device. Joel: If you inject
aggregate information, when I re-home in a different site I do not have
connectivity unless I change my EID. The whole point is not to change the EID.
Doesn't seem to match what we set as our objectives. The document needs to be
clear about the objectives. Victor: Fair enough. But we were not able to solve
it with the tools we had at hand. Joel: If we need small changes in the Mapping
System that looks cleaner than using tunnels for something that claims to be
robust and scaling. Joel: Actually, the split horizons (for mapping
announcements) is a little bit tricky, because you have site prefixes which are
going to show up from the overlay into the local site legitimately is there has
been movement, but accidentally if something else is going wrong. Victor:
There's a couple of checks that we put in the draft, but yes, for sure it's one
of the trickier things. Joel: Trying to build logic that depends on the RLOCs
with which one receives the information is fragile. Victor: Yes, we also
suggested some checks on the actual away tables, which basically indicated its
mobility event. Dino: We 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. That's why you had to add access lists. Victor:
Those procedures at the end systems are consistent with the ad mobility
procedures. 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, we relay mobility events, basically with Map notifications that
that go back to the departure sites.  We are going to also relay Map
notifications that go towards the sources of multicast. 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 difference being if there is a
failure of one of them, basically all the other sites remain unaffected. Dino:
One benefit we did not talk about is how these Uberlays and Site Domains can
help the underlay. RLOCs are local and do not need to be re-distributed in the
Uberlay. Zheng: Would you use inter-site multicast? Victor: Yes. It's all
documented. Is just concatenating LISP signal-free multicast. Luigi: What about
sites using different encapsulations? Victor: Good point can be one of the use
cases driving the work. Dino was also mentioning NAT, when the underlay
requires NAT. Encap translations can naturally fit in our design. Fabio:
Looking at the ICAO, that's the case, there will be different transport for
different organizations. Victor: Very good point. Part of what is driving this
is the use case having the civil aviation ground being restructured. It needs
to be modular. Different countries will choose different technologies. They
will meet in the center, the Uberlay. So, part of the motivation of this work
has been to achieve this modularity. Joel: this is interesting. Different
parties can even use different Mapping System technologies, and that could be
an argument for not just concatenating the Mapping Systems. Going down to the
xTR is the only way to have a clean separation.