Archives
PLENARY SESSION ‑ 12 MAY 2015,
9 A.M.:
CHAIR: Morning, everybody. If we could settle down and start, if you want to keep talking, you can continue that outside in the hallway. Otherwise, settle down, take a seat and we'll get started.
This morning, we've got a bit of a routey kind of flavour. Our first speaker is no stranger here, Michael Behringer from Cisco, he is going to talk about how to band networks and for me they are a perennial pain, so I am interested. Each talk is half an hour including questions,
MICHAEL BEHRINGER: Thanks for the intro, thanks for being here at nine o'clock, great to see so many people, at nine it's always a bit dodgy. I hope this is going to be interested. We have been working for the last four, five years in a deep dark basement without talking to anybody, finally we can talk about it and this is exciting. We have done some what we think is innovative stuff, new stuff, now this is really whacky as well, this is really unusual, and so we definitely and urgently need feedback, and we are seeking feedback from the operators community and involvement. We are open sourcing, what I'm showing right now so we are also asking for contributions in open sourcing, we are standardise that go that in the IETF right now. I want feedback from you guys, what you think about it, is that useful? And if you can get engaged, how you get engaged.
Now, in theory, we shouldn't need to meet, right, we shouldn't have the need to meet because we all know SDN will save the world, there will be this big central brain that does everything for us, yes, but... yes, but... and there's this one thing when you ask an SDN guy, they all go quiet, and the question is a very simple one: Well, yes, your controller knows everything, but how does your controller actually know where the network elements are and how to connect to them.
Well... well... mmm, config, thank you. Enterprise network, a few hundred devices, maybe, large network, IOT, so you want to go on sensors and manually configure username password, is that really a vision of the world? So they really have a problem.
How do you get established security between the two? What do you do? Configure a shared secret, right, usual crap... so there's a lot of problems that have no good answer right now. And there is the last one, how do you actually consistently reach a network element? What I mean is, if an SDN controller configuration an interface, if that's the interface over which the connection of the SDN controller goes he has a fair chance of killing himself, right, so, what do we do? And so we have come up with answers for these,
First of all, we need to make network elements smarter, and this is ‑‑ the actual project we are working on is called autonomic networking, that's what the overall title, autonomic networking means leaving some intelligence on the network element itself, and not centralising everything right, so how much is a discussion for debate right, but some has to stay local. And one of the things that we keep on the devices is an autonomic discovery so that devices can discover each other. What about the security question? We have come up with an approach to securely boot‑strap a network, and when I say boot‑strap, I don't mean config. Config is actually a detail, boot‑strap such that the device can authenticate itself, that is a big difference because today you have to tell a device for TelNet I want you to use these credentials, for SNMP I want you to use those, for routing authentication, you get the idea, there's a lot of duplication here, what if we have one device certificate and the defence certificate could be used for everything?
And so, I think we are on to something here, and that I want to discuss with you. And for the consistent reachability here, so, in other words, how can we make sure that a controller cannot kill itself by configuring interface by modifying routing and so on? And that's the actual topic of this talk, we establish the so‑called autonomic control plane and that is independent of the config of the device and independent of the routing table. So it gives you permanent connectivity and what we found out is that actually can be used sort of as an out of band channel. This sounds really whacky now. If you think what the hell is he talking about? That's normal. It will come.
First of all, how do we boot‑strap security. When I say boot‑strap security what I'm really referring is not boot strapping a config, not the usual stuff, a domain certificate. Such that there's one trust anchor in the domain, in your network there is a CA, off that hangs a PKI, a standard PKI, everything device gets a certificate from that CA and then the assumption is if device A and device B have a certificate from the same trust anchor, they can trust each other, they can establish connections in a secure way with each other. And by the way, there is no configuration required on those devices. We have developed an enrolment process, and once we know we need certificate to autonomic networking the next question is how do you get those certificates onto the devices? And we developed a process for that, we came through all sorts of ideas. This was the only one that really stuck.
So, first of all there is an exchange of identities and that is very first slide, this discovery, autonomic discoveries, that's that, so every device talks to its neighbours. It says, Hi, I'm device X, here is my, D. If it has already a domain certificate like the proxy it will send that domain certificate across, because that's its passport, if not it will send its unique device identifier, serial number essentially, and what is coming in more and more devices is hardware devices called secure unique device identifiers, that is essentially a crypto chip in hardware, where you can validate the device with the device 0 number X that. We tie into this boot‑strap process, the proxy passes the information to the trust anchor, the trust anchor says do I like this device, is that my device? If so, it sends the parameters that the new device needs over to the new device, through the proxy, and then you have a normal domain certificate enrolment. So, actually, this looks a bit much but it's actually very, very simple, and there's not much really new stuff.
The trick here is we work with IPv6 link local addressing here is the one thing that I quite like, we don't support v4. The entire approach is v6 only. That does not mean that cannot run a v4 network with it. You can still configure your network in your traditional way but all our he be mechanisms are purely v4 and the idea is it will take still a couple of years till this really really takes off and by that time hopefully ‑‑ I stop the story ‑‑ you know...
One of the nice things is, you know what we do today in, when we boot a device, we first give the device an address, say, do you want to tech me? Actually by the way, who are you? And based on that we say yes you may come in but first we give you an address. In our approach we don't. We use v6 link local. It has a number of cool things and one of those is really are cool that is well done, so we only use link local. That means the device really needs nothing.
So, here to the first demo. I have two micro demos, extremely short demos that show what we are up to. This is a VM on my PC, this is all running completely local and what you see here is on the left is a topology that I have constructed in this VM, this is the network we have wired up so to speak. These are all IOS images on Linux, so this is all wired up, none of the devices is configured. I'm now telnetting to the console port of device 100, that's the device on the top here, this one here ‑‑ I need to touch one device, the central device, I also in an autonomic network where devices manage themselves I need a central trust anchor, that's a device that we call the registrar. All of the devices in this lab are unconfigured, you see that all of them will come up with this initial configuration dialogue, I say no, I don't want tonne enter the initial configuration dialogue, then it takes a second for the device to spit out a few syslogs and come up with the interfaces and stuff like that. Then I configure the very basic information that an autonomic network has to know, has to know, and actually, funnily enough when you are in this state of mind where you think what does a network actually have to know, a network needs to know very, very little, so I go into enable mode, I say this, I tell this device you are autonomic, you are an autonomic registrar, this is what we call the central trust anchor, you work in domain ripe.net. The white list of devices is whitelist.text. This is a text file that we have prepared. You see here the serial numbers of the devices in that that belong to me. This is a bit crude, this ain't particularly pretty, but it works for now. We'll make this prettier as time progresses. Usually we'll see proper serial numbers and proper ITs here. I need a PKI trust anchor, that's a certificate authority, in this case we run it locally on the same device, it is supported on every autonomic device, it can have this function. And that's it. An autonomic network does not need more information.
Now the entire network can boot‑strap, and forgive me I will not explain every syslog that's passing through here. Note I'm only on device 100. Device 100 is boot‑strapping now. So the philosophy in autonomics is, you can see, you can debug everything, as you know, but, you can't config anything, well you can, I can say I don't want it no autonomic return, but that's the level of granularity we give you because it needs to be autonomic, it must be autonomic in itself for it to work properly. So now we see ‑‑ I can now see what happens with this device, and the device with serial number 100 now has a domain ID, what I entered, it has a unique device ID, it ain't pretty but it's not meant for human consumption to is doesn't matter. It has a certificate, and look at that, it has an IPv6 with which I can reach ‑‑ I'm I mean I'm on this device so that's a little bit silly for this device but it works for all.
And now I go on, show autonomic registrar, and I say device is accepted and I get the devices that have already enrolled in the domain while I am talking here, so work is happening while you are having coffee. The device 101 and 102, the neighbours of 100 have already boot‑strapped, and, as time passes, you see I hope you can actually read the syslog, "Device with UDI 203 is allowed," so this one down here, it's already allowed, so if I do the same command again, you see the next level of devices has already boot strapped. So boot strapped here means they have received a domain certificate, nothing else. They just have the trust anchor information, nothing else. Now, here is something to watch out for. There is no configuration on those devices. You should ask yourself a question, hang on, how can I enrol device 300 or further down devices if I don't have a network setup. There's no network, there is no config on those devices and that I'm going to show you now how it works.
Look now already the next layer ‑‑ it takes about 20 seconds or so for a device to enrol and then it does the next one, it ripples through the network and by the time I have done the next slide it will be done. So let me go over to the slides again.
So, the nice thing about this is since we use a secure way to identify the device the entire boot‑strap process is actually secure.
Virtual out‑of‑band channel is now what I actually want to show. And there is of source a catch in this whole thing, as I just pointed out, yes, this looks pretty on a slide, but, in reality, there's actually a network here. How do I get my packets from the proxy to the registrar? How I get it between new device and proxy is clear right, IPv6 link local, I don't need anything else. This is one of the very elegant things. So, that's clear, but between proxy and registrar, how does that work? And so, the answer is something new.
This is what we call the autonomic control plane. Here is what an autonomic node does the
So, an autonomic node will talk to its neighbours using link local. When it sees a neighbour with the same domain, with the same trust anchor, i.e. we're mates, we belong to the same company, then it says, you know, we have probably more messages to exchange in the future, let's establish a secure channel first of all. IP Sec, whatever you want, TLS, whatever, several tunnel times are supported.
Now, those who know me I have been working on MPLS security way back. One of the things I have always said is one day I want to one all control plane and management plane in a VRF, then I cannot be attacked from the data plane, this is a really elegant way of doing it and since we have started something new, we said okay, here we have a chance. So, an autonomic device establishes automatically a VRF, which is only used for this purpose. It is not configureable, cannot touch this, you can see it but cannot actively modify it. This tunnel gets hooked into the VRF and you do this to all your neighbours. And you end up with something that looks really, really odd. This is sort of an overlay network, which goes hop by hop. Anybody with a normal networking brain goes like... what the heck is that? And so, bear with me, this is actually quite cool. Because, this way, we put a loop back in those VRFs, those are the addresses that you saw, and the trick is again everything we do is based on IPv6 link local, everything. So I don't need to configure those tunnels either. I don't need routable address space. This is why it can't just happen. I don't need anything.
And that makes it independent of the config, independent of the routing table, I don't need routing for this because it actually runs inside this red topology, we run a very light wait routing protocol in there, RPL, RPL, used for the Internet of things, here in this room, how many people have heard of RPL? That's what I expect. Everybody goes like RPL, what? This is a very lightweight distance investigator protocol. Good enough for what we are doing and they think we can run an entirely huge enterprise with run routing instance, that's why we use that one.
So, now what we want to do is, we want to connect to this, and so wouldn't it be nice if I now had my SDN controller on the right‑hand side and it could talk to those devices through this channel, because now I can actually modify the config whichever which I within a, the red channel isn't dependent on it, I have permanent reachability of this device, some exceptions apply by the way, so, this is not a hundred percent but we're getting there, I have permanent reachability to this device, never mind what the config is is, so I can change the addressing scheme on all the links, I can change the routing protocol, I can do what I want. It does not matter.
So, for now, we have to bring in this interface where the control is connected manually into the dash and those who have looked in the MPLS, there is a command already that we are borrowing for this purpose to make sure this guy is now inside the red channel and now I can telnet to all the devices and, hey, I say deliberately, telnet, I am actually a security guy, you don't need to SSH because all the tunnels are encrypted. This is the nice thing. Security is just there, you don't need to worry about it any more.
Let me show you, the key point here really is if you think about it, you have actually an out of band channel here. Now, it's not really out of band, we all know that, it is in band, true, but it has the sort of semantic as out‑of‑band channel, cannot kill it. If you misconfigure your AAA, you actually get through the red channel.
That's where we come to the second demo.
In the meantime, all devices have enrolled, as you can tell. I can show autonomic registrar devices accepted detail and I see now for each device the key, the public key of that device, I see what I want is the address here. Whatever ‑‑ let's just pick one, here is the IPv6 address of this device. And now I can say ping ‑‑ so this VRF has a name. And then I ping this thing. And I have reachability, 203 is this device down here. So I have pinged the device even though there is no config on any of those devices, I can do this across the entire network. I do need a sum of servers and I don't have the time to go into all the details. I do need MD MS and I want a AAA server later for my log‑in, so I need a... here I need to do this command autonomic connect that you saw earlier, IPv6 address. So now this interface ‑‑ on this I have prepared. There is a AAA server, mDNS server, there is all can have services I need, a config later which I will not show which you can you can use well, and now you see actually that services get propagated automatically, they propagate inside the autonomic control plane so every device has knowledge of those services automatically, you don't need to do anything about it. Now I can actually telnet to this device and I have to say again ‑‑ here I have a log‑in and password, and then the big moment happens when probably the service announcement, I have done it fairly fast now. But you will get a log into this device now. So you go through the entire chain on completely unconfigured devices and you have reachability of the device.
So, now we have the password ‑‑ some of the things also have to do with the fact that this is a VM with more than a dozen devices turning so sometimes it just takes its time. I'll leave it here, you can log in this way into the device, and you have a prompt as if you were on the console of this device. You see where I'm getting. With this virtual out of band channel you have reachability to all of the devices across the entire network even if they are not configured. None of those devices is actually configured. That is pretty cool so you can later do this from an SDN controller, whatever you want.
So the work flow, I'm not going through. These slides are here so that you can look at what I have done. This is all explained ‑‑ this is a demo explained basically, how to configure registrar, you can have them redundant, they will discover VLANs if there are any and you can limit that. So all of that is not important here.
Strategy, and this is why I'm here. I need your input. I need your feedback, is that useful for starters? When we got there, we originally tried to solve a security problem. When we got to this point we said hang on, this is not just a security problem we fixed here, this allows us to do a lot more clever things, because now I know which device is friend and foe and can make boundaries automatically, I can bring out the routing protocol automatically, we have a prototype which completely self‑configures, with a routing protocols, and adds protection. No config required. We went through this and said hey, this is really big and that's why we got in an autonomic networking because that's really what it is. Let network devices by themselves figure out what they need to do. And give everything network device sort of a DNA sort of intrinsic knowledge on what it needs to do in a given context.
So, this is all being layered and this is what we are doing in the Working Group in the IETF now standardising the approach. What you are seeing is the autonomic networking infrastructure. This is not yet really autonomic networking. Really, bringing up routing protocols or do other network functions automatically is something that we still have to do. But what's important is that we establish one infrastructure such that the security issues that I mentioned earlier that we don't have to do security for every protocol separately, for example. And this is why we are building this infrastructure. You have seen naming addresses, you have seen the domain identity, I haven't shown the message path but you have seen some discovery and some other stuff. And on top of that are autonomic service agents that bring the real functionality, the cleverness that we want to bring into the autonomic networking. That's coming later, right. And so, in a service provider environment, we aren't completely stupid, right, we know you wouldn't want magic to happen. The reason why this is acceptable today is because exactly we are actually not touching this config. What's happening here is independent of the device config, so you manage your devices in the normal way, this is really out of band channel is really a free add‑on, so to speak, it's a free functionality that you can use or not, you don't have to use it or turn it on, so it's entirely up to you, but it's a very small step in autonomic networking but it allows you to gain a little bit of insight in where we want to go with this.
So, as I said, this is in the ANIMA Working Group there. You there are tonnes of drafts. We want input. If anybody wants to collaborate with us on that, we'd love to have authors from the operating community on all of those drafts really, so if you are interested in getting involved, please ping me on that. And on ODL we are open‑sourcing the current code basis, we really think this is going to be something big, as I said the potential to become something big so we want proliferation, so this thing should go out as it is, obviously everything is taking time, but we want this to be open source such that everybody can implement this basic infrastructure block that I have just shown in a really easy way, so if you look for SNBI secure network boot‑strapping infrastructure, that is what I just described.
And with that, to a very quick summary.
We are working on autonomic networking. The idea is that devices find out by themselves what they need to do and take certain actions independently, sounds scary, but OSPF ISIS is that, so you have down done it already, it's not something massively new, it's just the way we do it is different. Then we establish this autonomic control plane and that is completely autonomic itself, it just builds up, there's nothing you need to do with a nice property it's independent of your config and routing table meaning if you mess up your config somehow, if you mess up your address routing you still have reachability to those devices. That's something we'd like to get your feedback on.
That's in the notes there, the devices.
Questions...
I'm done.
CHAIR: Questions for Michael...
MICHAEL BEHRINGER: And probably ‑‑ if you scratch your head and think what was that? That is normal, it is whacky, give it a bit of churn, it will sink in.
AUDIENCE SPEAKER: My name is [Ahmad], I like your talk very much. It is very nice to see the security in an autonomic way, the security of the whole network. But I have a question that, the assumption is that the proxy certificate is trusted. So my question is: How the entire nodes, we find that the certificate is come from a trusted route, because in this case, if the let's say the attacker played the role of the proxy or the certificate proxy or registry, in this case the entire network would be misconfigured.
MICHAEL BEHRINGER: And the sound up here is really bad. You are asking how can the devices trust the certificate of the other device?
AUDIENCE SPEAKER: Yes. Mainly my question is the entire devices or the entire routers, how you verify that the certificate that comes from the registry or from the proxy, that it is a trusted certificate.
MICHAEL BEHRINGER: This is standard PKI as it would be in any other PKI, it's an electronic passport of a device, it has been issued by an issuing authority. The fact that it has been issued by the same issuing authority as mine, we make the assumption right now which we don't have to by the way, we make the assumption same trust anchor, I trust this device, it's the same domain. In my example it was ripe.net so all devices in network ripe.net will trust each other. At this moment, it's black and white. It is perfectly possible to have sub domains where you have different trust boundaries, different policies, all of that it possible.
AUDIENCE SPEAKER: So in this case you need to pre‑configure let's say the certificate, the trusted certificate list on the entire devices, the inner devices.
MICHAEL BEHRINGER: No, you don't need to configure anything. If I have ‑‑ it's like a passport. The fact that I have a passport from my country, you don't need to talk to me upfront, you can see that and you basically see my country has issued that therefore you believe that, right. It's the same with the certificate.
AUDIENCE SPEAKER: Sorry, another question, do you really own ‑‑ you said in IPv6, do you really own a stateless autoconfiguration discovery to distribute these things or ‑‑
MICHAEL BEHRINGER: We are running our own discovery protocol here right now. Again, this is in the standardisation right now. This is pre‑standardisation, so this is not standardised yet, but we are trying to standardise on this neighbour discovery protocol.
AUDIENCE SPEAKER: I have a question here on chat from Tore Anderson, who asks how are the devices assigned a hoop back addresses reachable through the virtual OOB network, I assume these are globally scoped, not link locals?
MICHAEL BEHRINGER: Yes, the addresses that are attached to the loop back here, that's a routable address and we use an ULA prefix that we calculate, it's not assigned, it's calculated. That sounds whacky, there is a draft how to do that. Loop back use routable addresses, we use ULA for that, everything else is link local.
Thank you very much.
(Applause)
CHAIR: So, thank you. The next speaker is David Lebrun. This is the second presentation on segment routing.
DAVID LEBRUN: Thanks for the introduction. So I'm a Ph.D. student at UCL in Belgium. I'll talk about some my work on segment routing and more specifically, the IPv6 flavour of segment routing and the implementation in the Linux kernel.
So I will assume that not every one of you knows about segment routing, so I'll do a brief reminder what it is all about.
So, segment routing is a source‑routing technology. So it means that the source controls the path of the packets into the network. So, for IPv6, every packet supporting segment routing has a stack of segments and each segment is an IPv6 address. This IPv6 address will present either a loop back at the ‑‑ or a link address of a router, so you can control if you want to go through some node, or through some link. And as the segments are IPv6 addresses, there are simply distributed through IGP, we need to support segment routing, apart from segment routing itself, we need IGP, and that's all.
So, I did some administration about the workings of segment how long, so we have here a simple network, ingress, egress, and we have an abstract SR header. This is a stack of segments. So as B segment B, and I explain the rest, and you have a pointer, which is updated at each segment node that points at the active segments. So first, you receive a packet at the ingress here, and the ingress node will just read the segments. And it sees that the current segment is segment D, so what it does is, updates the destination of the packet to the address of D an increments the segment pointer. So then D will save the packets, do exactly the same thing, okay the packets now needs to go to B, same thing. Here we have a special segments. This is a service segments, I go more on this later, but basically it's some service that needs to be applied locally by your virtual machine or whatever technology.
So, we apply the service, then the next segments, F, and then egress. So, basically what we did is, we controlled the path of the packet into the network and we did not follow the shortest path, that would have been from I like this straight froward to E. We did some detour and applied some things and then followed the packet out of the network.
So, that's for the abstract workings of segment routing.
Now, for what can we do with all this? Well, the possibilities are quite unlimited. For example, we can think of a network where we'd like to go from A to B, but using only disjoints link and our nodes. So, we can have some controller that would, from the graph of the network, would compute this joint path and then inject the proper segment routing header to further the traffic to go into the joint links. There are a lot of applications for this, redundancy, latency and so on. We can think of dynamic network configuration. So we have a controller that knows the network states, by, and it sees okay, I see that this link is congested, so what do I do? I just change the segments and go around the congested linking for some traffic. We can force traffic to go through some node like a firewall, for example you'd like your traffic to go through at least two firewalls of different vendors, no problem just track the segments and you go through the two firewalls. You can provide services to your customers, for example, you have several transit providers and you'd like to allow your customers to choose which transit to use instead of relying on your BGP algorithm. You just provide some segments to the user customers and then you can route your packets into the network through the correct transits.
I will not talk much about security, this will be for Eric, the next speaker.
So, now, IPv6. This is implemented by using a new extension header. It's a routing header type 4, so type 4 is not currently located by INA, but ‑‑ well it's in the very early implementation. The security concerns of the first routing header type 0 has been addressed thanks to an HMAC field which protects the header. So, we have here the routing header according to RFC 24‑60, so that's compliant. Then we have the first segment, it's an offset pointing in the segment list, so, the segment list contains every segment in reverse order. So, the first segment here first, is actually the final destination address and the last one is the first segment of this. This is because we need segments left according to the RFC, and it's easier to do this so simply we started at the end and increment, we go from one node to another node. So the first segment is the offset to this entry.
There are some more entries, optional entries between the last segments and the HMAC but I will not talk about, it it's some policy segments, it's not really important to understand segment routing here.
We have some flags, I talk about some of them later, and we have the HMAC key ID which maps to a secret key to whatever hashing algorithm to expiration time, whatever, and we have the HMAC value here that prospects the whole header and I will let Eric talk about this later.
So, about the flags. So here we have two important flags and one especially. We have the fast route flag when we said the packet got fast rerouted and we have the clean‑up flag. The clean‑up flag is quite important because if your packet is in a segment routing domain only for a time and when this packet exits the domain, for example, to some other provider, to some other whatever, you'd like for example to avoid linking information about your network outside your domain. So, the clean‑up flag just said that the ability to hop will have to strip the segment routing header from the packet before going outside the network.
Well, that's the algorithm for forward routing, I just go quickly about it. So, if a node says that the destination address is itself, so, it means we are a segment end point, we process the segment header, it route segments left, then we increment the pointer, we update the destination address with the next segment in the list. If the segments left is 0, then it means we are the patently made hop and if the clean‑up is set, then we strip the segment routing header. If, when we are saving the packets we already are at 0, then we are at the final destination and we give the packet to the PID, or do whatever processing we need to do.
So, about the Linux implementation. So, we are currently working with 3.14 branch, it's about 2,500 lines of code, open source of course, we have interfaces for injection and control. The source is available here, so, the kernel source and the user tools.
So, we have several ways to inject the segment routing either into a packet. We can do from a router level points, or from the host level point of view. For a route level point of view we do this per destination prefix, which will modify this so we can use for example net filter whatever, but currently like this table you have a destination prefix, you'll see a packet going in, okay it's for this destination and we inject a segment routing header. So some host you just send packets, the router checks the destination address, okay, it's in your table, okay, we inject the SRH and reroute the packet.
From a host level point of view, there is an interface that is sets up, so it picks the application that suggests the segment router into the packets. The kernel reinstitutes the packet and sends it into the network. And the router here just do the normal for routing and don't bother about the segment routing header. Host level injection can be interesting, for example, when we have a TCP flow, we'd like to have the flow going back to the same path. If we are in the same domain, it's kind of easy, we can just reverse the segment routing list, and take the reverse path the same as the forward path. But, of course, this is possible for host level injection. There is a per socket control. You can say okay for this segment to reverse the segment list, for this I do not want it, and so on.
So, more about the interface. You have some CCTL to control some stuff that's not important here and you have a user land tool to control the kernel tables. I will show some example of how to use this tool.
So, let's say we'd like to inject two segments for a given destination prefix. So, this is Facebook and perhaps you will recognise these two addresses. So basically this says for all traffic going to the IPv6 address of Facebook, we'd like the packets first to go through Google and then through RIPE. That's the most unusual case unrealistic case, but that's an example. So you have the prefix parameter here, you have the prefix length here, and the option of the add is the segment list which is separated. We can do the same, but by setting the clean‑up bit on, just add clean‑up to the command. So that's the same, the penultimate hop will move it to the final destination.
The show table here. So, this is the table. We have here three entries so that's the first example here, and you have two other entries, so we can have your prefix length, you have the number of segments, you have the segments here, ID don't bother about it. HMAC is the HMAC ID and the clean‑up just means that the clean‑up flag must be set for these packets.
So, we realise that for routing traffic through Facebook, through Google and RIPE is not such a good idea so we decide to remove it by using simply detail and if you want to flush the whole table, just flush.
So, I talk about using injection which sets per socket injection. I go quickly through some example code to see how you can do that. Well it's not best practice code, it's just some example code. Don't use it. But just it's for the sake of the example. So we just get the socket, whatever, we set the destination address here, we have the header, segment header, and so the length is the eyes of the header, plus 2 segments, we don't bother about HMAC, so you allocate the header, you don't bother about the length, the kernel will do this for you, a type 4, first segment offset, set the clean‑up flag, and then we just set the segments to the correct addresses, and then you just set socket these options and the kernel for each outgoing packet will automatically insert to the segment routing either into the packets. You just connect and you don't have to bother about it any more.
So, before I quickly talk about using services with segment how long, so, the idea is that basically the segments will present the next hop to use, but you can do something else with this. Locally you can say okay, I have received a packet, thanks to this segment, and I have a table saying that this segments correspondence to some services.
So you have the packet coming in. You look at the active segments on the table, and you have a mapping from segment N to service N and the service can be PID socket, whatever, you say okay, I just send the packet to the service, which can be a virtual machine whatever, the virtual machine do whatever it has to do, and return the packet to the network and it will continue for routing. You can do almost everything with this encryption, compression, fire walling, translation, it's just ‑‑ it's just user land now so you can devise whatever you want. And let's imagine the case where you went to first put the packets through a firewall, then compress the packets then encrypt them. What you have to do is just creating a segment routing header and chaining the segments representing the services us wish to apply. So, here is the packet sent by host A to host B, so source address is host A, I talk about this later, the segment list in reverse order. So first VM 1, which is firewall, then VM 2, which is compression, VM 3, which is encryption, we decide to go to 4 after that for whatever reason, just show it's possible, and then final destination is host B. The destination address is VM 1 because it's the first segment, so the packets just flow into the network from R1 to VM 1 which applied the services, the packet can go ‑‑ cannot go, okay, can go. From VM 1 to VM 2, compression, okay, sending it back into the network, encryption, same thing, Internet work again, R4 and then finally, final destination, host B, and you have a whole flow that has been through a firewall, through a compression, to an encryption, just by saying into the packet okay, we have segment 1, B and C and the network can do the rest.
So, some IETF drafts about, it there is more, but this is basically the main draft talking about segment how long, we have the draft saying about the IPv6 version, we have a draft about security, and so on.
So, some pointers here. So, this is the website of the IPv6 implementation, this is reports source code, whatever. The Cisco website here, some implementation, technical reports, and if you'd like to play with segment routing, there's a virtual machine available here, it's about 500 meg. There is the tool included, the kernel, so you can do whatever you want with it if you'd like to play with it.
Okay, I think that's all...
Do you have questions?
CHAIR: Questions for David?
AUDIENCE SPEAKER: Aaron Hughes, I have a lot of questions, but let's just start with the simple one. What is the expected behaviour of the router if a segment in the chain is no longer up?
DAVID LEBRUN: So, you mean a router that has to handle the segment routing, so you mean a segment end point?
SPEAKER: Anywhere in the middle of the path. How does the router know what to do if you have an extension header that says my next hop is an expected segment and that link is no longer up ‑‑
DAVID LEBRUN: That's up to the IGP, that's really not up to the world of segment routing to bother about it, do you whatever, but... if you do not use segment routing and you have a router that needs to forward a packet to the next hop but does it do if the next hop is not valid.
AUDIENCE SPEAKER: So the fallback path is ignore the extension header and fallback to your local routing policy.
Secondly, this is avoiding the FIB, aren't all packets on system switched anything where this extension header is enabled? Since you are ignoring the FIB in some cases, right, aren't all packets then system switched?
DAVID LEBRUN: Well, this ‑‑ you have the Linux implementation, so, yes, it's system switch. For hardware switch, well that's up to the hardware guys.
AUDIENCE SPEAKER: Okay. Last question: What actually is the use case for the clear flag not being set? When would you ever want to leave that data enabled?
DAVID LEBRUN: So you are saying what the use case for leaving the SOH into the packet when exiting the network? Well, I talked about it. If you'd like to reconstruct the inverse path you need to have the segments. Otherwise, you can't do that. Well, basically, it's a use case where you are in the same AS. Of course, if you are leaving the AS, there is, I don't think, any reason to leave the SOH in the packet.
CHAIR: Thank you, David.
(Applause)
CHAIR: The next speaker is Eric Vyncke.
ERIC VYNCKE: So, when we keep the same topic, so we keep going with segment routing, and some question that I address usually is beside, is it useful for our network or not, will it run on nigh network, yes or no? But the other question is, basically, can it be run in a secure way so that we do not basically bring the security down by adding some functionality like traffic engineering which is basically what segment routing is about.
So what I will cover is one additional use case. Dave talked about segment routing used for service chaining, so within typically the centre or one autonomic system, or, talk about traffic engineering, where he was trying to do some very real traffic engineering, sending packets through Google and then to Facebook, of course like a joke, but you may want to do this specifically in Europe, for instance, and based out of Brussels, I know some of my customer, when they are sending health data or financial data from Belgium, let's say, to Switzerland, they do not want these packets going through a US network, right, this is quite common requirement. So you want to do traffic engineering for instance just for this reason, not only to optimise bandwidth or provide backup or cost efficiency, insome case, you want to do it as well to apply to some regulation.
Anyway... so, specific use case. Use case until now were always within the same AS, but in some case, of course you will ‑‑ you want to be in one AS, thinking about mobile phone, we are not always connected on the mother network on your AS but you want to provide some services into your Cloud here, which is how long enabled, but the PC on the left is outside of your AS. Usually people outside of your AS will provide you with no quality or traffic engineering, they go ignore the segment routing header recollect it's not there, easy. But how can you, when you are outside of the network routing network now about T the first thing, we get the segment list and in this case the security of it, from let's say an SDN controller, whatever, magic box, that's aware about the topology of the SR enabled network knows if one router is down we need to fall back there, so this SRH can change upon the times.
Anyway, so it's coming from a nice place ‑‑ so from there, go into the PC and then from then all packets will include the segment routing header. Outside of the AS, nobody cares about it right, they are simply routed to the destination, people ignore the segment routing header, period. Arrive at the ingress router. This one really needs to check where the source is authorised to send segment routing headers to my network, because I will provide with some service that is cost me some money, so I need to be sure that the guy is actually authorised to do it. So it's checking with the HMAC, and then it's routed inside the segment routing network, pretty much it's usual and people do not need to check any more the security it have because it's within the same AS and most of the time you can trust each router within the same AS. I mean if cannot trust, it you are in deep trouble anyway.
So, now I mean most of the time when I start talking about segment routing people say hey, remember I read something called RFC 50‑95 that says hey, routing header is back, and there are basically not allowed any more. Yes and no. If you remember the structure of the routing header, all of them from RFC 24‑60 has the same structure. Where you have there, you have the type, and look about the type we have. Currently we have 0, 1, 2, 3. Type 0, is the bad one. And if you look upon my picture and you have seen a pension of mine, I am always using the guy with the hat, and you know hat, the white hat and the black hat. Right. So this guy is wearing a black hat. That's the bad guy, that's easy to understand. So ARIN are, with your white hat you are safe, you are the good guy. So he is sending a specific routing header with looping site where like A in Amsterdam and B like in Brussels for instance and it's going from A to B, A to B, so this guy is sending traffic arrive to A, A forward it to B, by looking at the extension header, B to A and so on. I don't do everything. Usually up limit is thereafter some forwarding it's dropped, right. There's no loop in IP network, but as a big [] attack. I used Amsterdam and Brussels about 12 hundred kilometres apart away, so there is no real damage there. If one is Australia and the other one in US it costs a huge amount of money, so you want to protect this. And this attack is the main reason why RFC 5095 depricated routing at a type 0, and it's very specific to say type 0, okay. It's not all of them. And basically, they said this, the amplification attack I just described, is sufficient to deprecate the use of routing type header 0. But, and they add in the blue a side effect is that this also eliminates routing at a type use case, where you want to do it for a good reason like traffic engineering. And will you now "However such applications may be facilitated by future routing header specifications." That's where we are. If you look about Type I of the routing header, that's a project called Nimrod, which is basically dated even before IPv6, which was I was born at that point of time, but I was not speaking IPv6 that point of time. It's about mobile networking something like that. Completely out, it made historic, but the type is still in use of course, it's still allocated it's no more in use and as far as I understand there is not a single nimrod packet was sent in IPv6. But type number 1 is allocated. So, if you see it it's a kind of a ghost packet.
Type 2, was assumed to be a big benefit of IPv6, mobile IPv6 right with optimised routing. Type 2 is not a problem, because as soon as you ask Type 2, segment left is always 1, right, this is basically the mobile agent. So cannot put a loop there. All you can do is a reflection attack. So it was assumed to be okay. And everyone can act on this.
Type 3 is interesting. It's called RPL, that's what Michael told you this morning with autonomic network. And as nobody, or nearly nobody knew about RPL, let me explain it, so it's mainly for sensors, and you see on the top right, where all the sensors below has got radio link, they are in the same network prefix A, but they do not have complete reachability among each other, so by some magic, I mean some protocol of course, they are building up a tree. On the top, which is the blue box, which is a gateway between the RPL network and and the real Internet and then everybody has got the list of its neighbour by radio. Those device, a tiny, tiny memory and tiny CPU. So RPL is a specific code called stateless, because it does have a lot of state in routers, routers, they are way more than 16, right, there could be thousands in one RPL network and we don't want to get to very small chip. So all they do, in stateless, all the nodes of a single route, the default route, pointing up, that's all they have. When the tree is building, the top node which is rerouter has got the complete topology, think OSPF, he knows exactly where all nodes are, he knows for instance, in order to reach C, which is on the left side, needs to go through B first. So, how does it go? You want to go from the RPL network to the Internet and then up you go to the Internet. Somebody on the Internet wants to reach node C, so he travels to the gateway and this gateway inject a routing header type 3, specifying pretty much like a similar routing all the list of the segments he needs to go through. So in this case will be A, B and C, right. The only machine is the top rate of the gateway between the RPL network on the the Internet. All the others will simply use those routing. That's how it works. It's smart. Now you get some case of course, if C wants to talk to D, which is just next door, packets will be followed the default route up to the blue box. The blue box will say back below, right, this is not optimised for this. But this is how RPL works. In this case, there is no security issue here, even if you can get multiple hops, you could introduce a loop simply because you trust all the RPL nodes into the RPL network, right. Again, if cannot trust them, then you get much more damage can be done. And, it's very important, RPL extension header will never leak to the Internet and if packets coming from the Internet have a RPL header, it will be dropped as well by the blue box. Basically, the blue box is not only the stateful thing that knows everything about the network, it's also a kind of a gateway blocking this extension network to come into the network or leaking from the network, that's how it was accepted in the IETF. We are back to segment how long and basically the draft that David and myself and Stefano proposed at the IETF. I mean, there are multi‑corner case that I will not address here, but let's go to the main one.
As David has said, it's basically the same diagram he is using, that the extension header that we are using. And, again, this extension header needs to be processed only if the IP destination address is one of yours. Routers in the middle, they don't look at it. They only look at the routing header when you are the destination, right, as part of the destination address field.
So what is new? A few things, but David explained it to you. What is really important for security is those fields. We are simply doing a HMAC. With HMAC with 0, there is no HMAC, it is pretty much the same thing as the HMAC we use in OSPF, or whatever. It simply proves that you share the right secret with the SDF controller and all the routers in the network. That's it, okay.
The coverage of the HMAC itself includes the source address, and all the fields, they do not change on the path, which is basically the list of the segment and the HMAC ID. Now, if the list of segments is changing for any kind of reason, for instance like a questions before, a node in the traffic engineering path is broken and we need to reroute around it, the list of segments is changing after a while, and enough goes the HMAC kind of signature will be different.
We have multiple key ID to a key rollover in same case we want to use a hashing algorithm with different strengths, SHA1, SHA2, and so on. So there's a reason we use a key here.
So with this that is only useful when you receive packets from outside of your AS because cannot trust anything coming outside of your AS. On the first ingress node you do check this HMAC and then after, as you are within the same AS, you don't trust it any more ‑‑ you don't check it any more because you trust the previous one.
Very simple there. And, again, most of the issue for routing type 0, like the amplification, are not applicable because we are within one AS and we trust each other.
So, extension address in the Internet. It's pretty much overloaded right. I was looking for a picture free of ‑‑ I found this one quite interesting. In some cases ‑‑ but is it a complete failure if we are using extension headers over the Internet?
And, we made a draft about a year ago telling that 20 or 40% of the packets without an address are dropped over the Internet. Of course, again, segment routing, if it's within one AS we don't care because then you can tune everything for yourself, but what if the specific use case where the mobile note wants to send a segment routing header to be processed later by the network? So, we need to be sure that the packet is travelling over the normal Internet.
So, I made this website and you can test it right now, this simply does this, and I did it yesterday. It's really a bit too small to read. It basically sends from my server, which is somewhere in France, an ICM packet to your IPv6 address, that's the green line, and in this network there is no firewall, and then it simply sends the same ping with a segment routing header, so type 4, okay, and segment left 0 of course because you need to accept it, and it simply travels here and my laptop replied. So, basically at least it was kind of ad hoc testing that not a lot of places are dropping segment routing header, even if that not exist. Again from a server to your PC, so there is no firewall.
Even more, I wanted to do some measurement, people who know me know that I like to measure a few stuff. If you go to the URL to Sander that gives me a VML, together with students doing their masters. We are basically getting the list of IPv6 addressees, the usual 1 million website and we look for the one IPv6 server, and we basically take a bit of all the BGP table prefixees shorter than /48 and we tried to send packets to those addresses. This specific one was using all the BGP table, so one packet per prefix, which is outable over the Internet and we measure whether we get back something. Everything which is green is okay. Most of the time, so 69% of the time when I was sending a Bing, somebody reply, okay. With the ping. In green, like light green is basically the destination AS drop meaning for instance if the Google, because Jenny is here, I'm sending any kind of packet to Google network, of course, they are the destination AS, they must basically protect the network, so I'm pretty sure they are dropping all packets extension address on the very first router as soon as you join Google AS. That's what I would do if I were there. So, that's normal. What's abnormal, this is the people in red. That's a transit AS, a dropping packets that are not designed for them. And in this case it's minor, it's 2 or 3%. So, at some point in time we need to go back on the same table and say hey ‑‑ maybe that's because people are changing their mind in nine months. Anyway, we can talk on this, because I think it's really, really important, and I would love, I'm pretty sure that everyone would love to know why people are dropping stuff if not on purpose.
Questions...
JEN LINKOVA: First of all, one minor comment, you mentioned use cases in the beginning of your talks and you said that for some reason you might want to avoid traffic going in a particular part of the network. I'm not sure how can you do it with segment routing because you can explicitly say which hops your traffic must go through but you know where you can say please never ever send my traffic through this part of the network.
ERIC VYNCKE: On this one you are right. Obviously, if you put a loose source routing, cannot be fully sure that you don't bypass. Now, if you really do a good guess putting all the routers in the shortest path, then you are mostly sure, mostly, I do agree.
JEN LINKOVA: Speaking of dropping filtering extension headers, I'm slightly confused with your type of results which says "not reached". What does it mean?
ERIC VYNCKE: Not reached, that's basically when I was sending a signal on port 80 and I got no reply, so I don't know. So even a normal one, not reached mean I'm trying to contact this IPv6 address but they had not a single reply, even for volume packets, so I cannot get any kind of data out of it.
JEN LINKOVA: Okay. Just a comment on filtering transit, I think I mentioned it, you actually never ‑‑ you could not know if it's transit AS or actually destination network because even, for example, if you do traceroute or ping to YouTube, you might go through few IS reach Google is controlling, right, so even packets is not dropped on the destination AS, it still might be dropped on the same administrative boundaries of the name network but a few ASs had.
ERIC VYNCKE: Correct. So we tried to do this for in some IXP, and in this ‑‑ for some IXP network, we know exactly the mapping because it's public so we can ‑‑ even if it's an IXP dropping it, basically we can come back, oh, it's Google, it's Facebook, whatever, so test one yourself. But right for a few of the ones, for the link to AS to which address it is we don't know. So my point is that there are some packets that say is transit AS drop that are actually destination AS drop? So this is the worst case.
AUDIENCE SPEAKER: The last comment, if you could, like I don't know, add to your website, because I really like to see the result, some clarification of the algorithm because, for example, when you see peering link, you never know actually is it ‑‑ who is dropping packet on this particular point to point link. It might be egress router or ingress router and you never know. So you could not actually reliably say that it was dropped on the destination AS or the previous action because peering link might be a number from address space from both sides or short address if it's Internet exchange.
ERIC VYNCKE: So again, this website has been done last week so give us time to clarify.
AUDIENCE SPEAKER: Thank you. It's very useful. Thanks for that.
AUDIENCE SPEAKER: Eric Matthew from Amazon. Yesterday, we were talking to ‑‑ Greg Hankins' talk was about how difficult it gets as we get to 400 gig and terabit speeds, and so on. If we are going to do cryptographic validation on packets at higher and higher speeds, is that going to work at all? Is that actually just a bit crazy?
ERIC VYNCKE: I have seen the question, of course, you know the reply. Of course, cannot do it cheaply at 40 gig. Now, what you can do is, if you are using segment routing within your own AS, you don't do this. Now if you want to do it it from outside of the AS, what you do of course, you do the HMAC, the HMAC is valid from one source to one destination, so you can build a cache, because you need specific hardware for doing this because it's not there existing line card but the thinking behind it is the first time you receive a new flow you compute the HMAC, if it's okay you cache it and then it will go faster.
AUDIENCE SPEAKER: It just seems an added complication to make things harder and more likely to be ‑‑ because I mean the risk for me is it's some sort of attack from outside, and that seems like a really good vector to attack me from outside, and I still don't understand inside my own network what can I do with this that I can't do with MPLS?
ERIC VYNCKE: Simply you can do the same thing with MPLS, segment routing does exist. Traffic engineering, there's multiple ways of doing this. It's the IPv6 use case, it's mainly when you have an IPv6 only core without any MPLS. Thing about one use case that some customers are talking to us, I have a data centre, a big one, which is IPv6, no MPLS, and I want to to some traffic engineering, there is a reason why we put in this. If you are happy, if your MPLS traffic engineering, right, there is no problem. It's just another arrow in your [] choir.
JEN LINKOVA: Just, I'm just curious, do you think is it the reason for use case for IPv6 only network, does it exist only because I could not run MPLS in IPv6 only network? Or do you think if we finally manage to get, for example, RSVP working in our IPv6‑only network, we do not need this?
ERIC VYNCKE: Or the other way around: If you have this, you do not need RSP for IPv6. It's one or the other basically, right. I do agree.
Okay. No more questions. So. Thank you for your attention.
(Applause)
CHAIR: And before you will go to the coffee break, let me remind that there is a possibility to rate the talk. Your feedback is very important for us, so please rate the talks at RIPE 70 website. Thank you.
(Coffee break)
LIVE CAPTIONING BY MARY McKEON RMR, CRR, CBC
DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.
WWW.DCR.IE
