Hi Dave, Thanks for your edits. I'm currently on holiday with only a mobile phone (which works only when the wind blows right) so I'll give comments when i get back to civilization on Tues. Hopefully we can have some group discussion in 6lo if time permits.
Regards, Kerry On Wed, Jul 6, 2016 at 9:22 PM, Dave Thaler <[email protected]> wrote: > Ok, I just posted an update in which I tried to take Kerry's feedback into > account. > > Some notes below about what I did, but see the diffs for details. > > > From: Dave Thaler > > Sent: Tuesday, July 5, 2016 6:22 PM > > To: [email protected]; Kerry Lynn <[email protected]> > > Subject: RE: [6lo] RESEND: Reveiw of > draft-ietf-6lo-privacy-considerations-00 > > > > I'm working on updating this now. > > > > Kerry Lynn wrote: > > > To begin finalizing the Security Considerations section of > > > draft-ietf-6lo- 6lobac, i thought it would be useful to re-read and > > > offer my review of draft-ietf-6lo-privacy-considerations-00. > > > > Thanks for the feedback! > > > > > First, some general comments: > > > > > > - I find the document clear and understandable, as per Dave's usual. > > > > > > - As this document pertains to constrained devices, I think some of > > > the concerns expressed in other fora (e.g. leaking link-local address > > > in email headers) don't apply here. > > > > Yes they do. Just because a device is resource constrained doesn't mean > it > > can't leak link-local addresses. In fact we have plenty of evidence > that > > leaking link-local addresses can easily happen by accident (or programmer > > neglect), in any number of Internet protocols (DNS, SIP, SMTP, etc.) > > I did make changes in a number of places, especially any discussion around > address scans, to make the discussion specific to routable addresses. > I put in some text to state my points as well, but the primary focus of > address scan text (and thus the larger number of entropy bits) is for > routable addresses, which I hope is clear in the text now. > > > > - I think it would be helpful to clearly divide the document according > > > to threats posed by off-link vs on-link adversaries. In the off-link > > > case, we are dealing only with routable addresses and information that > > > is at L3 or higher. This class of threats applies to all hosts, > including 6lo. > > > Using a random 60+ bit IID (per prefix?) will mitigate all threats > > > discussed in draft-ietf-6man-ipv6-address-generation-privacy except > > > correlation of activity over time. > > > > Ok, will see what I can do. > > I made textual changes, but not organizational changes (table of contents > remains the same) since some points do not clearly delineate that way. > So hopefully it's clear enough in each paragraph now. > > > > > > In the on-link case, are we only concerned with threats that apply to > > > (wireless) data links that are susceptible to eavesdropping, or must > > > we also be concerned with intruders in the wiring closet? > > > > If the link is a multi-access link, and one of the devices can be > compromised, > > then it can potentially be used to eavesdrop on communication between two > > other entities on the link. So it's not wired vs wireless so much as > point-to- > > point vs multi-access. > > I added a minor point about NBMA but the main focus in the text is, I hope, > consistent with I think what your main point is. > > > > In any event, this > > > class of threats would seem to exclude address scanning (which is > > > trivial if an attacker has access to the local link traffic). > > > > Depends on the link-layer protocol. Some link layers (e.g., ones that > don't > > support multicast/broadcast) don't use ND and so address scanning may > still > > be an issue. > > > > > - If address scanning is eliminated as a concern (as in cases where it > > > cannot be prevented), then arguments about "enough entropy" do not > > > apply and locally assigned short addresses have their rightful place > > > in forming link-local IIDs. The side effect of this is to enable > > > maximally efficient RFC 6282 compression for link-local traffic. > > > > I think you're still assuming that link-local addresses can never leak > via higher > > layer protocols, whereas we know they can. So link-local addresses are > still > > an issue for the off-link case. Even though an attacker can't use them > to > > communicate with the constrained device, they can still result in privacy > > vulnerabilities. > > As noted earlier, I updated the text so that address scans and the larger > amount of entropy being mainly for routable addresses. > > > > > > - Concerns about correlation over time may not apply to certain > > > classes of devices (fixed servers) or applications (e.g. building > > > automation, where associating link-layer address with location is a > > > feature, not a bug). In some cases, it may simply be impractical to > > > change link-layer address on a frequent basis (e.g. it is common in > > > the case of MS/TP nodes to set the L2 address via DIP switches). > > > > Right, in cases like fixed services that might even be resolvable via > DNS or > > some other mechanism, public addresses are used and privacy of such > > addresses is not an issue. However, the point is that that IETF should > not > > design protocols that can ONLY support such cases. (The draft is a bit > softer > > than saying that though, it just says that your Privacy Considerations > section > > needs to have a discussion of the issues, and then the IETF community and > > the IESG can decide whether there is IETF consensus on it.) > > > > > - It has been suggested that ND might be eliminated in some cases to > > > further increase bandwidth efficiency. (For example, in cases where a > > > locally-assigned short identifier has been assigned at L2 and is then > > > used to form an IID, ND is redundant.) > > > > Well there's multiple parts of "ND". The NUD part is still relevant in > all > > cases. The Address Resolution part can be eliminated in some cases (and > > indeed it's up to each link-layer protocol to say how Address Resolution > is > > done, which defaults to normal ND if you say nothing). > > > > > AFAIK, there hasn't been any > > > discussion about how to tell the difference between L2-derived and > > > "random" IIDs. We might identify L2-derived IIDs as those containing > > > the 0xFFFE pattern in the middle, or not having the 0xFFFE pattern but > > > having the U/L bit = 0 in the IID. This would exclude these patterns > > > from valid privacy IIDs and result in a maximum entropy of ~63 bits. > > > > One cannot positively tell the difference simply by looking at an > address. > > One needs additional information to say for sure, because ultimately > it's up > > to each link (or maybe even finer granularity). But for things like > address-to- > > string conversion ("pretty-printing") purposes, some implementations > (like > > Windows) do have a random generation algorithm that avoids colliding with > > the patterns you mention, and do result in a max entropy of ~63 bits. > > So far I don't see any reason the draft needs to discuss this point > though. > > > > > Now on to specifics: > > > > > > - In section 2, I think the analysis pertains to the lifetime of a > > > given link so the wording "average lifetime of a device" should > > > instead be "average lifetime of a link". > > > > Right, will fix (it's correct in the equation at top of page 4 but then > the text > > below it wasn't consistent with it). > > Done. > > > > > > It is worth noting that CoAP servers do not have a "stealth mode". > > > According to [RFC7252] a CoAP server MUST respond to an empty > > > Confirmable message with a Reset message. > > > > It's not worth noting because the same could be said for TCP or HTTP or > > ICMP. The "stealth mode" is a property of a host firewall in front of > it but on > > the same device. Section 5 of RFC 7288 (which the draft > > references) already contains a discussion of this point, and just uses > TCP and > > ICMP as examples, and that text equally applies to COAP. > > Updated text to discuss firewalls and reword to make it clearer that it's > about dropping unsolicited inbound traffic before it ever reaches > the TCP/ICMP/COAP/whatever layer, and also mentioned network firewalls > in front of the subnet, that have the same effect. > > > > > > - In section 3, MS/TP has 7 or 64 bits (since L2 addresses must be in > > > the range 0 - 127). > > > > Thanks, will fix. > > Fixed. > > > > > > - Section 3.1 seems to alternately switch between discussing > > > link-layer addresses and IIDs formed from those addresses. Perhaps > > > consistent use of "link identifier" and "interface identifier" would > > > help disambiguate the meaning. > > > > Ok, will see what I can do. > > Changed. > > > > > > EUI-64 and EUI-48 are well-defined terms (trademarked in fact, and > > > this should be noted in the document). > > > > Why should it be noted? Can you point me to a 6man RFC (since many 6man > > RFCs mention EUI-64 and EUI-48) that notes that the term is > trademarked? Is > > there an RFC style guide directive on such matters? > > > > > An EUI-64 may have 40, 36, or > > > 28 bits of entropy, while an EUI-48 may have 24, 20, or 12 bits, none > > > of which meet the standard of "at least 46 bits". > > > > When the OUI is unknown, the lack of such knowledge provides a few more > > bits of entropy since the attacker has to at least try any well-known > OUI's and > > do a search within each one. For example, if there's 64+ possible OUI's > in > > use, that's around 6 more bits of entropy. An off-link attacker cannot, > > without additional information, know what the link type is and so has to > try > > OUIs without being able to narrow it down to OUI's for that link type. > > I also reduced the number of occurrences of the "46 bits" number, since > that's > just an example for links that can last 8 years or more. (Many 6lo links > last > for far less time than that, so we shouldn't over-index on the number 46, > it's just an example. The key point is to derive the number from the max > expected link lifetime.) > > > > > > I'm not sure it's > > > accurate to use "randomized IEEE identifiers", unless this refers to > > > locally-assigned MAC addresses with the U/L bit = 1, in which case we > > > might want to reference an appropriate IEEE 802 or ISO standard. > > > > Random MAC addresses was the intent, but "MAC" as a term only applies to > > specific link types. Maybe "randomized link-layer addresses" is a better > > term, so I'll use that. > > Done > > > > > > - In Section 4, first bullet, it should be enough to indicate that > > > privacy IIDs are RECOMMENDED for routable addresses. (Is there a case > > > where a privacy IID is less than ~63 bits of entropy?) > > > > Such a recommendation may be too strong for some cases (it would indeed > > be sufficient, but not necessary). For example, if the link lifetime is > usually > > <1 second, then privacy IIDs might be overkill. The point of the first > bullet is > > to say that an IP-over-Foo doc should contain such a discussion. > However, > > perhaps your point is that it could say that using privacy addresses is > one easy > > way to meet the requirement. > > > > That is, I don't believe there is 6lo WG consensus for stating that > privacy IIDs > > are RECOMMENDED for routable addresses. > > > > > This section > > > should also discuss options for providing privacy IIDs via DHCPv6 > > > (M=1 in RA). > > > > I have no problem adding such a reference. The point is to say what > privacy > > considerations need to be addressed in a doc, rather than details of > *how* > > to address them, in order to leave maximum freedom. > > But providing examples as informative references as you suggest is a good > > thing. > > I checked and there is no reference (RFC or draft) as far as anyone I > asked knows. > So I didn't mention DHCPv6 in this document, I left it for 6man documents > to discuss since it's not specific to 6lo. > > > > > > Second bullet - as I've indicated above, there's no such thing as a > > > "random" EUI-64 or EUI-48. We can probably use "randomized MAC > > > addresses". I need to go back and re-read [RFC7136] to see if it > > > makes sense to specify U/L bit in this context. > > > > Agreed, will use "randomized link-layer addresses". > > Done > > > > > > Third bullet - this advice should not apply to link-local IIDs. Any > > > attacker wishing to find "hits" just needs to fire up a sniffer. > > > > Disagree as noted above. It applies due to off-link leakage. > > (And the IP-over-Foo layer should not make assumptions about what upper- > > layer protocols do.) The risk might be smaller, and hence it might apply > > "less", but it still applies. > > > > > Fourth bullet - this advice should not apply to link-local IIDs for > > > devices or applications where correlation of activities over time is > not a > > concern. > > > > Same answer. The risk might be smaller and hence it might apply > "less", but > > it still applies. > > Also the whole section is under the heading of "recommendations" not > "requirements", so they're already implied SHOULD's rather than MUST's > in that sense. But either way, the security/privacy text in a draft > should address > the issue, whatever the answer is. > > > > > Again the main point of this draft is not to say what one MUST or MUST > NOT > > do (or rather *how* one MUST or MUST NOT solve some privacy issue), but > > rather what issues need to be addressed in a doc, and some > > recommendations > > ("shoulds") on good ways to address them. So the fact that there's > still a risk > > means there's still a need for text to address them or convincingly (to > the > > IETF community and to the IESG) explain why some issue doesn't apply to a > > particular IP-over-foo mechanism. > > > > Thanks again for the review, > > Dave >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
