<<

OSI Model Overview Part 1 of 2

Table of Contents

OSI and TCP/IP Models ...... 2

Why Use the OSI (or TCP/IP) Model? ...... 4

OSI Layer Intro ...... 6

OSI Layer 1 – Physical ...... 7

OSI Layer 2 – -link ...... 9

OSI Layer 3 – Network ...... 14

Notices ...... 18

Page 1 of 18 OSI and TCP/IP Models

OSI and TCP/IP Models

20

**020 Instructor: Let's get a little more abstract here. Let's talk about some models.

The argument I get into with students every time is: "Well that protocol doesn't sit at that layer of the OSI model." "I know it doesn't; because OSI is a model." "Well SSL doesn't fit here." "I know it doesn't; because that's an implementation."

And so I need you to step back just a little ; just kind of let go here and say: This is theory.

Now another way to deal with this theory in its implementation is to

Page 2 of 18 actually kind of dig in to that and take a look at it. And how you do that-- I think-- the best way to do that is to go through a set of layers-- work through those layers with me here-- and then put it in action.

If you're allowed to on your network, download the tool that will actually allow you to capture packets.

I like Wireshark. It's a free, open source tool; and it's cross-platform capable. You have to be allowed to download it; and you also have to be able to well collect communications on your network to actually see it in action.

If you can't do that and you can only download the tool, you can actually get pre-built packet captures that other people have collected and have put up on the .

Well what is Wireshark? It is a way to look at all of the communications between hosts, with certain tools in place; and then you can inspect that individual protocol data unit and dig down inside of it and look at the actual protocols in use at what layers.

So let's look at our models here.

Page 3 of 18 Why Use the OSI (or TCP/IP) Model?

Why Use the OSI (or TCP/IP) Model?

Permit exchange of information among systems that are “open” or compliant with this standard • Reference framework to enable independent work • Definitions of security terminology • Standard descriptions of security services and mechanisms • Identify where services map to OSI model • Security management

“Information may not be given to, accessed by, nor permitted to be inferred by, nor may any resource be used by those not appropriately authorized”

- General Authorization Policy – ISO 7498-2

21

**021 So we've got these two different models. They allow us to abstract the communications that are going between two hosts, or maybe to many hosts, and allows us to create protocols that don't have to consider every single possibility of communication from me to you.

Let's go back to mainframe days for a second. In mainframe days it was that can talk to this node based on what rules I've laid out here. And this was a little bit of a brittle communication at that point. What we want is flexibility within our protocols.

Page 4 of 18 So what we did is we said: Okay between me and you what we're going to do is we're going to abstract that communication in a bunch of different ways, in a layered fashion, that allows me to say: Well there's an improvement that I can make here without disturbing the unimproved stack on your side.

So I can make improvements and optimizations for me; as long as I make sure that you understand and I follow the general rules or protocol; then you will be able to communicate with me on the other side. So a lesser client can communicate to a greater client, in a lot of cases.

Now when we look at this information in the OSI and the TCP model, a lot of people get really hung up on the rules, really hung up on the terminology in here. And what I will say to you is just relax and let it wash over you a little bit.

So this is a framework that is independent of the network; which is really, really nice.

It allows us to define security terminology at different layers. So we can apply more rigor of security at different layers inside the OSI model when it suits the communication from me to say you; and we can add that security as we go along.

Page 5 of 18 OSI Layer Intro

OSI Layer Intro

Defined by ISO 7498 • Also describes security mechanisms and where they fit in the model.

Application Presentation Session Transport Network Data-link Physical

22

**022 So let's look at the model. Here's our model: Application, Presentation, Session, Transport, Network, Data-link and . Sometimes these are mapped together.

Page 6 of 18 OSI Layer 1 – Physical

OSI Layer 1 – Physical

Application • Transmits logical (1’s and Presentation 0’s) over a physical circuit • Electrical and physical Session specifications Transport • Devices – NICs, , Network concentrators Data-link Physical

23

**023 When we look at Layer 1, we are talking about electronic , shapes; and at this point the data is just 1s and 0s, electronic signals. It's on or it's off.

Physical connector. What is the shape of the thing that you plug into the wall? Is it RJ45 or is it RJ11? Is it a BNC connector? The physical shape and characteristics of it are described at the Physical layer.

One other Physical layer attribute that we might want to talk about is wiring schemes. So when we're talking about an eight cable- an eight connector cable, is that

Page 7 of 18 EIA/TIA specification? And I won't use the numbers here; but it could be we'll set it up one way or we'll set it up another way.

By the way, in that communication between us, if we do it correctly and we wire all of our jacks the same, then we'll have communication. If we wire them to the other standard, we'll actually create what's called a crossover cable between two devices.

So let's go back to our introduction to the course; and how could you be evil at this point? What could you do at the Physical layer? Well you could inject noise onto the channel if you wanted to. You could cut the cable. You could- you could listen in and capture that information.

And so at the Physical layer we have to put in physical protection mechanisms.

Page 8 of 18 OSI Layer 2 – Data-link

OSI Layer 2 – Data-link

Application • Physical addressing, error Presentation detection and reliable data transfer Session • LLC – link-layer control, Transport governs sequence numbers and acknowledgements Network • MAC – media-access control, Data-link governs data transfer and Physical collision handling • Devices – ATM, switches, bridges • Protocols: PPP, ARP

24

**024 As we go up a layer to the Data-, now what we're doing is we're starting to abstract things. The Data-link layer-- remember, it knows nothing about the Physical layer except for I expect when this comes across that it is correct for what we're doing.

Now this layer breaks into two sub- layers: the and the media-access control.

When we talk about logical link control, this is sequence numbers and acknowledgements at a Layer 2 level. This is setting up so that we can transmit back and forth between

Page 9 of 18 each other. Don't confuse that with the Network or the .

But we govern the sequence that we've received the bits and we can keep on signaling.

More importantly at this layer is our address space; which is covered by the sub-layer media-access control. It governs the data transfers and the collision handling.

How does it do that? Well when we talk about a MAC address, it is six pairs of hex that are uniquely tied to a particular node on that network.

When we communicate to the rest of the nodes on that network in that what's called broadcast domain, what we will do is we will say; This is my MAC address; I'm looking for you.

So I want to communicate directly for you- to you. On this broadcast domain that everybody else hears, you know that I'm only talking to you; and the rest of you should- don't pay any attention to this. That's what it boils down to.

What happens if I don't know who you are; and I say: I'm looking for Steve? Everybody has to listen and say: Hum I'm not Steve. But Steve will raise his hand and go: Hi I'm Steve. Ah okay. Let's have a communication here.

How do I communicate to everyone? When I broadcast to everyone looking for Steve, what I do is I

Page 10 of 18 change the address of who I'm looking for to all f's in all of those hexadecimal representations.

And thereby everybody on that piece of broadcast domain will pick up that signal; and they'll look at it and they'll say: This is destined for everybody? Well I'm everybody. And then it will do-- it will take on that communication. And then-- here's the thing where it goes to the next layer-- it de-encapsulates and throws it up the stack; because it doesn't know that it's not Steve. At Layer 2 all it knows is I'm part of everyone; or this is my MAC address.

So at the Data-link layer what we do is we govern those transmissions by looking at that one piece of data that goes across there.

Now there is one other thing that we do, which is really elegant, which is checking for failed packets. We use what's called-- in Cisco terms this is called Checking Sequence; in OSI terms it's called CRC or Cyclical Redundancy Checking. We actually validate that the packet is intact from source to destination.

What we're doing is we're actually checking to see that the layer below, at the Physical layer, whether the signal was twisted or bent up or had noise injected into it, by a simple calculation methodology.

Now how would we get noise down below? Well an adversary could do it. But let's talk about a naturally

Page 11 of 18 occurring thing like noise or crosstalk on a piece of wire.

It could be that that signal that literally crossed off when two wires are over top of each other, that that signal got interrupted or switched. One zero got switched for another zero. It happens.

So what we do is we do the checking mechanism; and then we pass it up to Layer 2. And Layer 2 says: The checksum on this particular data area right here should be this number. If I calculate this correctly, this number will work just fine. Is that the same thing? Does this- does this data calculate to this? If yes, okay, we're good, we pass the CRC test; we take off all of our information and pass it up the stack. We'll get to headers and those kinds of things in a minute.

But at the Data-link layer all we're doing is we're checking to see that it's consistent. We're making sure that it's actually for us; and then we're passing it up the stack.

We actually physical devices here, which are things like ATM-- not the thing that you get money inside of. I think that's Asynchronous Transfer Mode. Switches and bridges sit at Layer 2. We'll talk about devices later.

The protocols that you see at Layer 2 are PPP-- Point to Point Protocol-- and then an interlayer protocol, Address Resolution Protocol or ARP.

Page 12 of 18 There's also- by the way there is Inverse ARP or IARP, and there is RARP, Reverse ARP. They're used for different purposes but they basically do the same thing.

All three of these protocols do the same thing. They map Layer 2 addresses to Layer 3 addresses. So there is a little bit of communication between the Data-link and the . So that kind of mapping has to take- has to take place above.

But we know about that mapping for ourselves by keeping track of all the MAC addresses that we have heard, and also knowing what are MAC addresses; and we map that in a table. We'll get to that in a bit.

Page 13 of 18 OSI Layer 3 – Network

OSI Layer 3 – Network

Application • Logical addressing, route Presentation selection • Fragmentation and re-assembly Session • Devices – Layer 3 bridges, Transport routers Network • Protocols: IP, ICMP, IPSec Data-link Physical

25

**025 At the Network layer, now we start doing logical addressing. Data- link had the MAC address. It's supposed to be burned in; and with the advent of virtualization that's kind of washing away at this point.

At Network layer we have a logical addressing that we actually control based on whether it's internet, intranet or whether it's an encrypted session between two hosts.

What happens here is we're allowed to redirect traffic and route around failure if we use the correct protocols-- that's different than a routed protocol. If we use the

Page 14 of 18 correct routing protocols, then we can route around the failure and get from the source to the destination.

Sometimes we encounter networks that can't handle the sheer size of the packet that we're passing the data over, for some reason. If that is true and we still want to make that information flow through, what we'll do is cut it into smaller pieces, called fragmentation.

Now evil-doers, when they look at this, they say: You know what? I'm not going to send you a packet that says 'this is evil' because your intrusion detection tools will-- oh well this is evil, I'm not going to do anything with that.

But what I could do is I could send you this in one fragment-- you can't assign or look at that packet. "Is"-- that comes in and that's going to actually be recombined later on past your inspection at this layer-- "Is evil." And then it gets recombined up above.

The fragmentation that was below doesn't allow the inspection tools at the Network layer to actually inspect correctly; because the fragmentation has occurred. The reassembly happens at the Network layer and goes up the stack.

So if we're looking for- if we're looking for evil and it's fragmented, we may not be able to see it.

Page 15 of 18 When it gets reassembled-- as it gets reassembled it doesn't get inspected at that point; it gets passed up the stack for inspection at the next layer up. Its job at the Network layer is to fragment and reassemble; and also to get the packet to its destination. We'll talk about- more about destinations when we talk about IPv4 and IPv6.

The protocols at the Network layer-- well there's really only one protocol that we're using today, which is IP. Are there others? Yes there are plenty of others. Are they in use; are they popular at this point? Less and less so every day. It turns out that IP is the protocol.

Now there is another protocol at this layer that helps us to deal with issues and problems; which that protocol is called ICMP. And its job is to be used as a testing protocol to make sure that the signal is actually getting through between us. We know it by its popular command line tool that we use as Ping.

We send out a signal and we see what comes back. That's all designed inside the ICMP protocol.

Now evil-doers can attack and use ICMP, and twist it up in a multitude of ways. We'll talk about those attacks later on. But realize that testing protocol has been abused severely over the past 10 or 15 years. So what we tend to do now is we tend to as a defensive measure say: We're not going to respond to that testing protocol.

Page 16 of 18 You can find out the edge that our actual is on; but we're not going to let you talk to these hosts directly back here because you have no business in that.

The other protocol that is arguably at the Network layer is IPSec. Now if you look at the protocol, I think it spans some of the layers there. It's not just a networking protocol. But we'll leave it there when we're talking about the OSI model.

It is a way to communicate over the public internet in an encrypted fashion, so your adversaries cannot see your communications nor can they de-scramble them. We'll get to that in the very last section when we talk about cryptology.

Page 17 of 18 Notices

Notices

© 2015 Carnegie Mellon University This material is distributed by the Software Engineering Institute (SEI) only to course attendees for their own individual study. Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or used in any other manner without requesting formal permission from the Software Engineering Institute at [email protected]. This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide. Although the rights granted by contract do not require course attendance to use this material for U.S. government purposes, the SEI recommends attendance to ensure proper understanding. THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT). CERT ® is a registered mark owned by Carnegie Mellon University.

2

Page 18 of 18