Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS)
> 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? :-) The chairs are going to respond so we can get out of this loop. > 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.) I can certainly refer to it as well as the NAT-traversal draft. But want the chairs to give me their approval. > 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. There is no long-term key storage. The format is used only in message exchange. > 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. Okay, sounds good. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS)
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 a
Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS)
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. An
Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS)
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.
>>
Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS)
> 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.
>> [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.
>
>>
>>> - 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):
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.
>
>>> - 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
Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS)
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 Sign
Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS)
> 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.
> - 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.
> - 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.
> - 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.
> - 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.
> - 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.
> - Section 6: There are security considerations. See
> above.
I added text per Ben’s comments.
Thanks,
Dino
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-lcaf-17: (with DISCUSS)
> 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.
> - 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.
> - 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.
> - 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.
> - 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.
> - 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.
> - Section 6: There are security considerations. See
> above.
I added text per Ben’s comments.
Thanks,
Dino
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
