Hi Dino, Apologies for the slow response...
I checked the diff from -17 to -20 before replying.
On 14/10/16 14:21, Dino Farinacci wrote:
>> I basically support Alexey's discuss position and Ben's comment but
>> with a bit more detail below.
>
> Thanks for your comments Stephen.
>
>> - section 3: I don't see how you can produce a canonical order of
>> the LCAF encodings if two can contain e.g. the same values other
>> than different URLs, since there is no canonical way to order URLs
>> (or JSON structures etc.) without a lot more specification.
>
> We want to define an order so if an implementation parses, say Type
> 4, it can optimize to know that Types 1-3 will not come after Type 4.
> We can achieve that with this text:
>
> [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.)
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.
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.)
>
>> - 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.
>
>> - 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?
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?
>
>> - 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.
But for lisp-crypto, if this can be a long term symmetric
key, or a derived shared secret then more needs to be said
I think. Or at least, we need the argument that storing
such keys is safe. Can you provide that? I don't recall
seeing that go by in the discussion of lisp-crypto but I
may be forgetting.
>
>> - 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.
>
>> - 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?
Cheers,
S.
>
>> - Section 6: There are security considerations. See above.
>
> I added text per Ben’s comments.
>
> Thanks, Dino
>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
