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

From: Stephen Farrell <[email-masked]>
Date: Tue, 8 Nov 2016 00:35:25 +0000

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
>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 Nov 2016 08:42:01 -0800

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

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

> you're using that term differently from the normal crypto

We are using it from an “address” perspective. Has nothing to do with security. ;-)

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

> and to recommend to avoid the pitfalls we know exist.

It is here (page 35-36 in -20):

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.

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

> maybe this warning is needed. But if not, yes, it'd not be needed.

We don’t know how ot clarify yet. We can in the future.

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

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

> 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

So are you good with my response?

> reference here, in terms of being useful to implementers.

See Security Considerations section.

> and as they are better understood from the security/privacy

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

Dino

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 21 Nov 2016 22:49:22 +0000

Hi Dino,

On 08/11/16 16:42, Dino Farinacci wrote:
> 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.

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

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

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.

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

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)
>>> 
>> 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
> 
>> seeing that go by in the discussion of lisp-crypto but I may be
>> forgetting.
> 

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

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

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 21 Nov 2016 15:50:23 -0800

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

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

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

> of exposing information about specific hosts behind a NAT as

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

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

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

> complex manner that is not IMO likely to be useful to

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

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

> until good specification text exists.

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

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

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Nov 2016 10:20:47 +0000

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

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

>>>> 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.
>>> 
>> 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.
>>> 
>>>>  maybe this warning is needed. But if not, yes, it'd not be
>>>> needed. Can you clarify?
>>> 
>> 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?
> 

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

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.
>>>>> 
>>>> Yeah but this seems like throwing the kitchen-sink and all at
>>>> the mapping system, which seems to me to be a recipe for
>>>> 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.
> 
> 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?
> 

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.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Nov 2016 10:17:24 -0800

> else were to try respond that'd get us out of that loop? :-)

The chairs are going to respond so we can get out of this loop.

> (And that latter is not stated in the lisp-geo draft.)

I can certainly refer to it as well as the NAT-traversal draft. But want the chairs to give me their approval.

> keys, then it's ok already.

There is no long-term key storage. The format is used only in message exchange.

> sorted the other discuss points.

Okay, sounds good.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 28 Nov 2016 11:39:47 -0800

Thanks Stephen for your careful review. I’ve updated the draft to clarify your concerns. Let me know if there is any remaining item preventing clearing of your discuss. And thanks Deborah for your contributions.

You can find a new submitted draft-ietf-lisp-lcaf-22 and a diff file enclosed.

Thanks again,
Dino

> On Nov 22, 2016, at 10:17 AM, Dino Farinacci <[email-masked]> wrote:
>