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

[Stephen Farrell <[e-mail]>]

On 21/11/16 23:50, Dino Farinacci wrote:
> 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.

We're talking past one another. Each time you re-assure me
that there's nothing to worry about but don't say how to
deal with the case about which I'm asking. Maybe if someone
else were to try respond that'd get us out of that loop? :-)

> 
>>>> 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.

Had you pointed at that draft before? If so, I guess I
missed it (and sorry about that). However, BCP160 is
*still* not a useful reference there or here, and I was
not suggesting referring to that draft (of whose existence
I wasn't aware;-). If your argument is that the privacy
considerations related to this section of the lcaf draft
are dealt with in that lisp-geo draft, then yes I would
argue that it needs to be referred to, but I think it'd
be better to call out here that location information is
privacy sensitive and ought not be used unless it's needed.
(And that latter is not stated in the lisp-geo draft.)

> 
>>>> 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.

Hmm, another draft of whose existence I wasn't aware.

> 
>> 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.

I guess I'd argue that that approach has not worked well
in terms of covering or even understanding the security
and privacy issues that likely arise, if one is to judge
from this document and it's references, which is what I'm
asked to do.

> 
>>>> 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?
> ;-)

Does it support long-term symmetric keys stored in the
format defined here? If so, then more text on that is
needed somewhere. If the lcaf format is only for public
keys, then it's ok already.


> 
>> 
>>>>>> - 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.

Ditto. Are we talking past one another again? I don't
think I've seen any response to the repeated comment
that BCP160 is not useful here.

> 
>>>> 
>>>>>> - 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.

We don't need a mediator. If the WG chairs or AD say that the
WG want all this text, then I'll move to an abstain once we've
sorted the other discuss points.

S.


> 
> Thanks, Dino
>