Hi Dino, On 08/11/16 16:42, Dino Farinacci wrote: >> Hi Dino, >> >> Apologies for the slow response... >> >> I checked the diff from -17 to -20 before replying. > > Great, thanks. Please ack based on if you agree with my responses > below. I didn’t see anything you said where I need another update. > But want your agreement first.
Hmm. I don't think I agree about another update not being
needed at all.
>
>>> [RFC6830] states RLOC records are sorted when encoded in control
>>> messages so the locator-set has consistent order across all xTRs
>>> for a given EID. The sort order is based on sort-key {afi, RLOC-
>>> address}. When an RLOC is LCAF encoded, the sort-key is {afi,
>>> LCAF- Type}. Therefore, when a locator-set has a mix of AFI
>>> records and LCAF records, they are ordered from smallest to
>>> largest AFI value.
>>
>> Sorry I'm not getting that. When I read "canonical" I take that to
>> mean that anyone given the items in any order can re-construct the
>> same set of octets. Are you defining some other format that doesn't
>> amount what I perceive as being a canonical form? (For background,
>> most canonicalisation that turns up in security relates to
>> signature/MAC inputs where you need to produce the exact same set
>> of bits.)
>
> The ordering is for the sole purpose of using reachability bits that
> are consistent among multiple ETRs that are registering the same RLOC
> set. Here is an example. Say we have two ETRs for a LISP site, their
> RLOCs are ETR1 and ETR2 and they are both registering an EID-prefix,
> we want the mapping to be:
>
> EID-prefix -> {ETR1, ETR2}
>
> And we want ETR1 to register the above mapping in the same order as
> ETR2. So we when the RLOC reachability bits are set for this RLOC-set
> (say 0x3), we know the low-order bit means we are advertisting the
> reachability-bit for ETR1, and the 0x2 bit is for ETR2.
>
> That is why we have a sort order. This is discussed in detail in
> RFC6830, and we are just waying here that if the RLOCs are
> accompanying with other data, that is defined by a specific LCAF
> encoding that the RLOC address are sorted.
>
>> If you don't need what I'd call a canonical form then maybe calling
>> it something else might be good, or explaining that you're using
>> that term differently from the normal crypto usage.
>
> We are using it from an “address” perspective. Has nothing to do with
> security. ;-)
>
>> If you do need (what I'd call) a canonical form, then I think more
>> work is still needed. (And that's tricky for URIs as there is no
>> general canonicalisation for those.)
>
> 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?
>
>>
>>>
>>>> - 4.3: I agree with Ben's comment. You ought include some text
>>>> here to the effect that this information can be privacy
>>>> senseitive and to recommend not sending or storing it in such
>>>> cases.
>>>
>>> I did that for the next revision.
>>
>> 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.
>
> 6. Security Considerations
>
> There are no security considerations for this specification. The
> security considerations are documented for the protocols that use
> LISP Canonical Addressing.
>
> The use of the Geo-Coordinates LCAF Type may raise physical privacy
> issues. Care should be taken when configuring the mapping system to
> use specific policy parameters so geo-location information is not
> returned gratuitously. It is recommended that any documents that
> specify the use of the Geo-Coordinates LCAF Type should consider the
> applicability of the BCP160 [RFC6280] for location-based privacy
> protection.
>
>>
>>>> - 4.4: there are also potential privacy issues here if this
>>>> could be used to identify traffic that is from one specific
>>>> host behind a NAT. A similar privacy warning should be
>>>> included.
>>>
>>> It does not identify any host.
>>
>> 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?
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.
>
>>
>>>> - 4.7: Sorry, when is key material sent in a message? How is
>>>> that protected? (Key ids are fine, but not key values)
>>>
>>> That is documented in the two use-case references.
>>
>> So for DDT, those are always public keys, right? And are part of
>> some PKI or equivalent. If so, those are fine.
>
> They are public keys and DDT, itself can be regarded as a PKI. But
> each parent transmit the public-key of the children it is referring.
> So it’s not a table lookup mechanism but an on-demand push.
>
>> But for lisp-crypto, if this can be a long term symmetric key, or a
>> derived shared secret then more needs to be said
>
> LISP-DDT-SEC is control-plane security, and lisp-crypto is data-plane
> security. They are not related and don’t depend on each other’s
> functionality.
>
>> I think. Or at least, we need the argument that storing such keys
>> is safe. Can you provide that? I don't recall
>
> We don’t store keys for lisp-crypto. We store public-keys for
> 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:-)
>
>>
>>>
>>>> - 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.
>
>>
>>>> - 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
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.
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
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?
Thanks,
S
>
> Dino
>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
