Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS)

[Dino Farinacci <[e-mail]>]

Snipping text a bit to make email more readable by third-parties.

>> 
>> It is a canonical form for all new types of addresses or information
>> we want to add in the future.
> 
> So maybe I'm being thick but I still don't see how one
> reliably orders things when the values are URIs that have
> paths with varying case, e.g. URI1="https://example.com/Foo/"
> and URI2="https://Example.com:443/foo". Can you explain how one
> ensures that all encoders produce the same order for the above
> or that it doesn't matter or that one never hits that case with
> two URIs being put in order?

The ordering is only needed for RLOC addresses. Addresses that are used for encapsulation. When a distinguished-name is used for an RLOC, it is ancillary data.

I think it is a whole lot simpler then they way you are generally thinking about it.

>>> I don't see the recommendation to not use/send/store this unless
>>> needed nor anything other than a generic warning to go read BCP160,
>>> which I'm not at all sure is something that would help LISP
>>> implementers. Do you really think they'll buy into the geopriv
>>> architecture? I don't really.
>>> 
>>> I'd argue that it'd be better to explain the issues here and to
>>> recommend to avoid the pitfalls we know exist.
>> 
>> It is here (page 35-36 in -20):
> 
> I don't see that in -21. I see text saying "there might be
> some privacy issues... maybe." The discuss point asked that
> it state that this information can be privacy sensitive and
> hence ought not be sent or stored unless it's needed. I also
> don't recall an argument that that kind of text would be wrong.

Based on your comment, the details were put in draft-farinacci-lisp-geo-02. I am not sure we should reference this draft in the LCAF draft since it is not a working group document. Others can comment.

>>> Are there no LISP use-cases where the Private ETR RLOC Address or 
>>> RTR RLOC Address could map to a host behind a NAT e.g. in my home?
>> 
>> Yes, kinda. But there is no need for the private-RLOC right now and
>> we are working that out in the NAT-traversal individual submission
>> draft.
>> 
>>> If there are (and there seem to be many LISP use-cases:-) then 
>>> maybe this warning is needed. But if not, yes, it'd not be needed. 
>>> Can you clarify?
>> 
>> We don’t know how ot clarify yet. We can in the future.
> 
> Why can't you fix this now? Why can't you say to not use this
> in any cases that might be privacy sensitive and give the example
> of exposing information about specific hosts behind a NAT as
> an example?

The NAT-traversal document says that, draft-ermagan-lisp-nat-traversal-11.

> I don't see why it's better to ignore problems like that, as
> we do know that when we ignore such things, they do come back
> to bite us in the ass later.

We are not ignoring problems at all. We are spec’ing them in full detail in the use-case documents where there is more supporting details and context to make these raised issues more understandable.

We have this document to defined types that we know we want to use in the future and have some level of detail on what the content to the messages should be but don’t have the detailed use-cases for ALL of them quite yet. In fact, this process has worked very well for us, because we did predict well and new use-cases have simply said “Use RLE as defined in the LCAF draft” or “use ELP as defined in the LCAF draft”. And there is many use-case drafts that point to this LCAF draft.

>>> LISP-DDT.
>> 
>>> seeing that go by in the discussion of lisp-crypto but I may be
>>> forgetting.
>> 
>> So are you good with my response?
> 
> I just had a look back at lisp-crypto and it seems I was remembering
> wrong and that doesn't support symmetric keys. Assuming I've not
> gotten that wrong again, this one is good:-)

lisp-crypto supports symmetric keys. And the reason is because the SAAG suggested we do so for performance in the data-plane. Remember?  ;-)

> 
>>>>> - 4.10.2: The same privacy issues apply here as for 4.3 and
>>>>> 4.4, if the MAC address maps to e.g.  a portable device carried
>>>>> by a person.
>>>> 
>>>> In this case, the MAC address can be a host/person. I put a
>>>> refernece to the Security Considersations section that
>>>> references RFC6280/BCP160.
>>> 
>>> See above WRT BCP160. I'm really not sure it's a great reference
>>> here, in terms of being useful to implementers.
>> 
>> See Security Considerations section.
> 
> I did. That text didn't help. Just referring to BCP160 is
> not good enough here IMO, you need some text to call out
> the actual issue, which is not called out clearly in that
> BCP, which deals with complex location issues in a pretty
> complex manner that is not IMO likely to be useful to
> LISP implementers.

See comment above about draft-farinacci-lisp-geo-02.

>>> 
>>>>> - 4.10.3 and all of section 5: What are these for?  I don't see
>>>>> the sense in defining these if there is no well defined way to
>>>>> use them. Any of these might have undesirable security and/or
>>>>> privacy characteristics.
>>>> 
>>>> We have use-cases for them. And they are being documented in
>>>> both other working group and individual contributed drafts.
>>> 
>>> Yeah but this seems like throwing the kitchen-sink and all at the
>>> mapping system, which seems to me to be a recipe for security and
>>> privacy failures. With the level of detail now available, how could
>>> we know for sure if I'm right or not? Wouldn't it be better to
>>> define these as they are needed and as they are better understood
>>> from the security/privacy POV?
>> 
>> They are needed and we are experimenting with them now. We can apply
>> updates when we learn more. We still do rough concensus and running
>> code.  ;-)
> 
> If more than one person writes code then they won't interop
> based on this low quality text. Running code does not mean

Someone just doesn’t look at this draft and say I want to implement the RLE LCAF. They say I want to offer draft-farinacci-lisp-predictive-rlocs or draft-ietf-lisp-signal-free-multicast in my products, therefore to support either or both use-cases, I implement the RLE LCAF according to what those drafts say. It is very specific because I write code for my own designs (and sometimes it happens backwards to the specs are detailed and accurate).

> it's ok to just sketch out definitions of data structures.
> IMO almost all of section 5 would be better deleted from this
> until good specification text exists.

We have agreement from the working group to go this route.

> I don't see a way to resolve this point. If the WG insist on
> including types for badly defined structures then I'll just

You cannot take read this document in isolation. It is accompanyed with other drafts (sorry I keep repeating myself).

> end up as an abstain on this. Can the chairs or AD confirm
> that the WG really have consensus to include all of the
> stuff in section 5 at this level of (missing) detail?

Yes, we need a mediator if this email doesn’t convince you Stephen.

Thanks,
Dino