12. Network Security

The following content is provided under a Creative Commons license your support will help MIT open courseware continue to offer highquality educational resources for free to make a donation or to view additional materials from hundreds of MIT courses visit MIT open courseware at ocw.mit.edu all right guys let's uh get started so today we're going to talk about network security and in particular We're going to talk about this paper on tcpip security by this guy Steve bivin who used to be at AT&T and now is at Columbia um one interesting thing about this paper is it's actually

a relatively old paper it's like more than 10 years old and in fact it's commentary on a paper that was 10 years before that um and uh many of you guys actually asked like why why are we reading this if many of these problems have been solved in today's TCP protocol Stacks so one Interesting point well so so it's true that some of these problems that Steve describes in this paper have been solved since then um some of them are still actually problems today we'll sort of look at that and see um what's going on

um but you might actually Wonder like why didn't people solve all these problems in the first place like when were they were designing TCP what were they thinking and it's actually not clear so what do You guys think why wasn't TCP designed to be secure with all these considerations up front yeah any guesses all right anyone else yeah the internet was a much more trusting place yeah like this is like almost literally a quote from this guy's paper yeah he he at the time the whole internet set of protocols was designed I guess about 40

years ago now uh the requirements were totally different it was to connect a Bunch of relatively trusting sites that all knew each other by name uh and I think this is often the case in any system that becomes successful the requirements change so it used to be that this is a you know a protocol for a small number of sites now it's the entire world and you don't know all the people connected to the internet by name anymore you can't call them up on a phone if they do something bad Etc so I think this

is a story for many of the Protocols we look at and many of you guys have questions like what the hell were these guys thinking this is so broken but in fact they were designing a totally different system that got adopted same for the web like we were looking at in the last couple of weeks it was designed for a very different goal and it extended and you sort of have these growing pains you have to figure out how to make the protocol adapt to new Requirements and another thing that uh somewhat suddenly happened is

I think people people also in the process gained a much greater appreciation for the kinds of problems you have to worry about in security and it used to be the case that you didn't really understand all the things that you should worry about an attacker doing to your system and I think it's partly for this reason that's sort of interesting to look at what happened to TCP security what went Wrong how could you fix it Etc to both figure out what kinds of problems you might want to avoid when designing your own protocols and also

what's the right mindset for thinking about these kinds of attacks how do you figure out what an attacker might be able to do in your own protocol when you're designing it so you can avoid similar pitfalls all right so with that Preamble aside let's actually start talking about what the paper is about so how should we Think about Security in a network so I guess we could try to start from first principles and try to figure out what is our threat model so what do we think the attacker is going to be able to do

in our Network well relatively straightforwardly there's presumably being able to intercept packets and probably being able to modify them so if you send a packet over the Network it might be prudent to assume that some bad guy out there is going to see your packet and might be able to change it before it reaches its destination might be able to drop it and in fact might be able to inject packets of their own that you never sent with arbitrary contents and uh probably so this is you can sort of come up with fairly straightforwardly by

just thinking well you know if you don't trust the network You know some some bad gu is going to send arbitrary packets see yours modify them Etc somewhat more worryingly uh as this paper talks about the bad guy can also participate in your protocols they have their own machine right so the attacker has their own computer that they have full control over so even if all the computers that you trust are reasonably maintained they all behave correctly the bad guy has his own computer that he can make it Do whatever he wants and in fact

he can participate in any protocol or distributed system so if you have a routing protocol which involves many people talking to each other uh at some scale it's probably going to be impractical to keep the bad guys out if you're running a routing protocol with 10 participants then maybe you can just call all them up and say well yeah yeah I know all you guys but at the scale of the internet Today it's infeasible to have sort of direct knowledge of what everyone else or who everyone else in this protocol is so probably some bad

guy is going to be participating in your protocols or distributed systems and it's important to design distributed systems that can nonetheless do something reasonable with that all right so what are the implications of all these things I guess we'll go down the list so intercepting is uh at some level easy to Sort of understand well you know you shouldn't send any important data over the netk work if you expect a bad guy to intercept them or at least not in clear Tex maybe you shouldn't encrypt your data so that seems relatively straightforward to sort of

figure out although still you should sort of keep in mind of course when designing protocols now injecting packets is a turns out to be a much lead to a much wider range of interesting problems that This paper talks about uh and in particular attackers can inject packets that can be pretend to be from any other sender right because the way this works in IP is that the IP packet itself has a header that contains the source of the packet and the destination and it's up to the whoever creates the packet to fill in the right

values for the source and destination and no one checks that the source is necessarily the correct one uh there's some filtering going on These days but it's uh sort of Fairly spotty and it's hard to rely on so to a first approximation an attacker could fill in any IP address as the source and it'll get to the destination correctly and it's interesting to try to figure out like what could an attacker do with such a capability of sending arbitrary packets now in the several weeks up up this like in buff overflows and web security we

Looked at to a large extent implementation bugs like how could you exploit a buffer overflow and interestingly the author of this paper is actually not at all interested in implementation bugs he's really interested in protocol errors or protocol mistakes so what's the big deal why is he down on implementation box even though we spend several weeks looking at them why does it matter yeah because we have to keep this box to be Comp yeah so this is the really big bummer about a bug in your protocol design because it's hard to change so if you

have an implementation bug well you had a mem copy or a printf of some sort that didn't change the range okay well you had a range check and it still works and now it's also secure so that's great but if you have some bug in the protocol specification in how the protocol has to work then fixing a bug is going to require fixing a protocol which means Potentially affecting all the systems that are out there speaking this protocol so if we find some problem in TCP this is potentially quite devastating because every machine that uses

TCP is going to have to change because it's going to be hard to make it potentially backwards compatible we'll see exactly what these bugs are but I think this is the real reason he's so excited about looking at protocol bugs because they're fairly fundamental to The sort of TCP protocol that everyone agrees to speak so let's look at one of these guys so one uh sort of the first example he points out is has to do with how TCP sequence numbers work so just to sort of re explain Yeah question I'm just curious this is

tin off topic yeah let's say you do find a TCP how do you make the change how do you tell all the computers in the World to Change yeah I think it's a huge Problem like what if you find a bug in TCP well it's not clear what to do and I think the authors here struggle a lot with it and in many ways if you could redesign TCP many of these bugs are relatively easy to fix if you knew what to look for ahead of time but because TCP is sort of fixed relatively hard

to fix uh or change um what ends up happening is that people or designers try to look for backwards compatible tweaks that either Allow old implementations to coexist with a new implementation or to add some optional field that if it's there then the communication is more secure in some way um but it is a big problem like if it's if it's some security issue that's deeply ingrained in TCP then it's going to be it's going to be a pretty humongous issue for everyone to just pack up and move on to TCP version you know whatever

n plus1 uh and you know you can look at IPv6 as one example of This not happening right like we've known this prom was going to come up for like 15 years or 20 years IPv6 has been around for well over 10 years now and it's just hard to convince people to move away from ipv4 it's good enough it sort of works it's uh it's a lot of overhead to move over and no one else is speaking IPv6 so why should I start speaking this bizarre protocol that no one else is going to speak to

me to me so it's like slowly moving along but I Think it takes a long time and there's got to be really some motivation to migrate uh and um backwards compatibility helps a lot not good enough for I guess IPv6 IPv6 has lots of backwards compatibility plans in it like you can talk to an ipv4 host from IPv6 so there you know they try to engineer all the support but still it's hard to convince people to upgrade um all right um but yeah so looking back at TCP sequence numbers we're going to look at Actually

two problems that have to do with how the TCP handshake works so let's just spend a little bit of time um working out what are the details of how a TCP connection gets initially established so there's basically three uh packets that have to get sent uh in order for a new TCP connection to be established so a client uh generates a packet to connect to a server and it says well here's my IP address C client I'm sending this to the server and There's various Fields but the ones that are interesting for the purpose of

this discussion is going to be a sequence number so there's going to be a syn flag saying I want to synchronize State and establish a new connection and you include a client sequence number in the initial packet then when the server receives this the server uh is going to look and say well a client wants to connect to me so I'll send a packet back to whatever this address is whoever said They were trying to connect to me so it'll send a packet from the server to the client uh and include its own synchronization number

SN server and it'll acknowledge the client's number and finally the client uh replies back acknowledging the server sychronization number uh acknowledge uh SNS and now the client can actually start sending data so in order to send Data the client has to uh include some data in the packet and also put in the sequence number of the client to indicate that this is actually sort of legitimate client data at the start of the connection it's not some data from later on for example that just happens to arrive now because the server missed some initial parts of

the data so originally all these sequence numbers were meant for uh ensuring inorder delivery of packets so you know if the Client sends two packets the one that has the initial sequence number that's the first chunk of data and the one with the next sequence numb is the next chunk of data but it turns out to also be useful for providing some security properties here's an example of these requirements changing so initially no one was thinking TCP provides any security properties but then applications started using TCP and sort of relying on these TCP connections not

Being able to be broken by some arbitrary attacker or no an attacker not being able to inject data into your existing TCP connection and all of a sudden this mechanism that was initially meant for just packet ordering now gets used to guarantee some semblance of security for these connections so in this case um I guess the problem stems from what could a server I Guess assume about this uh TCP connection so typically the server assumes that or you know implicitly you might imagine the server could assume that this connection is established with the right client

at this IP address C seems like a natural thing to assume is there any basis for making this assumption like should like if a server gets this message saying you know here's some data on this connection from a client to a server and it has sequence Number c why might the server conclude that this was actually the the real client sending this guess the sequence hard to guess right so that's sort of the implicit thing going on that it has to have the right sequence number c here and uh in order for this connection to

got established the client must have acknowledged the server sequence number s here and the server sequence number s was only sent by the server to the Intended client IP address yeah how many bits are available for the sequence number so sequence numbers in TCP are 32 bits long so it's like not entirely easy to guess so if if it was really a random 32-bit number it would be hard to just guess and you'd probably waste a lot of bandwidth trying to guess this yeah question the data sequence number is higher than the initial sequence number

Yeah so basically these things get Incremented so every time you send a sin that counts as one bite against your sequence number so this is snc I think actually what happens is this is snc + one and then it goes on from there so if you send five bytes and the next one is snc initial plus six um so it just counts the bytes that you sent and sins count as one bite each makees sense other questions about this all right so typically um or at least the way the TCP specification recommended that people choose

these sequence numbers was uh to increment them at some roughly fixed rate so the initial RFC suggested that you increment these things at something like 250,000 units just like plus 250,000 per second and the reason that it wasn't entirely random is that these sequence numbers are actually used to prevent out of order packets or packets from previous connections from interfering with new connections so if Every time you establish a new connection you chose a completely random sequence number number then there's some chance if you establish lots of connections over and over that some packet from

a previous connection is going to have a similar enough sequence number to your new connection that's going to be accepted as a valid piece of data on that new connection so this is something that the TCP designers worried a lot about these out of order packets Or delayed packets so as a result they really wanted these sequence numbers to progress in a roughly monotonic manner over time even across connections so if I open one connection it might have the same source and destination port numbers IP addresses Etc but because I established this connection now instead

of earlier packets from earlier hopefully aren't going to match up with the sequence numbers I have for my new connection so this was a mechanism to Prevent confusion across sort of repeated sort of connection establishment yeah so if you don't know exactly like how much you know your other that you're talking to is going to increment the sequence how do you know like the packet you're getting is the next packet if there wasn't some like intermediate packet that so typically you remember the last packet you received and if the next sequence number is exactly that

then This is the next packet in sequence so for example here the server knows that I've seen exactly SN C plus1 worth of data if the next packet has sequence number SN C plus one that's the next one so so you're saying that like when you establish the sequence number then after that you're committing it only oh absolutely yeah yeah yeah so these sequence numbers one initially when you establish it they get picked According to some plan we'll talk about that plan You can sort of think they might be random but over time they have

to have some flow for initial sequence numbers for connection but then within a connection once they're established that's it they're fixed and they just tick along as the data gets sent on the connection exactly make sense all right so there were some plans suggested for how to manage these sequence numbers and it was actually Reasonable plan for avoiding duplicate packets in the network causing trouble but the the problem uh of course showed up that attackers were able to sort of guess these sequence numbers because the SE there wasn't a lot of Randomness being chosen so

the way that the host machine would choose these sequence numbers they have just a running counter in memory every second they bump it by 250,000 and every time a new connection Comes in they also bump it by some constant like 64k or 128k I forget the exact number so this was Rel atively easy to guess as you can tell you send them a connection request and you see what what sequence number comes back and then you know the next one is going to be 64k higher than that so there wasn't a huge amount of Randomness

uh in this protocol so we can just sketch out what this looks like so if I'm an attacker that wants to connect to a server but Pretend to be from a particular IP address then what I might do is send a request to the server very much like the first step there include the some initial sequence number that I choose at this point any sequence number is just as good because the server shouldn't have any assumptions about what the client sequence number is now what does the server do the server gets the same packet as

before so it responds in the same way as before it sends a packet Back to the client with some server sequence number and acknowledges snc and now the attacker if it if the attacker wants to establish a connection it needs to somehow synthesize a packet that looks exactly like the third packet over there so it needs to send a packet from a client to the server that's easy enough you just fill in these values in the header but you have to acknowledge this server sequence number SNS and this is Where sort of the pr start

if the SNS value is relatively easy to guess then the attacker is good to go and now the server thinks they have an established connection with a client coming from this IP address and now an attacker could inject data into this connection just as before they just synthesize a packet that looks like this that has the data and it has the client sequence number that in fact the adversary chose maybe it's plus one Here but it all hinges on being able to guess this particular server supplied sequence number all right does this make sense yeah

what's the reason that the server sequence number isn't completely random so there's two reasons one as I was uh describing earlier uh the server wants to make sure that packets from different connections over time don't get confused for one another so if you establish a connection from One Source port to Another destination port and then you close the connection establish another one with the same source and destination Port you want to make sure the packets from one connection don't appear to be valid in another connection does the server so the the server sequence number is

incremented for every one of their packets well so this is the sequence number so this the sequence numbers within a connection as I was describing get bumped with all the data in a Connection but there's also the question of how do you choose the initial sequence number here and that gets bumped for every time a new connection is established so the hope is that by the time it wraps around 2 to the 32 and comes back that there's been enough time so that all old packets in the network have actually been dropped and will not

appear as duplicates anymore so that's the reason why they don't just choose random points or they didn't initially Choose random points yeah this is a problem between connections for a connection between the same guy the same time the same server the same Source Port the same destination that's right and you're worried about old pack this is what the original yeah TCP designers were worried about which is why they prescribe this way of picking these initial sequence numbers different new connections you could differentiate that's right yeah so Then I don't see why the incrementing stuff and

not just pick randomly so I think the reason they don't pick randomly is that if you did pick randomly and you established I don't know a thousand connections within a short amount of time from the same source to the same destination then um well every one of them is some random value module 2 to the 32 and now there's a non-trivial chance that some packet from one connection will be delayed in The network and eventually show up again and will get confused for a packet from another connection this is just sort of not not nothing

to do with security this was just their design consideration initially for uh reliable delivery yeah this isend to be some other client to the server sorry this is this is attack some other Cent that's right yeah so we haven't actually said why this is interesting at all for the attacker to do like why Bother he could disc connect from his own IP address right so what happens like for the server like uh what happens to the other computer like who a is pring to be and he receives an ask something he never said yes this

is actually an interesting question like what happens here right so this packet doesn't just get dropped it actually goes to this computer and what happens yeah in the pi they just mentioned like you try and do it like they would try And do it when the other computer was like updating or rebooting or off or something right certainly if those other computer is offline the packet will just get dropped and you don't have to worry about it too much if a computer is actually listening on that IP address then in the TCP protocol you're supposed

to send a reset packet uh resetting the connection because this is not a connection that the computer C knows about and in TCP this is presumed to be Because this is some old packet that I you know requested long ago but I've since forgot about it so the machine C here might send a packet uh to the server saying I want to reset uh you know I actually I forget exactly which sequence number goes in there but the uh client C here knows all the sequence numbers and can send any sequence number as necessary and

reset this connection so if this computer C is going to do this then it might interfere with your Plan to establish a connection because when s gets this packet it says oh sure if you don't want it I'll reset your connection uh there are some implementation is bugs that you might exploit to or at least the author talks about an adversary potentially exploiting that would prevent client C from responding so for example if you flood C with lots of packets that's an easy way to get them to drop this one it turns out there's other

more interesting Bugs that don't require flooding C with lots of packets that still get C to drop this packet or at least it used to on some implementations of TCP Stacks yeah presumably those firewalls would also that this one no the sin this that came into a client and the client didn't originally send a s to that server then the fire is Dr I depends yeah so certainly if you have a very sophisticated stateful firewall that keeps track of all existing Connections or for example if you have a natat then this might happen on the

other hand that aat might actually send the rst on the behalf of the client um so it's not clear I think this is not as common so for example on a Comcast network I certainly don't have anyone intercepting these packets and maintaining state for me and sending rsts on my behalf or anything like that yeah so why can the server have independent um sequence numbers for each Like possible Source right so so actually this is in fact what TCP Stacks do today so this is one example of how do you fix this problem in a

backwards compatible manner uh so we'll get to exactly the formulation of how you arrange this but yeah it turns out that if you look at this carefully as you doing you don't need to have the initial sequence number be Global you just scope it to every Source destination pair and then you have all the duplicate Avoidance properties we had before and you have some security as well so just to sort of uh write this out on the board of like how the attacker is getting this initial sequence number the attacker would probably just send a

connection from its own IP address to the server saying I want to you know establish a new connection and the server would send a response back to the attacker containing its own sequence number s and if these SNS for this Connection and the SNS for this connection are related then this is a problem but you're saying let's make them not related because this is from a different address then this is not a problem anymore you can't guess what this SNS is going to be based on this SNS for a different connection yeah you still have

a collision problem because you could engage with 32 bits of IP address your your PE so you have a lot of cords for each one of these you still Have conflicting sequence numbers for all of these connections that you get so these uh sequence numbers are specific as it turns out to an IP address and a port number Source destination Tuple so if it's different ports then they don't interfere with each other at all oh because you're using the port that's right yeah you also use the port in this plan as well yeah right yeah

so the ports are sort of below the sequence numbers if in some way of thinking about It yeah question but if the sequence numbers are Global then doesn't theing depend on cents are yeah good point yeah so in fact if the server increments the sequence number by I don't know 64k I think it is or it was for every connection then well you connect and then maybe five other people connect and then you have to do this attack so to some extent you're right this is a little Troublesome on the other hand you Could probably

arrange it for your packet here to be delivered just before this packet so if you send these guys back to back then there's a good chance they'll arrive at the server back to back the server will get this one respond with this sequence number it'll get the next one this one respond with the sequence number right afterwards and then you know exactly what to put in this third packet in your Sequence so I think this is not a foolproof method of connecting to a server there's some guessing involved uh but if you careful arrange your

packets right then it's quite easy to make the right guess or maybe you try several times and you'll get lucky yeah even if like you know it's totally random and you have to guess it there only like 4 billion possibilities it's not like a huge number right like I feel like in the course of a year you should be able To like probably right yeah so I think it uh so you're absolutely right you shouldn't really be relying on TCP to provide security uh you know very very strongly because you're right it's only 4 billion

guesses and you can probably send that many packets you know certainly within a day uh if you have a fast enough connection um so it's sort of an interesting argument we're having here in the sense That at some level TCP is hopelessly insecure because it's only 32 bits there's no way we could make it secure but I think many applications rely on it enough that not providing any security at all is so much of a nuisance that it really becomes a a problem but absolutely right so in practice you do want to do some sort

of encryption on top of this that will provide stronger guarantees that no one tampered with your data that where the keys are more Than 32 bits long um but so still turns out to be useful to prevent people from tampering with TCP Connections in most cases all right other questions all right so let's see what actually goes wrong why is it a bad bad thing if people are able to spoof TCP connections from arbitrary addresses so one reason this is bad is uh if there's any kind of Ip Based uh authorization so if some server

decides whether an operation is going to be allowed or not based on the IP address it comes from then this is potentially going to be a problem for an attacker to spoof connections from an arbitrary Source address so one example where this was a problem and it largely isn't anymore is this family of commands or things like our login so it used to be the case that you could run Something like our login into a machine let's say I don't know Athena Diop mit.edu and if your connection was coming from a host at MIT then

this art login command would succeed if you say oh yeah I'm user Alice on this machine let me log in as user Alice onto this other machine and it'll just trust that all the machines that mitu are trustworthy to make these statements uh I should say right like Athena dialup never actually Had this problem it was using Kerberos from the very beginning but uh other systems uh certainly did have such problems and this is an example of using the IP address where the connection is coming from as some sort of a authentication mechanism for whether

the caller or the client is trustworthy or not this is certainly used to be a problem isn't a problem anymore so relying on AP seems like a such a clearly bad plan yet this actually is Still the case right so our login is gone it's basically replaced by SSH now so that's good um on the other hand there's still many other examples of protocols that rely on IP based authentication one of them is SMTP so when you send email use SMTP to talk to some mail server to send a message and to prevent spam many

SMTP servers will only accept incoming messages from a particular Source IP address so for example Comcast mail server will only Accept mail from Comcast IP addresses same for MIT mail servers will only accept mail from MIT IP addresses or there's at least one server that is&t runs that has this property um so this is a case where it's still the you know using IP based authentication um here it's not so bad right like worst case you'll send some piece of spam through a mail server so this is probably why they're still using it whereas things

that allow you to log into an arbitrary Account stopped using IP based authentication soes this make sense why is a bad plan and just to double check right so so suppose that some server was using our login what should you do to attack it like what what bad thing would happen any suggestions yeah just get it new computer and then like make a user that you want to log into and then the network yeah so you basically yeah you get your computer you synthesize this Data to look like a legitimate set of R login commands

that say oh log in as this user and run this command in my shell there you sort of synthesize this data and you mount this whole attack and send this data as if a legitimate user was interacting with a our login client and then you're good to go yeah absolutely okay so this is one reason why you probably don't want uh you know your TCP sequence numbers to be so guessable another problem is these uh Reset attacks so uh you could much like we were able to send a sin packet uh if you know someone's

sequence number you could also send a reset packet we sort of briefly talked about it here as the legitimate client potentially sending a reset to reset the fake connection that that hacker is establishing but in a similar vein the adversary could try to send reset packets for an existing connection if there's some way that the adversary Knows what your sequence number is on that connection so this is actually not clear if this is such a big problem or not at some level maybe you should be assuming that all your TCP connections could be broken at

any time anyway it's not like the network is reliable so maybe you should be expecting your connections to drop but one place where this turned out to be particularly not a good assumption to Make is in the case of routers talking to one another so if you have multiple routers that uh speak some routing protocol then they're connected of course by some physical links but over these physical links they actually speak some Network protocol and that Network protocol runs over TCP so there's actually some TCP session running over each of these physical links that the

routers use to exchange routing information so this is certainly the Case for this protocol called bgp we'll talk about it a bit more in a second and bgp uses the fact that the TCP connection is alive to also infer that the link is alive so if the TCP connection breaks then the routers assume the link broke and they recompute all the routing tables so if an adversary wants to mount some sort of a denial of service attack here they could try to guess the sequence numbers of these routers and Reset these sessions so if the

TCP session between two routers goes down the entire rout both routers decide oh this link is dead we have to recompute all the routing tables and the routes change and then you might shoot down another link and and so on so a bit of a worrisome attack not because it sort of violates someone's you know secrecy Etc but or at least not directly but more because it it really causes a lot of uh you know availability problems for other Users in the system yeah so if you're an attacker could you just uh and you wanted

to Target one particular user could you just uh keep keep sending uh connection requests to a server on his IP and just making to keep droing connections to those servers and so you just accessing certain things well so uh it requires you guessing so you're saying oh suppose I'm using Gmail and you want to stop me from learning something in Gmail you'll just send Packets to my machine pretending to be from Gmail well you have to guess the right source and destination port numbers the destination port number is probably 443 because I'm using hgps but

the source port number is going to be some random 16bit thing and it's also going to be the case that probably the sequence numbers are going to be different so unless you guess a sequence number that's within you know my TCP window which is you know in the order of You know probably tens of kilobytes you're also going to be not successful in that regard so you have to guess fair amount of stuff that uh there's no sort of Oracle access to you can't just query the server and say well what is that guy sequence

number uh so that's the reason why that doesn't work out as well yeah um so again right many of these issues were fixed including this rst based thing especially for bgp routers um the fix there's actually two sort of amusing Fixes one really shows you how you can like carefully exploit existing things or take advantage of them to fix particular problems here the Insight is that these routers only want to talk to each other not to someone else over the network and as a result if the packet is coming not from the immediate router next

across the link but from someone else I want to drop this pack packet all together and what the designers of these routing protocols realized is that There's this wonderful field in a packet called time to live it's an 8 bit field that gets decremented by every router to make sure that packets don't go into an infinite Loop so the highest the CTL value could ever be is 255 and then it'll get decremented from there so what these routing protocols do as sort of a clever hack is they only accept or uh they reject any packet

with a TTL value that's not 255 because if a packet has the value 255 it must have come from the router just to the other side of this link and if an adversary tries to inject any packet to tamper with this existing bgp connection it'll have a TTL value less than 255 because it'll be decremented by some other routers along the path or including this one uh and then it'll just get rejected uh by the recipient so this is one example of a sort of a clever combination of techniques that's backwards compatible and solves this

Very specific problem yeah the bottom right router also s something yeah so these routers are actually this is a physical router and it knows these are separate links so it looks at the TTL value and which link it came on uh so if a packet came in on this link it will not accept it for this uh TCP connection but you're right for the most part these routers trust their immediate neighbors need not necessarily be the case but if You keep seeing this prom and you know you've implemented this hack then it must be one

of your neighbors you're going to like look at TCP dump these interface well why why are you said me these reset packets so think at this prom it's not as big you can manage it by some out of band mechanism make sense all right there's other fixes for bgp that they implemented some form of header authentication md5 header authentication as well um but they're Really targeted at this particular application where this reset attack is particularly bad but there's actually still a problem today right if I want if there are some long LIF connection out there

that I really want to shoot down I just have to send you know some large number of rst packets probably on the order of you know hundreds of thousands or so but probably not exactly 4 billion uh because the servers are actually somewhat lack in terms of which sequence Number they accept for a reset it can be any packet within a certain window and that case I could probably you know or any attacker could reset an existing connection with you know a modest but not a huge amount of effort that's still a problem uh and

people haven't really found any great solution for that sense all right and I guess the sort of last uh bad thing that happens because these sequence numbers are somewhat Predictable is just uh data injection into existing connections so suppose there's some protocol like you know our login but you know maybe our login doesn't you know some suppose we have some hypothetical protocol that's kind of like our login but actually doesn't do IP based authentication you have to type in your password to log in all this great stuff but the problem is once you've typed your

password Maybe maybe your TCP Connection is just established and can accept arbitrary data so I'll wait for one of you guys to log into a machine type in your password I don't know what that password is but once you've established a TCP connection I'll just try to guess your sequence number and inject some data into your existing connection so if I can guess your sequence numbers correctly then this allows me to make it pretend like you've typed some command after you Authenticated correctly with your password so this all sort of suggest that you really don't

want to rely on these uh 32 byte or 32 bits sorry um sequence numbers for providing security uh but let's actually see what modern TCP Stacks actually do to try to mitigate this problem so as we were sort of discussing I guess one approach that we'll look at in the next two lectures is how to implement some security at the application Level so we'll do some use Cryptography to authenticate and encrypt and sign and uh verify messages at the application Level Without Really involving TCP so much but uh there are sort of existing applications that

would benefit from making this slightly better um at least not make it so easy to exploit these problems um and the way that I guess people do this uh in practice today for example Linux and windows is they implement the suggestion that sort of John gave earlier um that We maintain different initial sequence numbers for every Source destination pair so what uh most sort of TCP sin implementation ations do um is they still compute this initial sequence number uh as we were Computing before so this is the old style Isn let's say and in order

to actually generate the actual Isn for any particular connection we're going to add a random 32-bit offset so we're going to include some sort of a function think of It as like a hash function like shaan or something maybe better uh and this is going to be a fun of the source IP The Source port number the destination IP address destination port and some sort of a secret key that only the server knows in this case so this has the nice property that within any particular connection as identified by a source and destination IP port

pair it still preserves all these nice Properties of this old style sequence number algorithm had but if you have connections from different Source destination tupal then there's nothing you can learn about the exact value of another connection tupal sequence number and in fact you have to you would have to guess this key in order to uh infer that value and hopefully the server presumably the OS kernel stores this key somewhere in its memory and doesn't give it out to anyone else so this is how Pretty much most TCP Stacks deal with this particular problem today

to the extent Allowed by the sort of total 32-bit sequence number it's not great but sort of works yeah you repeat that again like is the key unique to so so when my machine boots up or when every machine boots up it just generates a random key every time you reboot it it generates a new key and this means that every time that for a particular Source destination pair the sequence numbers Advance at the same rate as control this so for a given Source destination pair this thing is fixed so you observe your sequence numbers

evolving Accord your initial sequence numbers for new connections evolving according to a particular algorithm so that still provides all these defenses against re uh old packets from previous connections being injected into new connections just like packet reordering Problems so that still works and that's the only real thing for which we needed this sequence number choosing algorithm to prevent these duplicate pack from causing problems however the thing that we were exploiting before which is that if you get the sequence number for one connection from s to a or from a to S sorry then you from

that you can infer the sequence number for a different connection that's now gone because every connection has a different offset sort Of in this 32bit space as implemented by its F function so this completely decouples the of sequence initial sequence numberb seen by every connection yeah what's the ining the key well if you don't include the key then I can connect to you I'll compute the same function f I'll subtract it out I'll get this I'll compute this function f for the connection I actually want to fake and I'll guess what the initial Sequence number

for that one is going to be so can you because machines now restart infrequently can you still reports what the key should be by reversing I think uh typically this function f is something like a cryptographically secure hash function which has a semi prooved property that it's very difficult it's cryptographically hard to invert it so even if you g were given the literal inputs and outputs of this Hash function um well sorry if you were giving uh the outputs of the inputs and outputs of the cash except for this key part it would be very

hard for you to guess what this key is like cryptographically even in an isolated setting so hopefully this will be at least as hard in this setting as well um so we'll talk a little bit more about what these functions f are a bit later on and how you use them correctly make sense other questions About this particular problem and solution all right so in fact so this is mostly sort of an example of these TCP sequence number attacks that you know aren't as relevant anymore because every operating system basically implements this plan these days

so it's hard to infer what someone sequence number is going to be on the other hand people keep making the same mistakes so uh even after this was implemented for TCP um there's this other protocol called DNS That is hugely vulnerable to similar attacks um and the reason is that DNS actually runs over UDP so UDP is a stateless protocol where you actually don't do uh any connection establishment where you exchange sequence numbers in UDP you simply send a request from your Source address to the server and the server figures out what the reply should

be and sends it back to whatever Source address appeared in the packet so there's no time to Really exchange or it's a single round trip so there's no time to exchange sequence numbers and to establish that you ah yeah you're actually talking to the right guy so with DNS um as a result uh for a while it was quite easy to fake responses from a DNS server so how would a query look like in DNS typically well you send some query so suppose a client sends a packet from client to some DNS server so it

knows the DNS server's IP address ahead of time maybe Preconfigured somewhere saying well here's my query maybe you know I'm looking for mit.edu and that's basically it and the servers destination port number is always 53 for DNS and the clients used to also run on the same port number for ease of use or something so you send this packet from the client on this port to the server on this port here's the query and the server eventually sends back reply saying you know mitu has a Particular IP address 18.9 something the problem is that some

adversary could easily send a similar response packet pretending to be from the server and there's not a whole lot of Randomness here so if I know that you're trying to connect to mitu I'll just send a lot of packets like this to your machine I know exactly what DNS server you're going to query I know exactly what your IP address is I know the port numbers I know what you're Querying for I can just Supply my own IP address here and if my packet gets there after you send this but before you get the real

response your client machine is going to use my packet so this is another example where not insufficient Randomness in this protocol makes it very easy to inject responses or inject packets in general and this actually some ways even worse than the previous attack because here you could convince a client to Connect to another IP address altogether and it'll probably cach this result because DNS involves caching maybe you can supply a very long time to live in this response saying this is valid for years and then your client maybe until it reboots is going to keep

using this IP address for MIT to ddu yeah you fix this by having a client include some random value in theery and the server has to it exactly that's right yeah so this is typically what people have done Now the problem as we were sort of talking about earlier is backwards compatibility uh it's very hard to change the DNS server software that everyone runs so you basically have to figure out where can you inject Randomness and people have figured out two places it's not great but basically there's a source port number which is 16 bits

of Randomness so if you can choose the source port number randomly then you get 16 bits and there is also a query ID inside of the packet which is also 16 bits and the server does Echo back the query ID so combining these two things together most resolvers these days get 32 bits of Randomness out of this protocol and it again makes it noticeably harder but still not cryptographically perfect uh to fake this kind of response and have it be accepted by the client um but so these problems keep coming up unfortunately Even though it

was well understood for TCP people didn't well some people I guess suggested this might be a problem but it wasn't actually fixed until uh only a few years ago make sense all right so I guess uh maybe as on as side right there are solutions to this DNS problem as well by enforcing security for DNS at the application Level so instead of relying on these Randomness properties of small you know Numbers of bits in the packet um you could try to you know use encryption in the DNS protocol so protocols like DNS SEC that the

paper sort of briefly talks about try to do this so instead of relying on any network level security properties they require that all DNS names have signatures attached to them that seems like a sensible plan but it turns out that working out the details is actually quite difficult so one example of U sort of a problem that Showed up is name enumeration because in DNS you want to get responses well this name has that IP address or you could get a response saying no so sorry this name doesn't exist so you you want to sign

that don't doesn't exist response as well because otherwise an adversary could send back a doesn't exist response and pretend that like a name doesn't exist even though it does so how do you sign responses that certain names don't exist ahead of time I guess one Possibilities you could give your DNS server the key that signs all your records that seems like a bad plan because then someone that compromises your DNS server could walk away with this key so instead the model that DNS SEC operates under is that you sign all your names in your domain

ahead of time and you give this signed blob to your DNS server and the DNS server can then respond to any queries but even if it's compromised there's not much else that That hacker can do all these things are signed and the key is not to be found on the DNS server itself so the DNS St protocol had this clever mechanism uh called nsec for signing nonexistent records and the way to do this is by signing gaps in the namespace so it might say well um an nsec record might say well there is a name

called food. mit.edu and the next uh name alphabetically is uh maybe go mit. and there's nothing Alphabetically in between these two names so if you query for a name between these two names alphabetically sorted then the server could send back this signed message saying oh there's nothing between these two names you can safely return doesn't exist but then this allows some attacker to completely enumerate your domain name you could just ask for some domain name and find this record and say oh yeah great so these two things exist let me query for You know Goa

mit. that'll give me a response saying what's the next name in your domain Etc so it's actually a little bit hard to come up with the right protocol that both preserves all the nice properties of DNS and um prevents name enumeration and other problems there's actually a nice thing now called nsec 3 that tries to solve this problem partially sort of works not um we'll see I guess what gets adopted yeah is there any kind of signing of Non-existent top level domains yeah I think actually yeah the the dot domain is just another domain and

they similarly have this mechanism implemented as well so actually Dot and com now Implement DNS SEC and there's all these records there that say well you know dot you know in is a domain name that exists and Dot you know something else exists and there's nothing in between uh so there's all these signatur other than denal service Why do we care so much about domain names within MIT well probably we don't like actually there's a text file in MIT in AFS that lists all these domain names at MIT anyway but I think in general some

companies feel a little uneasy about revealing this uh they often have internal names that sit in DNS that aren't actually ever should should never be exposed to the outside I think it's actually this fuzzy area where it was never really formalized What guarantees DNS was providing to you or was not and people started assuming things like well if we stick some name and it's not really publicized anywhere then it's probably secure here I think this is another place where this system doesn't have a clear spec in terms of what it has and doesn't have to

provide and when you make some changes like this then people say ah yeah I was sort of relying on that why not yeah like a replay attack where like You could send in Old Gap signature yeah there's actually timeouts on these things so when you sign this I I'm say you actually sign and say I am signing that this uh sort of set of names is valid for know a week and then the clients if they have a synchronized clock then they can reject old signed messages sense all right so um so this is on

the sort of TCP Sin Sin you know guessing attacks um another interesting problem That also comes up in the TCP case uh is a denial of service attack that exploits the fact that the server has to store some state so if we look at this uh handshake that uh we had on the board before we'll see that when a client establishes a connection to the server the server um has to actually remember this sequence number snc so the server has to maintain some data structure on the side that says for this Connection here's the sequence

number and it's going to say well you know my connection from C to S has the sequence number SN C and the the reason the server has to store this table is because the server needs to figure out what snc value to accept here later does this make sense always also needs uh yeah the server also needs SNS I guess yeah so Yeah y absolutely but it turns out that well yeah you're right and the problem is that actually yeah you're right SNS is actually much more important sorry yeah but yeah it needs to store

both absolutely uh SNS is actually much more important because SNS is how you know that you're talking to the right guy uh yeah uh the problem is that there's no real bound on the size of this table so You you you might get packets from some machine you don't even know who sent it you just get a packet that looks like this with a a source address that claims to be C and in order to potentially accept a connection later from this IP address you have have to create this table entry and these table entries

are somewhat long lived because maybe someone is connecting to you from a really far away place there's lots of packet loss so it might be not not for You know maybe a minute until someone finishes this TCP handshake in the worst case so you have to store this state in your TCP stack for a relatively long time and there's no way to sort of guess whether this is a valid connection attempt or not so one denial of service attack that people discovered against most TCP Stacks is to Simply send lots of packets like this so

if I'm an attacker then I'll just send lots of syn packets to a Particular server and get it to fill up its table uh and the problem is that you know in in the best case maybe the attacker just always uses the same Source IP address in that case you can just say well you know every client machine is allowed you know two entries in my table or something like this and then you know the attacker can use up two table entries but not much more the problem of course is that the attacker can fake

these client IP Addresses make them look random and then for the server it's going to be very difficult to distinguish whether this is a attacker trying to connect to me or some client I've never heard of before so if you're some website that's supposed to accept connections from anywhere in the world this is going to be a big problem because either you deny access to everyone or you have to store state for all these mostly fake connection attempts that makes Sense so this is a bit of a problem for TCP and in fact for most

protocols that allow some sort of connection initiation and the server has to store state so there are some fixes we'll talk about in a second what workaround TCP implements to try to deal with this problem this is called sin flooding uh in TCP uh but in general this is a problem that's worth knowing about and trying to avoid in any protocol you design on top as well so you want to make sure that the server Doesn't have to keep State until it can actually authenticate and identify who is the client because by that time if

you identified who the client is you've authenticated them somehow then you can actually make a decision well every client is allowed to only connect once or something and then I'm not going to keep more State here the problem is you're guaranteeing that your store State before you have any idea who it is that is connecting to You so let's look at how you can actually solve this uh sin flooding attack where you can where the server accumulates lots of state so of course you know if we could change gcp again you could fix this pretty

easily by well I don't know using cryptography or something or CH changing exactly who's responsible for storing what state but the problem is we have TCP as is and could we fix this problem without changing the TCP wire protocol so this Is again sort of an exercise in trying to figure out well what exactly could we what what tricks we could play or exactly what assumptions we could relax and still sort of stick to the TCP header format and other things and the trick is to in fact figure out a clever way to make the

server stateless without having to so basically the server isn't going to have to keep this table around in memory and the way we're going to do this is by carefully choosing SNS instead of using this formula we were looking at before where we would add this function we're instead going to choose this uh sequence number in a different way and here's the sort of I'll give you exactly the formula and then we'll talk about why this is actually interesting and what nice properties it has so if the server detects that it's under this kind of

attack it's going to switch into this mode where it chooses SNS uh using this formula uh of um sort of applying basically the same or similar kind of function f we saw before uh and what it's going to apply to is the source IP you know destination IP the same things as before source Port destination port and also a time stamp and uh you know also a key in here as well and we're going to concatenate it With a time stamp as well so this time stamp is going to be fairly coarse grained it's going

to be on order of minutes so it's you know every minute the time stamp ticks up by one it's a very coarse grain time um and you know there's probably some split uh between this part of the header and this part of the header this time stamp doesn't need a whole lot of bits so I forget exactly what this protocol does in real machines but you could easily Imagine maybe using eight bits for the time stamp and maybe using 24 bits for this chunk of the sequence number all right so why is this a good

plan like what what's going on here why this weird formula so I think we have to remember what was the property that we were trying to achieve with the sequence number so there's two things going on one was that this defense against duplicated packets that we were trying to achieve By maybe the formula is still here nope oh yeah yeah here right so just to compare these guys so when we're not under attack we were previously maintaining this old style sequence number scheme to prevent duplicate packets from previous connections all this good stuff turns out

people couldn't figure out a way to defend against these kinds of sin flooding attacks without giving up on this property so basically saying Well you know here's one plan that works well in some situations here's a different plan where we'll give up on that Isn old style component and instead we'll focus on just ensuring that if someone presents us this sequence number s in response to a packet like here then we know it must have been the right client so remember that in order to prevent IP spoofing attacks we sort of rely on this SNS

value so if the server sends this SNS value to some client then Hopefully only that client can send us back the correct SNS value and finish establishing the connection and this is why we had to store it in this table over here because otherwise how do we know if this is a real response or fake response and the reason for using this function f here is that now we can maybe not store this table in memory and instead when a connection attempt arrives here we're going to compute SNS according to this formula over here and

Just send it back to whatever client pretends to have connected to us and then we'll forget all about this connection and then if this third packet eventually comes through and its SNS value here matches what we would expect to see then we'll say oh yeah this must have been someone got our response from step two and finally sent it back to us and now we finally commit after step three to storing a real entry for this TCP connection in Memory so this is a way to sort of defer the storage of the state at the

server by requiring the server the client to Echo back this exact value and by constructing it in this careful way we can actually check whether the client just made up this value or if it's the real thing we were expecting does that make sense yeah yeah so snc now we basically we don't store it it's maybe not great uh but uh so it is yeah so in fact in I Guess what what really happens is that um in um I didn't show it here but there's probably going to be a sort of a null data

field here that says this packet has no data but it still includes the sequence number SN C just because there's a field for it so this is how the server can reconstruct what this snc value is because the client is going to include in this packet anyway it wasn't Relevant before but it sort of is relevant now and we're not going to check it against anything but turns out to be pretty much good enough right it has some unfortunate consequences like if this sence well there are some complicated things you might abuse here but it

doesn't seem to be that bad uh it seems certainly better than the server filling up its memory and stopping serving requests altogether um but yeah And and we don't include it in this computation because the only thing we care about here is offloading the storage of this table and making sure that the only connections that eventually do get established are legitimate clients because then hopefully we can say well you know if this client is establishing a million connections to me I'll I'll stop accepting connections from him that's easy enough finally uh the problem is That

all these Source addresses of there spoofed are hard to distinguish from legitimate clients make sense yeah would you need to score time stamp ah so the clever thing the reason this time stamp is sort of on the side here is that when we receive this SNS value in step three we need to figure out how to compute how do you compute the input to this function f to check whether it's correct so we actually we take the time stamp from the end of the packet and we use That inside of this uh computation everything else

we can reconstruct we know who just sent us that third step in packet we have all these fields we have our key which is again still secret and this time stamp just comes from the end of the sequence number from the last eight bits and then it might be that we'll discard time we reject time stamps that are too old uh just to thisw Old connections yeah so I'm guessing the reason you only use this when you're Under attack is because you lose eight bits of security or whatever yeah so it's not great right like

it has many bad properties one is you lose sort of lose eight bits of security in some sense because now the unguessable part is just 24 bits instead of 32 bits um another problem is what happens if uh you lose certain packets so um if this packet is lost uh so typically in TC p uh there's someone responsible for retransmitting something if a particular Packet is lost and in TCP if the third packet is lost then the client might not be waiting for anything or sorry maybe the protocol we're writing on top of this TCP

connection is one where the server is supposed to say say say something initially so I connect I just listen and the server sends you know in SMTP for example the server is supposed to send me some sort of a initial greeting in the protocol so okay suppose I'm connecting to an SMTP server I send My third packet I think I'm done I I'm just waiting for the server to tell me you know greetings this is an sppp server please send mail this packet could get lost and in real TCP the way this gets handled is

that the server from step two remembers that hey I send this response I never heard back this third thing so it's the server that's supposed to resend this packet to trigger the client to resend this third packet of course if the server isn't Storting any state it has no idea what to resend so this actually makes connection establishment potentially uh problematic where you could enter this weird state where both sides are waiting for each other well the server doesn't even know whether it's waiting for anything and the client is waiting for the server but the

server basically dropped responsibility by not starting state so this uh this is another reason why you Don't run this in production mode all the time yeah presumably also you could have data comms if you have two if you establish two very short connections right after each other from the same absolutely yeah so another thing is of course because we gave up on using this Isn old style part we now give up protection against these multiple Connections in a short time period being in independent from one another so I think there's a number of trade-offs Like

we just talked about three there's several more things you worry about uh but uh it's not great right like if we could design a parle from scratch to be better we could just have a separate you know nice you know 64-bit header for this and a 64-bit value for this and then we could enable this all the time without giving up the other stuff stuff and all these nice things but yeah just have on the SS St two and do they have to be the Thing this SNS and this SNS yeah because otherwise you have

no idea if the server has no way to conclude that this client got our packet if if the server didn't check that this SNS was the same value from before then these attacks would be even worse because I could fake a connection from some arbitrary IP address then you know get this response maybe I don't even get it because it goes to a different then I establish a connection from some other IP address And then the server is maintaining a whole live connection probably a server process on the other side waiting for me to send

data and and so on but the t is going to be different right so like how can like the server recalculate that with a new time St and now the one before if it doesn't any St so the way this works is this time stamp as I was saying our course grains that are on a scale of minutes so if you connect within the same minute then you're in Good shape and if you connect at a minute boundary well too bad I mean the server like yet another problem with the scheme it's imperfect in many

ways but most operating system including Linux actually have ways of detecting if there's too many entries building up in this table that aren't being completed it switches to this other scheme instead to make sure it doesn't overflow this table yeah uh so if the attacker has Control of a lot of IP addresses and they do this and even if you switch it the yeah so then actually there's not much you can do right then uh the reason that we were so worried about the scheme in the first place is because we wanted to filter out

or somehow distinguish between the attacker and the good guys and if the attacker has more IP addresses and just controls more machines than the good guys then he can just connect to our server and request Lots of web pages or maintain connections and it's very hard then going to be for the server to distinguish whether these are legitimate clients or just the attacker tying up resources the server so you're absolutely right that this only addresses the case where the attacker has a small number of IP addresses and wants to amplify his effects uh but it

is a worry and in fact you know today it might be that some attackers control a Large number of compromised machines like you know just dustop Machines of someone that didn't you know patch their machine correctly and then they could just Mount denial of service Stacks from this distributed set of machines all over the world uh and that's pretty hard to defend against um so another actually interesting thing I want to uh mention is uh denial of service attacks but in the in this in the particular way that Network Protocols make them worse um I

guess Network protocols allowed an Al service XX in the first place sorry uh but there are some Network protocols that are particularly susceptible to abuse uh and probably a good example of that is again this DNS protocol that we were looking at before so the DNS protocol we still have it here involves the client sending a request to the server and the server sending a response back To the client and in many cases the response is larger than the request the request could be just tell me about mit.edu and the response might be all the

records the server has about mitu the email address the mail server for mitu assigned record if it's using DNS SEC and so on so the query might be 100 bytes the response could well be over 1,000 bytes so suppose that you want to flood Some some guy with lots of packets or lots of bandwidth well you might only be able to send a small amount of bandwidth but what you could do is you could fake queries to DNS servers on behalf of that guy so you only have to send 100 bytes to some DNS server

pretending to be a query from that poor guy and the DNS server is going to send a thousand bytes to him on your behalf so this is a problematic feature of this protocol because it allows you to amplify Bandwidth attacks and partly for the same reason we're talking about with TCP sin flooding attacks it's very hard for the server for the DNS server in this case to know whether this request is valid or not because there's no authentication or no sort of sequence number exchanges going on to tell that this is the right guy connecting

to you Etc so in fact this is actually still a problem in DNS today and it actually Gets used quite frequently to attack people with bandwidth attacks so if you have a certain amount of bandwidth you'll be that much more effective if you reflect your attack off of a DNS server and these Ro DNS servers are very well provisioned and they basically have to respond to every query out there because if they stop responding to requests then probably some legitimate requests are going to get dropped so this is a big problem in practice Yeah So

if you can s State on the DNS server is reasonable to say that the victim will never send this many DNS requests or never reply to right yeah so it's possible to maybe modify the DNS server to keep some sort of State like this that's the reason why this board still works now because they don't sort State yeah well I think people are starting to modify DNS servers to try to store State on the other hand there's so many DNS servers out there that it doesn't matter Even if you appear to do you know 10

queries against every DNS server but still every packet gets Amplified by you know some significant factor and they have to respond because maybe that client really is trying to issue this query um so this is the problem yeah so you're right if this was one DNS server then this would be maybe not as big of a deal the problem is also that the root servers for DNS for example aren't a single machine it's actually you know Racks and racks of servers because they're so heavily used and trying to maintain the state across all these machines

is probably nontrivial so you know as it gets abused more probably it'll be more worthwhile to maintain this state but uh here's another I guess a general principle you want to follow in sort of any protocol is well might be a good principle um is to make the client do at least as much work as the server is doing so here the problem is The client isn't doing as much work as the server and that's why the server can help the client amplify this attack if you were redesigning DNS from scratch and this was really

your big concern then it would probably be fairly straightforward to fix this the client has to send a request that's has you know extra padding bites just there just wasting bandwidth and then the server is going to respond back with a response that that's at most as big as that and If you wanted a response that's bigger maybe the server will say sorry your padding wasn't big enough send me more padding and this way you guarantee that the DNS server cannot be used ever to amplify these kinds of bandwidth attacks so there's some some and

there actually these kinds of problems happen also at higher levels as well so in web applications you often have uh web services that do lots and lots of computation on behalf of a single Request and there's often denial of service attacks at that level where adversaries you know know that a certain operation is very expensive and they'll just ask for that operation to be done over and over again and unless you carefully design your particle and application to allow the client to prove that oh I'm burning it as much work as you uh or something

like this then it's hard to defend against these things as well make Sense all right so I guess the last thing I want to briefly touch on that the paper talked about as well is these routing attacks and the reason these attacks are interesting is they're maybe popping up a level above these just protocol transport level issues and look at what goes wrong in an application and the routing particle is a particularly interesting example because it's often the place where trust and sort of initial you know configuration gets Bootstrapped in the first place uh and

it's easy to sort of get that wrong and there's even today there's not great authentication mechanisms for that uh perhaps the clearest example is the DHCP protocol that all of you guys use when you open a computer or connect it to some Wireless or wired Network the computer just sends out a packet saying I want an IP address and other stuff and some DHCP server at MIT typically receives that packet and sends you back Here here's an IP address here's an IP address that you should use and also here's the DNS server you should use

and other interesting configuration data and the problem is that the DHCP request packet is just broadcast on a local network trying to reach the DHCP server because you actually don't know what the DHCP server isn't going to be ahead of time you're just plugging into some Network the first time you've been here let's say and your client doesn't Know what else to do or who to trust and consequently any machine on the local network could intercept these DHCP requests and respond back with any IP address that the client could use and also maybe tell the

client hey you should use my DNS server instead of the real one and then you could intercept all future DNS requests from the client and so on that Mak sense so I think these Protocols are fairly tricky to get right and at a global scale the Protocols like bgp allow any participant to announce a particular IP address prefix for the world to you to sort of know about and Route packets towards the attacker so if there's certainly been attacks where some you know router participating in bgp says oh I uh I'm you know a very

quick way to reach this particular IP address range and then all the routers in the world say okay sure I'll I'll we'll send those packets to you uh and uh this probably the most Frequent abuse of this is by spammers who want to send spam but they their own IP addresses are blacklisted everywhere because they are sending spam so they just pick some random IP address they announce that oh yeah this IP address is now here and then they sort of announce this IP address send spam from it and then disconnect uh and and gets

abused a fair amount this way sort of getting less now but it's kind of hard to fix because um in order to fix it you have To know whether someone really owns an IP address or not and it's hard to do without establishing some Global database of maybe cryptographic keys for every ISP in the world and it takes a quite a bit of effort by someone to build this database same problem actually applies to DNS SEC as well in order to know which signature to look for in DNS you have to have a crypto graphic

key associated with every entity in the world and it's not there now Maybe it'll get buil up slowly but certainly one big problem for adopting DNS SE all right so I guess the thing to take away from this is maybe just a bunch of lessons about what not to do in general in protocols but also actually one thing I want to mention is that while probably secrecy and integrity are good properties to try to enforce at higher levels of abstraction like in cryptographic Protocols of the Application and we'll look at that in next lectures one

thing that you really do want from the network is some sort of availability and dos resistance because these properties are much harder to achieve at higher levels in the stack so you really want to avoid things like maybe these amplification attacks maybe these uh you know sin flooding attacks uh maybe these rst attacks where you can shoot down an arbitrary person's connection these are things that are Really damaging at the low level and that are hard to fix higher up but the integrity and confidentiality you can more or less solve with encryption and we'll talk

about how we do that in uh next lecture on coros so you is then