IETF 102, Montreal, CA IRTF Open Meeting Tuesday July 17th, 2018 Morning Session I, 0930 - 1200 Notes by: Mat Ford IRTF Chair Opening Remarks: IRTF Overview and News Allison Mankin Allison's slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-irtfopen-allison-mankin-irtf-chair-opening-remarks-00 Allison drew attention to the success of IRTF the preceding day. Applied Networking Research Prize Winners Hijacking Bitcoin: Routing Attacks on Cryptocurrencies Maria Apostolaki, ETH Zürich, CH Maria's slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-irtfopen-maria-apostolaki-anrp-talk-hijacking-bitcoin-routing-attacks-on-cryptocurrencies-00 Q&A Cathy Aronson (CA): It's unlikely that an AS would have no customers, but you could also have an AS that does what the BCP says and filters what their customers announce. Maria Apostolaki (MA): By having direct peer connections we also avoid the passive attackers that are in the middle. Also need to think about creating incentives for ISPs to filter, but have to consider that we need to find those locations such that they are also close to bitcoin clients - don't have that many ASes that filter. CA: But they should be. MA: Yes, I agree. ?: Can you go back to the picture showing peering and interconnections for sabre, where there were three nodes. Do you assume that when the direct connection between relay 1 and relay2 is broken, traffic will go through relay3? MA: The point is that relays will compose a graph that is always connected. If one link is broken I want to transfer information by another one. ?: According to regular peering connections they will send traffic through upstream providers. Peering connections are exchanging routes that belong to themselves and their customer pool. Here you don't have a customer pool. Relay 1 and Relay 2 will not exchange prefixes that belong to Relay 3 otherwise it's a route leak. MA: The reason why peering links are needed is because nobody can advertise to Relay 2 for example the prefix of Relay 1 and be strictly more preferred. ?: Until they are directly connected. MA: Yes. This is why I need the relay network to be always connected because I have an alternative route that is composed of direct peering links among the relay nodes. ?: You are speaking about an overlay network that is built upon relays? MA: The relays are in the relay network, there is not an additional network on top of them. Do we agree that if the relay nodes are connected with peering links and at least k-connected, say 2-connected, that if we lose a peering link for any reason then information can still be exchanged via the links we have. ?: Only using some kind of proxy MA: It is a connected network - the proxy that you are describing is basically the alternative path ?: Peering links do not exchange routes that belong to other peers. There is a physical connection but there is no logical connection. Inside BGP there is no such route. But let's take this offline. Phil Hallam-Baker: I'm going to make myself unpopular - I'm not at all worried about attacks on crypto currencies - bitcoin is using as much electricity as Nigeria - bitcoin is an attack on our planet, an attack on our financial infrastructure - we need better attacks against bitcoin. The sooner we sink it the better. Don't think of this in the normal fashion of here's an attack, let's find a defence, make the attack better! MA: regarding environmental aspects, I agree - but this is not about blockchain it's a general problem. Shane Kerr (SK): have you thought about the financial model of how you maintain these sabre nodes? how do you expect to pay for this in the long run? MA: There are already relay nodes that everyone can connect to - they're mostly maintained by academics, or supported by academics, our intuition is that it would be nice if an ISP deployed it because it would prove that is in sucha position in the Internet that it can help bitcoin - it would be an advertisement. If we implemented the programmable switches they would already have them and then we just add the relay node. But I get your concern. SK: Have you looked at the possible impact of lightning networks on this? Lightning network is a change to the bitcoin model where instead of all peers connecting to all other peers there are lightning nodes which act as a kind of localised network. MA: Are you saying that we are centralising something that should be decentralised and that's bad? We don't want to replace the bitcoin network, just want to provide an alternative. SK: No that's not what i'm asking about - I think the model of how bitcoin is going to work in the future is changing - scaling problems with current network mean that in future transactions won't be broadcast across the entire network straight away - it has lower guarantees, but this is required for scaling - not sure how your attacks fit in there - whether more or less secure - and how sabre solution fits in here MA: Perioidic exchange of transactions is required for consensus right? When this happens if network is partitioned it would not be possible, so this applies. SK: I agree that it's always going to be a problem - maybe even worse in a lightning network scenario. Doug Montgomery (DM): You're relying on placement of various nodes that are topologically aware - do you address how you'll both learn about the AS topology and react to its changes? MA: Once i place them I care about the changes that might happen DM: How did you know the AS topology in the first place to know where to place them? MA: CAIDA has a database that we can use to infer business relationships among ASes - it's not perfect DM: So your system isn't self-aware - if CAIDA goes out of business tomorrow does this still work? It can't discover the AS topology itself and react to changes MA: Every time you're in an AS and you want to know your AS path to another you can use traceroute - it would just take more time if we have to start traceroutes from everywhere rather than using the CAIDA database. If the system was in place there should also be traceroute to check for changes in the paths such that we keep track with whatever happens in the path with the relays. Stuart Card: I've been astonished at the paucity of discussion at IETF about the potential interactions between blockchain research communities with IETF activities - do you have any ideas for broad areas of research at the intersection of cryptocurrencies and blockchain and IETF technologies where we might invert the relationship rather than regarding bitcoin as an application, but as an enabler? Allison Mankin: we have the DINRG, Distributed Internet Infrastructure Research Group, that is the home for this kind of research on friday morning - I think we are aware - that's why this paper was interesting to us - DINRG is the place where we're hoping that the intersection you mention will flower. Max Pala: Have you considered the deployment of TLS among nodes that have lots of connections to guarantee integrity? MA: We cannot really solve the partition attack with that - we can only address message modification by an AS level adversary. Aanchal Malhotra (AM): Regarding countermeasure for delay attack - you mentioned encryption and MAC - how does that help defend against a man-in-the-middle that can drop packets? MA: If the packet is dropped, bitcoin client will notice and request block from another peer - problem is that node thinks everything is working properly because connection is not lost - TCP will disconnect or abort if attacker drops block - so bitcoin client will notice that AM: It's still a delay attack - it's still delaying the delivery of the block not for 20 minutes maybe, but.. MA: Dropping is a problem and is what we use for a partition attack - but in delay attack it is invisible, so not possible for node to know it is under attack, but you are right that even if traffic is encrypted it can be dropped and so network can be partitioned, which is why we consider encryption a solution to delay but not to partition attack. Bingyang Liu (BL): Are attacks and countermeasures specific to cryptocurrency networks, or are they applicable to any peer-to-peer network? Delay attack is specific to bitcoin, I think ethereum is not vulnerable to delay attack right, but for partition attack I think it is general to any p2p network - so how about countermeasure, is it applicable to any p2p network? MA: I believe at least cryptocurrencies would be vulnerable to a partition attack - bitcoin is more centralised so easier for an attacker to hijack this traffic, but you're right any p2p network would not be able to function if you partition it. BL: There are lots of p2p networks including TOR, and other cryptocurrency networks - can your countermeasure protect all these p2p networks? MA: If we assume that we study all partition attacks in all the networks you describe then yes we can imagine that we can have a relay network for all. I cannot comment on whether such an attack would be feasible in another p2p network, if we assume that there is an attack model that would make sense with hijacking then yes you can use same properties to build a network against this attack. BL: It maybe more interesting if we can design a secure p2p network that is not vulnerable to partitioning attack MA: Agreed Jim Fenton: One of the characteristics of bitcoin network is the egalitarian p2p nature of their nodes and i'm wondering if you've had feedback from that community about sabre because this is starting to create the beginnings of a heirarchy - not all nodes are sabre nodes, are the sabre nodes considered a point of control and so on. MA: no, but first there are already relay networks out there and they are used to improve performance of the bitcoin network, so you can assume the same properties there - we envision a network that will be open to everyone - and will not be controlled in a way that can do something bad to bitcoin - even if it was controlled bitcoin clients would still have their connections to each other and so doesn't have the power to work against them i believe. SECMACE: Scalable and Robust Identity and Credential Infrastructure in Vehicular Communication Panos Papadimitratos, KTH Royal Institute of Technology in Stockholm, SE Panos' slides: https://datatracker.ietf.org/meeting/102/materials/slides-102-irtfopen-panos-papadimitratos-anrp-talk-secmace-scalable-and-robust-identity-and-credential-infrastructure-in-vehicular-communication-00 Q&A Max Pala (MP): All the times that you reported here are for signature generation? Panos Papadimitratos (PP): For whole execution of protocols that I showed you - many signature generations, verifications and so on. MP: Doesn't include network delays? PP: Network delays are dwarfed in these measurements - you might have a special deal with your telecom provider or you might be in your garage on your home network - all these numbers if you wanted to see how they would be in real life you have to add a few 100s of milliseconds - this is pure processing and communication. MP: You use normal CPUs, in many PKI environments you usually need HSMs and unless you're willing to spend a high amount of money the performance is not nearly as good - have you looked at economic aspects? PP: It's interesting you mention this, the need for HSM has been strong on the vehicle side - the Preserve project I mentioned earlier had an ASIC to validate 1000s signautres per second - we had an ASIC that can do up to 1000 signature verifications per second - better hardware is available now. MP: ASICs are almost impossible to certify. On the server side I would suggest looking into bursts of requests - that is where problems can arise if you don't have sufficient capacity. PP: Thanks for the suggestions. Apostol Vassilev (AV): Your protocols have a dependencvy on accurate timestamps to execute correctly right. How do you deal with vehicle clock aging for example? PP: For HSM you have real time clock that has to be synchronised with an external source - relying on GPS or Galileo is one option - spoofing GPS signal is an issue - a separate part of our work deals with securing the positioning and time signals for GNSS in general. For servers I suppose we can consider NTP with security addons. AV: NTP not necessarily a secure protocol right? PP: If your clock is not in sync with PCA, you appear, request certificates, lifetime will be according to clock of PCA - depending on where clock is, the PCA will decide which certs to provide - if clock of another car has drifted away from your clock, there are two things that can happen - one is that drift is not severe, or if it is such that a given message is rejected because cert has expired then that's the worst thing that can happen - traffic is rejected because it is outdated. AV: Could be criticial message about a crash, so this is an attack vector right? PP: Yes - there is a whole area of work that is trying to look at validity of data itself - these systems have much more severe unreliability factors - designing application for collision avoidance is where reudundancy and controls are required to filter out manipulated or forged messages, or an input controlling adversary that can induce a given value on a give vehicle - causes everything to break down due to lack of cross validation. AV: I agree these are difficult problems, but I'm not sure it's OK to kick the can up to the application level if the problemn can be solved at the protocol level. PP: Agree but which protocol are you talking about? AV: How to deal with drifts and tolerances that are involved in dealing with drifts. PP: Yes, I'm trying to make a distinction between provision of credentials versus how you deal with faulty information in whatever distributed protocol you are running. AV: Yes Allison Mankin: This would be a really big and very dynamic certificate system - there's nothing like it in the real world now - are we going to have something like this, operating this way? PP: Do we have anyone from a car manufacturer here or a certification authority that is already investing in this area? (apparently not) What we are trying to do is to show that it is complicated but we can keep moving forward and demonstrating that it is not too hard or expensive in the end. This kind of PKI will be dealing with 5 or more orders of magnitude more numerous credentials than any other PKI you have seen so far. So this is something we have to address as early as possible. The flipside will be to have a toy system that can provide very few credentials, so that would be at the expense of privacy protection. So we want both. Saulo Silva (SS): Did you consider speed of the vehicles - you are exchanging information between moving targets - can you expand to higher speeds, e.g. 500 knots? PP: These are real mobility traces with different velocities - this is taken into consideration. The interactions with VPKI deals with unreliability of communication or other multi hop communication - I can't tell you whether these protocols would work for unmanned aerial vehicles - more homework required. There is a great commonality but dealing with exact paramaters will require more work. SS: Collision avoidance is very different if you're talking about 80 mph versus 800 knots. PP: Absolutely and this gives me an opportunity to mention another part of work we're doing - we take standardised ways of communication, we need security, privacy, even though adding crypto accelerators at some point all this is tedious. How can we offload vehicles from communication onus and maintain security - one approach is collaborative verification - allows scaling to a larger neighbourhood. Guilin Wang (GW): The key idea for your system still use a longterm cert and shortterm cert - this idea should be the same as DSRC or formally called IEEE 802.11p - what's difference between your work and DSRC? PP: How to position with respect to standardisation efforts? IEEE 802.11p is a modified midimax control protocol with a different physical layer and multi channel operation targetting vehicular communicatino environment - security per se is not addressed in 802.11. Security from IEEE point of view is addressed in IEEE 1609.2 - there they provide the vehicle with a whole set of pseudonynms for life of vehicle, or for several years - crypto mechanism enables vehicles to use credentials - this goes against the on-demand provision - incurs higher overhead a priori - there are a number of other technical differences - they don't address distribution of revocation list - it is a parallel effort to which we contributed, they chose a different approach - i'm not saying we are better - there are pros and cons that one could argue about - the paper discusses in detail how our work relates to IEEE work and other research proposals, so I suggest you take a look at the paper. GW: Which type of signatures are used and what is key size? PP: car-to-car communication consortium had consensus that key lengths should be 256 bits - also had consensus in the community that keys shouldn't be very short - shouldn't be able to rewrite a transcript of messages after a year or so. so that was motivation for key length. second dimenaion is that communication is at a premium - have to keep crypto overhead as low as possible - ECDSA won out against RSA - also in accordance with IEEE standard. Amelia Andersdottir (AA): Isn't it true that CA will have all info from sensors about speed and timing so that whoever issues certs will know everything about vehicles that is protected in privacy model. from consumer perspective i understand challenge of V2V is that there is big competition for driver data to lock them into insurance schemes and so on - central location for data generation/storage means you're not solving tricky problems for consumers or addressing privacy very well. PP: think of car as a huge sensor that allows you to learn too much - quick answer is that none of this data is communicated with any of the entities I described here - you are talking about a different problem - once you have credentials, or if you forget provision of credentials. car manufacturer allows you to collect diagnostic data about the car - this is a problem that has to be addressed there. if data is at the disposal of various curious entities why would you bother building a strong privacy preserving system such as the one we are proposing? leverage legislation, user education is necessary, otherwise resistance is futile. AA: Could you imagine a big CA? PP: CA could be Ministry of Transportation - perhaps the differentiation between long term and PCA - PCA could be any CA in the world now that sees an opportunity to sell certificates. Who will step forward and instantiate CAs is open question. AA: I assumed automotive manufacturers would be CAs themselves - this model would aggravate the problem of data sharing for consumers because they have both technical leverage and contractual. PP: Principle is separation of duty - if all these operations are run by same entity with the same gluttenous appetite for data then you cannot do anything - need design to reduce as much the exposure as possible. Only thing you know as PCA is that I am asking you for ticket, then have to collect data from wireless system - but if you ask me a priori to share data that's a separate problem. MP: Whole system is based on assumption that crypto can be done fast and sizes of signatures etc. can be kept small - there is a lot of research on quantum-resistant crypto that is going in the opposite direction - signatures in the order of many kilobytes, key generation takes a long time - that's definitely not compatible with your system - have you considered how the future of crypto will impact your system? or how it can be parameterised so that you can accomodate changes? PP: It depends on the lifetime of the digitally signed data. If you want to use them for a posteriori liability attribution 10 or 15 years after the collection of a transcript. MP: Also consider long-lived credentials, credentials of CAs PP: Exactly. One thing you can do is increase key length for long term certs while you keep ephemeral certs with 256 bit security or you can keep increasing, but you need to have an eye on communication overhead - I'm not a cryptographer, but I have talked to cryptographers and I understand that we're not about to have our algorithms broken. Allison Mankin (AM): Come to CFRG because that is on the agenda. MP: Your system will take years to deploy, so lack of an imminent threat doesn't mean there isn't an issue. PP: One should be very much concerned with how to update crypto primitives that run onboard the vehicle and how to handle software updates securely. There are more issues when you think of vehicle lifetime. MP: For anonymity, electronic world is different to physical world. Long-lived ID is VIN - have you considered using that? Privacy concerns not addressed. PP: Introducing new technologies should not introduce new vulnerabilities. Beaconing location including VIN will create a much bigger problem than having to look under the hood of the car to see the VIN. AM: Thanks to the speakers and congratulations again to both Panos and Maria for their Applied Networking Research Prizes. See all of you in RG meetings throughout the rest of the week.