Minutes IETF104: lisp
minutes-104-lisp-00

LISP WG Minutes
AGENDA

Session 1/1 (90 Minutes)
=-=-=-=-=-=-=-=-=-
Friday, March 29, 2019
9:00 - 10:30, Morning Session I, 90 Minutes
Room: Athens/Barcelona

- Status reports for WG drafts
        5 Minutes       (Cumulative Time: 5 Minutes)

Luigi: gave an update on the wg documents.
The documents are still in progress due to reviews.
The bis documents has thorough security reviews and lisp sec document is put on
wg last call to have all documents regarding security reviewed together.
Hopefully there will be progress and all the problems have all been solve and
it made the document better.

o WG Items

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

Albert presented:

List of DISCUSS issues
1. Incremental deployment of LISP-SEC and downgrade attacks
2. Security of the gleaning mechanism: Traffic redirection of off-path attackers
3. Security of the LSB mechanism: Spoofing attacks
4. Security of the Echo-Nonce mechanism: Nonce is too short to prevent off-path
attackers 5. Security of Map-Versioning: Gagging updates 6. Anti-Replay
protection of Map-Register 7. Long-lived keys to authenticate Map-Register 8.
Map-Request/Reply anti-replay protection

Resolution
- Addition of a new e-bit
- 2,3,4,5 restricting usage of Gleaning, LSB, Echo-nonce and map versioning
when communicating over the internet. Only for use in a trusted environment and
the deployer should be aware of the issues associated with this. - 6. start
nonce with a random number and incrementing - 7. Usage of a derived_key :
definition of the key-derivation Function algo

Discussion:

2,3,4,5: point
Luigi: Updates need – do not use it in an untrusted environment and the
deployer need to be aware of the risks related to this mechanism Albert: The
document will be update to include those

6. Start nonce …
Dino: It was suggested that when you start, the nonce doesn't start at 0 but
with random nonce. randomly

7. Long lived Keys
Dino: What we haven't talked about is how do we make this interoperate with the
existing stuff. We  should do that offline.

Fabio: The way to make it interoperable with existing implementation is that
today we define the algorithm ID that is there in the packet and the algorithm
ID today is specifying only the HMac function that we use in the map register.
In the map register message, there is the authentication data and the algorithm
ID that you should use. We can define a new algorithm IDs that are say
specifying not only the HMAC function but also the KDF function. The ETR will
have to do not only the HMAC computation but before that it will have to do the
key derivation function and this is extensible because we can define future
algorithms.

Dino: Can we do that a high order bit because if we set the higher order bit
and we should say let's use KDF for all the existing hashes that are
identified.  If the high order bit is zero it works like today. If  the higher
order bit is set then that means you have sha-256 with KDF

Fabio: Yeah. I didn't think about that …it's a once in a time …

Dino: rather than having to X values you just set the higher a bit and then any
new HVAC you add later can run in a non KDF mode and KVA, Fabio:  Also don't
want to burn two entries in there for things that in the future will not use ,
We define 1 2 extra decimal but yeah it might be a small section

8.Map-request

Albert: relaxes requirements on nonce that is just used once.

Luigi: Just for clarification to understand this, you throw away the pair but
you can keep the nonce value. Is just the association you throw away. Albert: 
You throw away everything. If you need to send a new map request then you will
generate on your nonce and a new OTK. Fabio:I think what it is providing is a
reply protection is the fact that the one time key is used one time. So, I
generated one time key which is a big number (128 bit) then I'll do the map
request for a exchanged replies come back. I check the integrity protection and
then I discard the one time key. The nonce is now providing only an index. 
When I receive the map reply back, I can basically look up which one-time key I
had used to protect that  key then nonce (64-bit) still has to be randomly
generated because you don't want to use the same nonce because otherwise you
will point to the same one time key. The property of anti-replay is not in the
nonce but in the one-time key. Let's make a difference because otherwise the
nonce would have had to be much bigger.  In conversation with Ben, if LISP-sec
is not enabled the nonce provide a limited anti- reply protection. Dino:  I
just wanted to address Luigi's question so the nonce otk pair in both the
implementations of lists I've done it's also used as a data structure first
rate limiting map request in lieu of the map reply coming back you want a rate
limit so what happens is if you send a map request and you don't get a map
reply you're gonna at some point later send another map request you send it
with the same nonce with a different otk or you can be a new to tuple pair so
you have to consider those things too because the rate limiting is really
important right Fabio: I think there is text that is saying that you know rate
limiting is important yeah Albert: We now have exponential backoff in order the
rate limit for the retransmissions.
 Fabio:  what this thing does is-  if the attacker is sending you map replies 
 with a nonce that you have sent you will still look up your OTK  and also
 there is still the possibility of a ..
Dino: On the other hand, the attacker could just be the man in the middle and
just dropping the map-request causing you to retransmit to see if you're using
the same one-time key. One time is a relative term right, is it one time for
this destination query or is it for each individual map request?  It should be
the latter.
 Fabio:  One time is one time.
Luigi: Crystal clear
Albert – gave a quick update on the yang model…
- LISP YANG Model - draft-ietf-lisp-yang-11
  10 Minutes (Cumulative Time: 35 Minutes)
  Alberto Rodriguez Natal

Alberto : Request WGLC and process for yang doctor review.
Luigi: Let me do it and then we go for WGLC. I mean if he (Yang doctor) gives a
green light it's it's great.

Dino: so the this current yang model has features that corresponds to the
proposed standard documents nothing more or less. Is that right? I mean there's
existing working group documents that may define new types and so I'm just
wondering to not lose it.

Alberto: Our intent is to be perfectly aligned with this but if it is not and
if you guys find something let us know/

 Dino: Let's be honest here, it has all this instance-id stuff in there and
 that's all defined in the VPN document which is a working group document
 that's not going to propose standard.  I don't want to complicate things but …

Albert: I mean they're well but in other cities they have attributes he said
any reference ID

Dino: we don't talk about instance ID explicitly other than it's an extended
Eid lookup in the mapping system.

Joel: The mapping system PS documents do support the field and so it's okay to
have them in the yang model because it's not like we're modeling a field that
is not in the PS document. I think we're walking the line the right way.

o Non WG Items

- A decent LISP Mapping System (LISP_decent) -
draft-farinacci-lisp-decent-03.txt
  15 Minutes (Cumulative Time: 50 Minutes)
  Dino Farinacci

Joel: It sounds like a couple of issues and they may be addressed on later
slides but one if you want stability something gets strange when you suddenly
add another server because he can't actually take responsibility for any
addresses because anything that would hash to him now must have hashed to
somebody else before so you there seems to be a problem with adding and
subtracting things if you require that the function is permanently. Dino: we
were able to get that to work well so stay tuned okay Joel: that's all that's
fine the other one is there's a philosophical what determines who's allowed to
participate in these things right is there a slide on that? Dino: I will
address that.

Joel: let's be clear prefix in this case means dotted suffix

Dino: Yes
Joel: It's a portion in the way we actually read DNS starting with a dot and
it's coming there after is that way that's what you're saying?

Dino: it's a DNS pre-fit and the reason we call it a DNS prefix is because it's
a DNS name and then we will prefix the modulus index to it I'll get to it on
the next slide.

Joel: The type that's common is the DNS suffix.
Dino :This is true.

Joel: it's not too limited right
Dino: it's a domain name right it's a domain zone

Joel: Because I've run into people who think you can do other things in DNS
that really don't work well.

Dino: The statement is technically accurate because the map server set is a
prefix to a DNS suffix so it is correct okay stay tuned. just hold on I know
you're anxious Joel… Joel: does the hash include the prefix link? You show map
register with hashes but the lookup doesn't know what the prefix length we
had…. Dino: we added something in the latest draft called a hash mask and hash
mask are high order bits that are common between the lookup and the
registration. Joel: Now some have a system-wide hash mask that could be
advertised that everybody knows somehow and everybody uses for their
registration hash. For their lookup hash and all registrations will have to be 
longer Dino:  in cases where you're using 1 /128 and slew of  / 32 s like the
XTR are co-located with the host and it's one in the same and you could use the
entire length if you know that everybody's registering / 32s. Joel:  yeah yeah
you can use a / 32 of ipv4 but if some people are using / 24 you better not do
the hash on. Dino: Absolutely. We're finding most of the list use cases now are
being put very close to the host not even one hop away but either inside the
container or the hypervisor so it's supporting a per host sort of thing because
people want the mobility and therefore well you know Joel: You're using it for
mobility I get that but that’s not the only use case we are claiming it's
applicable. Dino:  absolutely that's why we have the hash mask Joel: Okay ….
Joel: so the collorary is that if you lose thus though all of these servers
which are taking care of a particular modulus nobody can register for anything
that hashes to that and nobody can look up anything to have that hashes to
that. Dino:  I'm just like in today's mapping system too if all map servers are
if all map servers are down today the map requests go through DDT they come
down to those they black hole. Joel:  Currently this is there's a relationship
between the map server providers and the customers who are making use of them
there's somebody to ask Dino: Yes Joel: In this system there is a much looser
relationship yeah that's true and that's not a fatal flaw I'm not saying that
we need to be aware of what the limitations are. Dino: yeah you know in the DDT
model was great because we understood bgp peering and how agreements are
between different organizations and but that still complicates things now these
things could be run loosely coupled but you have to you know you as a mapping
service provider have to know that sorry that's not my hash index you have to
go to my competitor to figure out the problem. Discussions: Luigi: I have a
couple of clarification questions I mean don't you have here a huge service
discovery problem at the beginning if you have to know to whom you can talk to?
Dino: No,  the whole point is you can figure the suffix and once register you
once you want to send a register you hash it and that construction of the DNS
name is allowing you to do that resource discovery. Luigi: Yes that this leads
me to the second question you started the motivation telling if Katerina comes
and wipes out every connection to XTRs. Magically the DNS is still working. You
have a dependency. Dino: You run a local DNS in that case… Luigi: I don't have
access to the mapping say that anymore any of it do you rely on on another
infrastructure and if you lose both. Dino: You're relying on a protocol not a
global infrastructure today when you bring up containers a container system
that's completely isolated you can use DNS names because it implements its own
version of DNS. Luigi:  right it's only talking about the devices not
containers Dino: I'm talking about the same thing - same doesn't matter Albert:
Go to slide number 12 so I understand better the how this work. Okay so what
you do is so when you come from app requests your hash and then out of the hash
you know the name the DNS name over which to look up.  Then you have the IP of
the map server to query right? So the so you are trusting the DNS you are
basically are trusting the DNS for authentication? Dino: Right you're using
another level of indirection by using the DNS naming system to give you these a
records which are IP addresses of map servers. Albert: Okay Dino: These could
be host entries and they can be statically configured in your configuration but
if they're statically configured then you don't have that that dynamic resource
discovery thing Colin: Just to add a point to that - I mean part of the
infrastructural design of this is actually to use some forms of distributed
letters so the domain name distributed ledger or kind of a more shared
cryptographic database where the trust of it comes by the resource input
required to create it so you can do is key value lookups as far as DNS lookups
or anything associated with that in that ledger it's also that it can be
self-contained so the ledger can also help maintain those trustable I guess
aspects but you know the mathematics and resource in. Joel: either either we
need to say that or we need to not be dependent on it in the draft I mean yeah
of course not well you can make it work with a ledger we've we've done this
before of we can make it work with this or that or the other thing not
criticizing you I'm not objecting to use a ledger but we need to be clear in
the draft yeah about what we're requiring Dino didn't say one word in his
presentation about a distributed look Colin: I agree on this this specific
draft was more so getting the infrastructural components of how the distributed
Mapping system work all these other little intricacies as far as like DNS or a
blotch and everything else are kind of I guess secondary to that but if we I
guess we could maybe do some modifications so it includes some distributed
ledger in there Joel: if you want to I mean I actually would prefer that we
keep our technology separate and didn't have a components but that's a personal
prejudice not a chairs preference Dino: yeah yeah so yeah you want to keep
these things decoupled but if they can provide value to each other that's good
but we have to also be concerned about circular dependencies - Distributed
Geo-Spatial LISP Blackboard for Automotive - draft-barkai-lisp-nexagon-00.txt
  15 Minutes (Cumulative Time: 65 Minutes)
  Sharon Barkai

Joel: before you go on I just want to make sure I've understood what you just
said because if I'm seeing something probably other people are wondering what
this looks like not Lisp terms for the moment. You created a database indexed
by an ID per tile and you're storing in the database the reports from every car
that has a meaningful report about this tile presumably with some currency so
you don't store relevant data. Then anybody who's interested in this set of
tiles subscribes to it so presumably as the car moves forward it subscribes to
the set of tiles that correspond to in front of it in the road you're using the
list mechanisms as the mechanism for registering that you have information
putting information in subscribe the list subscribed mechanism is a way of
getting the information out of this database it's not a paraphrase oh Sharon: 
the mapping system is used so I can talk to the right tile because this is very
geospatial… Joel: Conceptually, it's not really a server per tile but that's
conceptually a server per tile so when you do the EID lookup you get the name
the address of the server which is responsible for that data or the database
key. Sharon: Exactly Joel: Does not matter what your granularity of server is
the Eid lookup gives me who I should talk to. ???: who does the look up of the
EID? GPS is not really precise so normally how do I know in the same pitch tile
and located this is about three on relation between our antennas whatever. Then
the description of the identifer of a tile is it's like mapping. Is it like an
index in a database? so how do we get? Sharon:  That's the good question so in
order to publish an annotation, I have to be 1 meter accurate but GPS is not.
So but through machine vision which can be used for localization to better snap
to set and give me the 1 meter. So to publish I need very good technology.  To
subscribe, that's not the case I can be just a normal navigation app and when I
go into a cell I need to get a dump of the next 20 seconds.  So I need to get a
heads up and then I can locate myself but then what were the hazard is on the
map. I will let the navigation or whatever correct the GPS as best it can but
the hazard position on the map is correct . Joel: well so that would seem to
have the risk that if my if I'm the driver who's you using the data if I'm on
the service road for the highway and the highway is congested. I may get the
report that there is congestion in front of me when there isn't now if it's
only viewed as informative that's probably not fatal but if I get told it's
clear in front of me because it thinks I'm on the side road when I'm actually
on the highway that could be a serious problem because I won't react in
advance. Sharon:  The goal of the blackboard okay is to communicate where is
the congestion? \The responsibility of the client is to use the best
information. ???: we always had the problem of predicting free roaming so
predicting where I'm heading for so it's there some idealist if I have all
their hexagons and I know I'm going on the street.  I may be like me I'm from
Germany I'm going 280 kilometers per hours so it's their way to pre-roam that I
can already encapsulate to the next four seconds. Sharon:  So your client is
supposed to prefetch your next 20 seconds. so in a in town it's probably the
next block I'm gonna turn who is crossing the road which I cannot see well
because it's raining things like that.  It is up to you to prefetch the cells
that you're going to get into ???: it's pretty cool okay Padma: I just had one
question so do you have some kind of reputation because if you have multiple
cars or actually giving different information. Sharon: Absolutely. You publish
and you correct what you see because of your in-car AI then when you publish
your sum up and correct different annotations from different car it. Joel:
strikes me I probably contributed to this we're diving into a lot of details
navigation systems information collection systems which are all related to
either the underlying database or to the application on the car navigating car
I think we because we're good on what we wanted to give some other people time
we should focus on it this is being used for this it's really tempting we're
all engineers we want to go refine all the rest of it and Sharon would
appreciate the feedback but we have a focus here. Sri Gundavalli:  I think it's
a great work thanks for that. So let us take the case of a pedestrian walking
down the street how exactly would that be used? How do I subscribe to that
event. Sharon – simple dashcam and …of which are in their future who else this
car is may also subscribe reflect yellow so maybe one more really cool … Sri:
How does it you know? We're trying or does the same thing using Date Safety
Message data so how does that compare this actually I'm just curious? Sharon:
What we did is we took three standards okay h3 Liz and BDD which Berkeley deep
drive guys… Luigi: I'm sorry to interrupt you. You take it offline okay. Colin,
you have a clarification ? Colin: Quick question, yeah I was just going with
the question if you want to do a server for granular cell or you know I mean as
we were discussing earlier but I was wondering what the opposition having it be
kind of more at localized mesh network be because you saw latency issues and
you have the mobility issues solved with natural with Lisp so there's any
opposition of that. Sharon : Local real mesh is not feasible because doesn't
turn around corner. So you need anyway the tower. So it's anyway indirection.
Colin: okay - Overflow Time/ Discussion
  25 Minutes (Cumulative Time: 90 Minutes)
LISP Anonymity -  draft-ietf-lisp-eid-anonymity-06  10 Minutes
Padma Pillay-Esnault

Padma : in version 5 and the latest change we made is a very small change just
for a clarification. …. Request for WGLC – Pretty stable. Fabio: I want to make
a comment on the last call and please very friendly I mean many of us have been
incredibly busy in addressing the RFC Bis review process now the SEC is being
added and really that is sucking out all of the air from the room. I mean I
honestly didn't have time to do the proper review of this document and I will
not have time for the next three months. I suspect… So my suggestion is really
can we wait one cycle so that you know we can focus all the energy of the group
into you know trying to push this thing through and then going forward. Let me
add one more thing so one nice effect of this is pain will be going through is
that now there are at least a couple of guys in the second year Ben and Eric
that are knowledgeable of LISP. So I think this in time will come back because
they now understand well LISP protocol and they have clearly a very security
ever strong security background so I think that if we take a little more time
we we can you know focus more energy on this one. Joel: Frankly I would not
have Deborah to handle anything that was not necessary for getting us to PS
until we have finished with the iesg on the PS ones because…. Padma: So I hear
you guys and actually I want to say thanks for bulldozing the way for us later
but we actually were going to ask for last call in Bangkok on this document. I
held it one cycle by myself so this is the second cycle we're holding it. So I
want to get this priority when you come back though that would be the only
thing I would ask. Fabio: I know I know Padma : And for Predictive routing as
well. Fabio: I understand we have been in that situation for a few cycles.
Luigi: I would suggest we proceeded in this way so we wait for the this
document and Lisp sec to go through and then we start to move forward the other
documents. It  doesn't mean we have to wait until Montreal hopefully. Padma:
Yeah Luigi: hopefully up at the same time if we hold on a little bit it means
as well documents like the Yang model we will hold on as well we can work on
the Yang Doctor. We will ask,  it depends on the energy of the working group. I
don't want to burden anybody but just the we agree on the how to move forward
as a working group. Fabio: So if there is one lesson we have learned from all
of these is that all the proper review we will not be able to do now within the
working group, will come back with an exponential factor. Padma: Honestly the
reason why I was kind of I added it last minute it's just I don't want to lose
a second cycle without actually doing an update. I think it's important that we
do the update so that you guys know that these are documents are waiting in the
queue. Dino: Fabio there's no protocol changes to this at all and basically a
host today can choose any idea wants to and the xtr learns about it the xtr has
no idea if it's a random number that's being generated an allocated address
from iana or the registries or whatever so i mean it does specify that this EID
could be a crypto EID, a hash of a public key and that stuff's that more
complicated stuff is put in another document that has runs its own course but
this is just simply saying that a host could use any Eid at once and change it
as much as it wants all the LISP machinery doesn't know this is going on it's
just a configuration sort of thing so it's a really trivial to review right.
Now the security area will probably say is frequently changing Eid secured
enough or do they need to be you know but those are my work in there correction
Luigi: We have two minutes what I propose what if you want to gain time what I
propose is what if we ask for a security review right away of the document so
that we are sure that once we go over the last call we don't have any issue
afterwards so life is like the Yang model we try to gain time before we go for
the last. Dino: It won't work because it will be dependent on the ID mobility
draft in the ECDSA. Luigi: What you are saying we have still to wait anyway
because there is an interdependence between documents. Yeah that's what you
just said yes ? Dino: I am trying to tell you what I mean I know I don't I'm
trying to anticipate with the sector guys with it would say and if they just
think that ephemeral addresses and changing things frequently is sufficient for
these class of applications then there is no dependency on those drafts. If
they want something stronger than… Luigi: The most reasonable way to move
forward in my opinion because of these comments is we asked for a security
review so that we're sure that once we move it to the year the is she we don't
get stuck in in endless their discussion about a security  like we did with the
bis documents Albert: I understand everyone's concerns and willing to move
forward . The first thing is that don't assume what a security review is. You
said it will be easy … we don't know..  honestly we get some experience Luigi :
From experience … Padma:  I would say agree with you guys about waiting so let
me do that Albert: When we have a conversation with them LuigiL I have also
pressures from is also the working group at this point let us not give them
more reason to Luigi: About the these last three minutes what I gather is we
will move the document further forward in the sense that I will ask for that
security review that we will not get stuck afterwards. At the same time we
don't go for WGLC right away. Fabio: By security review, you mean involving
something someone from the secdir. Now these guys have full.  Their basket is
full of LISP requests, we don't want to add to that buffer I mean honestly
please Luigi: It is not up to me to deal with the agenda of the SEC dir.
Deborah:  I mean actually you're not gonna ask Benjamin Luigi:  no no no no
it's for early Directorate review Deborah: As we all know that's no guarantee
we can find it it's good and yeah it shows that you're interested to get their
feedback. Luigi:  We don't have to be forcibly and guys doesn't mean we go to
Ben. Little bit I think a little bit and wouldn't be a bad idea if we give time
to other people to get accustomed it with LISP so that they can review the
security part. I mean we cannot rely only on Ben and Eric otherwise we will be
always stuck under on the pipeline of these two guys. Fabio: Has this been
presented to security? It may me help involving people from outside this
community. Luigi: exactly and not only on this document Erik Nordmark: I wrote
a draft called privacy issues in ID locator system a year ago I don't see it
cited in this document it might be useful… LISP Uberlay -
draft-moreno-lisp-uberlay-01 10 Minutes Alberto Rodriguez Natal Not enough time…