Return to Video

35C3 - How does the Internet work?

  • 0:00 - 0:19
    35C3 preroll music
  • 0:19 - 0:20
    Herald Angel: Welcome everybody to this
  • 0:20 - 0:25
    talk, "How does the Internet work?" And
    our speaker is Peter Stuge and I'm very
  • 0:25 - 0:29
    happy that he is here to explain to all of
    us how the infrastructure of the Internet
  • 0:29 - 0:33
    really works. I am pretty sure we will all
    learn a lot today. Please give a big and
  • 0:33 - 0:42
    warm round of applause for Peter Stuge.
    applause
  • 0:42 - 0:46
    Stuge: Thank you. Thank you very much.
    Thank you for being here. This is amazing.
  • 0:46 - 0:54
    Translation into French, wow. So I want to
    talk about how the Internet works. And I
  • 0:54 - 1:01
    try to, try to... yeah, try to shine some
    light on all the technologies that are
  • 1:01 - 1:07
    involved when we use the Internet every
    day. So, why this talk? Some motivation
  • 1:07 - 1:12
    first, then a little bit of brief
    background just how the Internet got
  • 1:12 - 1:18
    started. And then we get into the details.
    So what actually happens between the web
  • 1:18 - 1:27
    browser and the website, that's the
    starting point. So in the description I
  • 1:27 - 1:32
    listed things from bottom up, so from the
    very low level packet stuff and through
  • 1:32 - 1:38
    the various layers of the network stack up
    into the applications. And that's the
  • 1:38 - 1:44
    building blocks part, but I inserted this
    overview first, what is actually going on
  • 1:44 - 1:49
    between the browser and the website
    because that's what most people already
  • 1:49 - 1:59
    know and use a lot. Some parts, well, some
    details about the different protocols and
  • 1:59 - 2:04
    in the end some recommendations for
    further talks, if you find these topics
  • 2:04 - 2:12
    interesting. So the reason I want to give
    this talk is to talk about how does the
  • 2:12 - 2:18
    Internet work, right? The mechanisms that
    we use all the time... but aren't
  • 2:18 - 2:25
    mentioned very much. So they are sort of
    obscured or... well I don't know if hidden
  • 2:25 - 2:32
    is the right word but we wouldn't.. we
    don't experience the network itself very
  • 2:32 - 2:37
    much, right? We experience the various
    services that we use and they, the
  • 2:37 - 2:45
    services, they try their hardest to keep
    us interested, to tickle our imagination
  • 2:45 - 2:53
    and... I think it's dangerous to not talk
    a little bit about the network every now
  • 2:53 - 3:00
    and then. And to think about the network,
    and to actually fight for a public network
  • 3:00 - 3:08
    that is available to all and equal. Also
    neutral. If we focus on the service
  • 3:08 - 3:14
    providers alone then they're going to be
    deciding what we can do with the network.
  • 3:14 - 3:21
    But the point of, or the great thing
    about, how the Internet is neutral today
  • 3:21 - 3:27
    is that we're all connected or we could
    all connect to each other. We don't
  • 3:27 - 3:33
    really have to use these service
    providers. We tend to. This is somehow a
  • 3:33 - 3:39
    human nature to sort of go towards
    centralization and monopolization. But the
  • 3:39 - 3:48
    Internet is a tool that would allow us to
    try more variants or other kinds of
  • 3:48 - 3:55
    structures. And we need to be aware of
    that and the importance of net neutrality.
  • 3:55 - 4:04
    If we don't talk a bit about the network
    we might lose it. So. How did it all get
  • 4:04 - 4:15
    started? In 1970, then ARPA, they started
    the ARPANET. So ARPA back then is this is
  • 4:15 - 4:22
    now DARPA. That's the Defense Advanced
    Research Projects Agency. They develop
  • 4:22 - 4:28
    technology for the U.S. military. And they
    did back then as well. So the ARPANET was,
  • 4:28 - 4:34
    as the quote says, from this very very old
    document, that the objective is to get all
  • 4:34 - 4:41
    their suppliers connected into a network
    together, and being able to exchange
  • 4:41 - 4:46
    information so that they can, I guess,
    make progress more quickly, more
  • 4:46 - 4:55
    efficiently. Right? Now it's something
    else. I think that's good. So let's let's
  • 4:55 - 5:02
    look at what happens between the browser
    and the web site. So we have a person
  • 5:02 - 5:08
    using a laptop and they have a browser and
    they type in a web address.
  • 5:08 - 5:14
    "events.ccc.de", for example. To read the
    blog posts, the latest blog posts about
  • 5:14 - 5:22
    the Congress. So then the browser really
    does two different things first of all. To
  • 5:22 - 5:31
    get, to show this page. So first of all it
    has to ask for the the way to reach this
  • 5:31 - 5:37
    website that we want to reach. Computers,
    they don't deal very well with names or
  • 5:37 - 5:44
    text. At least not the network part of
    computers or systems. So there is this
  • 5:44 - 5:51
    translation somehow like a phonebook, I'll
    get back to that in a bit, called DNS,
  • 5:51 - 5:55
    which is used primarily... it has a few
    other uses as well, but it's used
  • 5:55 - 6:00
    primarily to get from this name that we
    entered, "events.ccc.de", that we can also
  • 6:00 - 6:08
    somehow easily remember, to the network
    address. The IP address of this web site.
  • 6:08 - 6:14
    So that's part one. And it says System
    DNS because the browser doesn't do all of
  • 6:14 - 6:21
    this phone book lookup itself. It can rely
    on the operating system to take care of
  • 6:21 - 6:26
    this. Unfortunately. So that's the
    parentheses that's what the operating
  • 6:26 - 6:30
    system is doing its using a few protocols
    UDP, IP and that becomes a network packet.
  • 6:30 - 6:35
    We'll get back to those in just a little
    bit. So once the browser has the the
  • 6:35 - 6:44
    network address the IP address of this
    website it creates a connection. So it
  • 6:44 - 6:53
    contacts the web server and it uses this
    set of protocols. So it first uses IP to
  • 6:53 - 6:57
    reach the IP address of the server and in
    particular it uses TCP for this connection
  • 6:57 - 7:03
    type, we'll get back to those in a little
    bit, as well what what their properties
  • 7:03 - 7:07
    are. And on top of that the browser then
    uses the HTTP protocol. We'll see an
  • 7:07 - 7:16
    example of that in the very end. How or to
    get to request the the web page that we
  • 7:16 - 7:23
    wanted to see. And that's all happening
    on the laptop in the browser and part in
  • 7:23 - 7:28
    the operating system that we're using
    whatever that might be. Then there's of
  • 7:28 - 7:33
    course this long chain, or sometimes not
    so long, but usually several several
  • 7:33 - 7:38
    machines along the way, routers, we might
    have a wireless router at home or in a
  • 7:38 - 7:46
    coffee shop or here at Congress, and
    beyond that there is certainly there are
  • 7:46 - 7:52
    certainly some more routers along the way
    from or between our laptop, my laptop, and
  • 7:52 - 7:57
    the destination that I want to contact.
    So all of these routers they receive some
  • 7:57 - 8:03
    packets, they look at the addresses, where
    it's going, in particular, and then sends
  • 8:03 - 8:11
    it along its way. So they're they're just
    forwarding packets all all day long.
  • 8:11 - 8:20
    Finally at the destination on the web
    server there are also two parts. So first
  • 8:20 - 8:28
    of all the request that was sent by the
    browser is received. It goes through these
  • 8:28 - 8:32
    these different layers, different
    protocols, and the website server
  • 8:32 - 8:37
    software, it looks at the request and it
    says OK somebody wanted the first blog
  • 8:37 - 8:44
    post, then I'll send that right back the
    same way that I received the request, and
  • 8:44 - 8:50
    that's part two. So returning the response
    to this request, and it goes all the way
  • 8:50 - 8:58
    through the routers the same path but in
    the reverse direction to the laptop. So
  • 8:58 - 9:06
    let's let's look at all these different
    building blocks. All right. So let's start
  • 9:06 - 9:11
    with the small smallest one in the network
    packet. I talked about packets going back
  • 9:11 - 9:20
    and forth, so the packets, or a packet, is
    sort of the atom on the network--it's the
  • 9:20 - 9:28
    smallest useful unit that is sent or
    processed by the network. I think a good
  • 9:28 - 9:34
    way to explain packets is with regular
    postcards that you can send with mail,
  • 9:34 - 9:43
    because their size, their maximum allowed
    size, is pretty much standardised. You
  • 9:43 - 9:47
    can't send a postcard which is one meter,
    right? And that's the same with the
  • 9:47 - 9:52
    network packets, you can't send
    arbitrarily large network packets. One
  • 9:52 - 10:00
    pretty common maximum size is 1500 bytes
    or roughly characters. So just to give an
  • 10:00 - 10:07
    idea of of how fairly small the packets
    are actually and even that might, I don't
  • 10:07 - 10:11
    know do, 1500 characters fit on a
    postcard? No I guess not, I think that's
  • 10:11 - 10:15
    too much. So maybe the packets are a
    little bit larger than postcards, but
  • 10:15 - 10:21
    still the analogy is pretty good because
    you send them out and and there's very
  • 10:21 - 10:27
    little, there's a little bit of structure,
    like there's a stamp perhaps, and a
  • 10:27 - 10:31
    recipient address but that's pretty much
    it. So what you what you write on the
  • 10:31 - 10:36
    postcard on the on the other side is
    really up to you and it's the same with
  • 10:36 - 10:41
    the packets, they can contain anything,
    but if you write in the language that the
  • 10:41 - 10:45
    receiver doesn't know, then they're going
    to receive the packet and then actually
  • 10:45 - 10:53
    just drop it because they don't know what
    you're trying to tell them. So packets,
  • 10:53 - 11:00
    they are sent and received through network
    interfaces. This is an Ethernet cable LAN
  • 11:00 - 11:08
    port, or a Wi-Fi antenna, or maybe a 3G
    modem if you're on the go out and about
  • 11:08 - 11:13
    and your cell phone does this of course as
    well right. The cell phone has Wi-F if
  • 11:13 - 11:20
    you're in a coffee shop maybe, or it has
    3G if you're in the subway or on the tram.
  • 11:20 - 11:28
    And one interesting thing, or where the
    comparison to the postcards doesn't really
  • 11:28 - 11:35
    fit anymore, is that network interfaces,
    they can easily pass millions of packets
  • 11:35 - 11:42
    in a single second. So it can be can be
    quite a lot of information going through
  • 11:42 - 11:49
    especially if you have a good internet
    connection like here at Congress. So then
  • 11:49 - 11:57
    the next step or sort of if you start
    looking at OK what can we put on the
  • 11:57 - 12:01
    information side of the postcard, right,
    where where we can put any message we
  • 12:01 - 12:07
    want. For this talk I'm only going to
    focus on IP version 4. I know it's it's
  • 12:07 - 12:16
    old and legacy and we really shouldn't be
    using it still but it is, it's dominant so
  • 12:16 - 12:24
    far, it won't be forever, but so far it's
    quite common. And I think it's something
  • 12:24 - 12:31
    that most of us have at least seen when
    setting up the Wi-Fi or the new Internet
  • 12:31 - 12:36
    connection, right? This IP address that I
    put up on the slide is maybe the most
  • 12:36 - 12:44
    common IP address there is, right, for the
    for the new wireless router. These IP
  • 12:44 - 12:50
    addresses they consist of the four numbers
    and they are the four numbers. They range
  • 12:50 - 12:55
    from 0 to 255 and then there's now four of
    them and with dots in between is just how
  • 12:55 - 13:04
    we write them. This is an efficient way
    for machines to identify themselves. But,
  • 13:04 - 13:10
    the reason IP version 4 isn't so great
    anymore is that it's quite a small number
  • 13:10 - 13:16
    of addresses. So it turns out that the
    Internet is pretty popular and worldwide
  • 13:16 - 13:23
    the addresses have run out or are running
    out. There aren't enough addresses for all
  • 13:23 - 13:27
    the devices that are actually
    participating or somehow connected to the
  • 13:27 - 13:38
    Internet. IPv6 will solve this. Let's see.
    Maybe maybe we'll live to experience that.
  • 13:38 - 13:43
    So what is what is a network then? There
    are different kinds of networks. I've
  • 13:43 - 13:51
    written physical networks and logical or
    abstract networks. Physical network is
  • 13:51 - 13:57
    cabling, right? If you have some kind of
    connection from your Internet service
  • 13:57 - 14:05
    provider that goes to your wireless router
    or if you have a LAN setup like in the
  • 14:05 - 14:10
    hack center with a switch and lots of
    cables to each, one cable to each
  • 14:10 - 14:16
    computer, that's a physical network and
    that's a tangible thing right. That's
  • 14:16 - 14:20
    something we can we can touch and we can
    modify it with our hands and so on. But
  • 14:20 - 14:24
    then there are also and that's that's
    certainly one network type and another
  • 14:24 - 14:29
    equally valid network type is the logical
    network, or as I also call it the abstract
  • 14:29 - 14:37
    network, which is defined only by the
    addresses used by some set of computers
  • 14:37 - 14:43
    that are communicating together. So here's
    an example of an IP network that might be
  • 14:43 - 14:52
    used with the wireless router and that has
    the IP address up on top right. And the
  • 14:52 - 15:00
    there's sort of a pattern right. The first
    three digits are the same. And that's the
  • 15:00 - 15:09
    network address. And the very last part is
    zero with this slash 24. Meaning that 24
  • 15:09 - 15:17
    first bits of the 32. So now it's
    technical maths and binary and sorry, but
  • 15:17 - 15:23
    essentially the 24 means the first three
    numbers are always the same. And within
  • 15:23 - 15:27
    this logical network, so within this group
    of computers or systems that can
  • 15:27 - 15:34
    communicate with each other, only the very
    last digit will change. And as long as
  • 15:34 - 15:42
    this is the case we don't need a router,
    yet. We can--all these computers or all
  • 15:42 - 15:46
    these systems--they can communicate
    directly with each other on the local
  • 15:46 - 15:51
    network or on a Wi-Fi or or whatever. And
    the slash 24 (/24) and with the
  • 15:51 - 15:58
    255.255.255.0 that's just two different
    ways to express exactly the same thing. So
  • 15:58 - 16:08
    where do these IP addresses come from and
    how, who has them, and so on? So if we get
  • 16:08 - 16:15
    a wireless router then we have some IP
    addresses. But me and my friend we both
  • 16:15 - 16:20
    have the same perhaps IP addresses because
    we have a wireless router from the same
  • 16:20 - 16:26
    supplier. Right. And this is a little bit
    of a special case. Those aren't Internet
  • 16:26 - 16:33
    IP addresses. They're used only very
    locally. So only in one home network, only
  • 16:33 - 16:42
    in one company network, perhaps. The
    public IP addresses are the ones that are
  • 16:42 - 16:47
    on the outside of this wireless router
    that I got, and the wireless router
  • 16:47 - 16:54
    typically only has one. Some Internet
    providers give you a few but it's very
  • 16:54 - 16:59
    easy to have a lot more devices in your
    home or in your office than public IP
  • 16:59 - 17:04
    addresses that you get from your Internet
    provider. So the IP addresses, they are
  • 17:04 - 17:11
    assigned to the Internet providers, or the
    other way around, Internet providers they
  • 17:11 - 17:17
    apply for some range of some number of IP
    addresses. And here in Europe there is an
  • 17:17 - 17:24
    organisation called RIPE in charge of
    allocating a block of IP addresses to the
  • 17:24 - 17:31
    Internet companies that are actively
    connecting to other Internet companies and
  • 17:31 - 17:40
    maybe are also your Internet providers and
    mine. So and RIPE they have, they of
  • 17:40 - 17:48
    course have colleagues in different parts
    of the world. So I think there are four or
  • 17:48 - 17:52
    five, maybe even six of the RIR
    organizations, the regional network
  • 17:52 - 17:59
    centers. They assign IP address blocks to
    the Internet companies, and by Internet
  • 17:59 - 18:04
    company I don't only mean Internet
    providers that we use at home and at work,
  • 18:04 - 18:12
    but also really any larger company that
    has a service available on the Internet.
  • 18:12 - 18:20
    So all the streaming sites that you can
    imagine, all the, most, well several large
  • 18:20 - 18:26
    just websites that are used every day will
    also have their own IP address range and
  • 18:26 - 18:33
    will be active in finding different ways
    to connect to the Internet providers so
  • 18:33 - 18:40
    that the end users can have as good an
    experience as possible when they're
  • 18:40 - 18:49
    visiting there or using their services. So
    I talked about the Internet companies,
  • 18:49 - 18:55
    they are trying to find good ways to
    connect to each other or to make it
  • 18:55 - 19:02
    possible for users with one Internet
    company to reach either users at another
  • 19:02 - 19:10
    Internet company or some service provided
    by some Internet company. And that's,
  • 19:10 - 19:17
    that's the routing that's going on, both
    in the wireless wireless router at home
  • 19:17 - 19:23
    but just as well and and even more so in
    all of these routers on the Internet that
  • 19:23 - 19:32
    are handing packets back and forth. So
    starting with the wireless home router, it
  • 19:32 - 19:41
    typically has one local network. At least.
    It might have more. So I had a home router
  • 19:41 - 19:48
    that had both the regular Wi-Fi network
    and I was also able to configure a guest
  • 19:48 - 19:54
    network or guest password. So that's
    actually two. It's Wi-Fi, so it's not
  • 19:54 - 19:58
    really so intuitive, but those are two
    separate physical networks, because if
  • 19:58 - 20:03
    you're connected to one you can't
    communicate directly with the other
  • 20:03 - 20:11
    network without a router. Now there's some
    chance that the wireless router will do
  • 20:11 - 20:16
    this, will enable this communication, but
    it's not for sure and it's not it's not
  • 20:16 - 20:22
    certain. And in fact it's more likely that
    it won't work because this guest access,
  • 20:22 - 20:26
    you're supposed to be able to give that to
    somebody who's just visiting and maybe you
  • 20:26 - 20:34
    don't want them to access your printer or
    your storage cabinet or whatever. Right?
  • 20:34 - 20:39
    So it's quite likely that this guest
    network doesn't get access to the main
  • 20:39 - 20:48
    network. So two different networks, even
    though it's the same the same radio waves
  • 20:48 - 20:55
    or the same air that's carrying the radio
    waves but the key property by the, or with
  • 20:55 - 21:02
    a wireless or a home router, is that it
    almost always only has a single Internet
  • 21:02 - 21:08
    connection, so it has a single connection
    to some Internet provider or in in the
  • 21:08 - 21:14
    direction of the Internet. Typically
    that's that's the telco. But in some cases
  • 21:14 - 21:21
    there's even, especially in the US,
    there's the situation where the telco or
  • 21:21 - 21:27
    the Internet provider is also a content
    service provider. And that's a pretty bad
  • 21:27 - 21:34
    situation. In particular if you have no
    options, no choice. So we have the home
  • 21:34 - 21:41
    router with a single connection towards
    the Internet to the Internet provider.
  • 21:41 - 21:47
    Let's compare that with the Internet
    routers that are further out on the
  • 21:47 - 21:54
    Internet and operated by the many
    different Internet companies. They will
  • 21:54 - 22:01
    similarly have one or more local networks
    that belong to them the same way that the
  • 22:01 - 22:08
    wireless network belongs to the home
    router or wireless company, or sorry an
  • 22:08 - 22:12
    Internet company or an internet
    organization, let's say like the CCC as
  • 22:12 - 22:19
    well, it has some some equipment and
    servers with the events.ccc.de server for
  • 22:19 - 22:28
    example, is part of the CCC slice of the
    Internet, and the router that's
  • 22:28 - 22:42
    responsible for all of CCC's networks is
    responsible for. Also this IP segment
  • 22:42 - 22:47
    where the web servers. Now the big
    difference here is that those Internet
  • 22:47 - 22:53
    routers, or the routers that are further
    out on the Internet than our home routers,
  • 22:53 - 23:02
    they typically connect to at least two but
    usually many more other Internet routers.
  • 23:02 - 23:08
    Exactly how is it different in every
    location. There are some norms and some
  • 23:08 - 23:16
    common topology is but this is... so the
    connections that exist are determined by
  • 23:16 - 23:24
    by peering agreements between the Internet
    companies and their Internet organizations
  • 23:24 - 23:31
    there. They can of course have agreements
    with whoever. So it's not so easy to tell
  • 23:31 - 23:37
    them beforehand what a particular
    organization, how a particular
  • 23:37 - 23:41
    organization, will do peering. This is an
    interesting topic. There are some more
  • 23:41 - 23:49
    talks on this as well that I'm referring
    to later. One, at least one model, is to
  • 23:49 - 23:59
    have a site. Some data center somewhere
    where an Internet exchange is running. So
  • 23:59 - 24:06
    this is an organization whose sole purpose
    is to enable many different Internet
  • 24:06 - 24:11
    companies or Internet organisations to
    somehow make their way there, put some
  • 24:11 - 24:18
    cables to this data center, and all
    connect together and be able to exchange
  • 24:18 - 24:27
    traffic between each other efficiently and
    maybe even at no cost. That's an
  • 24:27 - 24:37
    interesting topic because there are so
    many different business models for the
  • 24:37 - 24:45
    peering agreements. So the Internet
    exchanges is one model. There's a handful
  • 24:45 - 24:54
    of them in Germany and that's about the
    scale of it. Private peering is of course
  • 24:54 - 24:59
    possible to where organisations just have
    a direct connection between each other.
  • 24:59 - 25:07
    And OK. So these connections they are then
    established somehow and how do the routers
  • 25:07 - 25:13
    know where to send what? And that's a good
    question. This is managed by routing
  • 25:13 - 25:19
    protocols, BGP is one. One such
    application or some, BIRD, is one
  • 25:19 - 25:26
    application and then BGP is the protocol.
    So there are some rules, you can configure
  • 25:26 - 25:31
    what to prefer, what route to prefer, but
    you can also just say I don't really care
  • 25:31 - 25:36
    so much and just use whatever is
    available. And of course this depends on
  • 25:36 - 25:42
    how much you have to pay for traffic that
    you send which way. If you have a really
  • 25:42 - 25:49
    good peering agreement with another
    Internet organization and you're able to
  • 25:49 - 25:55
    send a lot of traffic their way then
    without having to pay very much extra or
  • 25:55 - 25:57
    maybe anything at all then of course
    you're going to try to send as much
  • 25:57 - 26:11
    traffic as possible that way. All right,
    so now we're getting, we've looked at IP
  • 26:11 - 26:18
    addresses and IP addresses... we know some
    systems on the Internet or connected to
  • 26:18 - 26:23
    the Internet... all systems connected to
    the Internet, they have some IP address.
  • 26:23 - 26:33
    And if we know the IP address we can try
    to reach that system.Yeah, yeah. That's a
  • 26:33 - 26:42
    bit unfortunate. So. The first um the
    first bullet point is UDP. It's... now
  • 26:42 - 26:47
    we're talking about, okay, so on the on
    the postcard when we're writing stuff
  • 26:47 - 26:54
    there we we put the IP address because we
    know what system we want to reach. But we
  • 26:54 - 27:00
    want to send it some kind of message as
    well. There are a few different ways to
  • 27:00 - 27:08
    structure messages. And these are the most
    common ones, or the ones that make up
  • 27:08 - 27:14
    almost all of the traffic on the Internet.
    So the first one is UDP. It's quite like
  • 27:14 - 27:22
    postcards. So it's just a single message.
    There's no context, there's no connection
  • 27:22 - 27:28
    between two different messages, and
    there's also no guarantees about how this
  • 27:28 - 27:33
    message will, or this packet will, perform
    on the network. So if you send out a UDP
  • 27:33 - 27:40
    packet it might arrive or it might not and
    you'll never know. And that can seem a bit
  • 27:40 - 27:47
    useless but actually it's quite good in
    many cases. For example if you're doing
  • 27:47 - 27:56
    real time audio or video streaming UDP, is
    a good choice because it's real time
  • 27:56 - 28:02
    information, so if something is missing
    maybe there will be a glitch in the audio
  • 28:02 - 28:09
    or there will be some glitch in the video,
    but it's not so important to wait and
  • 28:09 - 28:15
    delay the image to fix that glitch. It's
    better to get the next image and just
  • 28:15 - 28:24
    replace the image. So just keep on going.
    And for that UDP is a really good fit.
  • 28:24 - 28:29
    Just send it send it along and if it
    arrives it arrives, most of the time it
  • 28:29 - 28:36
    does arrive. Most of the time it works
    fine. So sometimes a good choice. The next
  • 28:36 - 28:44
    point there is TCP. So maybe you've heard
    the term TCP/IP and TCP/IP is exactly
  • 28:44 - 28:50
    the... so specifically it's the
    combination of this, this TCP then, I'll
  • 28:50 - 28:59
    get into it in a second, with the IP
    address in both TCP and UDP. They have the
  • 28:59 - 29:05
    concept of a port. So that's a second
    address. You could compare that with,
  • 29:05 - 29:14
    let's say, the IP address is the street
    name and the port is the house number on
  • 29:14 - 29:18
    that particular street. So it's a bit more
    precise. You know it's that system but
  • 29:18 - 29:27
    that system might offer many services and
    you want one specific one. So for each of
  • 29:27 - 29:34
    the common services that we use, email and
    web and Jabber and whatever, there are
  • 29:34 - 29:44
    typical port numbers that are allocated
    and always the same. So that I don't have
  • 29:44 - 29:50
    to guess or or look up what it is. So with
    TCP, what are the properties of that?
  • 29:50 - 30:03
    That's more like a stream of letters that
    you have to go to the post office and
  • 30:03 - 30:11
    acknowledge that you've received. So the
    recipient of a TCP packet or a network
  • 30:11 - 30:20
    packet with IP and TCP inside of it will
    always confirm reception to the sender. So
  • 30:20 - 30:26
    this allows this concept of a connection
    that I mentioned, where both sides talking
  • 30:26 - 30:36
    to each other are synchronized and know
    where the other party is in this
  • 30:36 - 30:42
    communication or in this connection. What
    data has been received and what has not
  • 30:42 - 30:52
    yet been received. So the packets, TCP
    packets can of course also get lost,
  • 30:52 - 30:57
    right? There's no guarantee with any
    network that it will always function
  • 30:57 - 31:02
    correctly. You can just pull the cable and
    it will not be possible to send any
  • 31:02 - 31:11
    packets.So TCP will recognize that. Oh, so
    I sent some packets out, but they haven't
  • 31:11 - 31:17
    been confirmed, they haven't been
    acknowledged. OK. I'll try again. I'll
  • 31:17 - 31:26
    send again a few times and it's usually
    adjustable how long TCP will be retrying
  • 31:26 - 31:30
    to communicate. And finally it will give
    up and say yeah, sorry, it seems that this
  • 31:30 - 31:39
    connection is broken. It's not possible to
    communicate anymore over this path. But if
  • 31:39 - 31:45
    you're quick and you plug the cable back
    in then maybe everything will heal or the
  • 31:45 - 31:50
    connection will just continue functioning
    just as if there was never an
  • 31:50 - 31:57
    interruption, because the network software
    is just keeping track of what has been
  • 31:57 - 32:05
    sent, what has been received, and can
    recover from this loss of communication.
  • 32:05 - 32:16
    And the third one on the bottom is this
    SCTP. This is not quite so widespread but
  • 32:16 - 32:23
    it's still a very powerful mix. It's a lot
    younger than the other two. So UDP and TCP
  • 32:23 - 32:35
    they are... I'd like to say 70s and 80s.
    Yeah. So quite old. whereas SCTP I think
  • 32:35 - 32:40
    the standard was final, or the first
    version of the standard came in 2000, so
  • 32:40 - 32:48
    it's quite a lot younger, tis is protocol.
    But it's a powerful combination of
  • 32:48 - 32:57
    properties from both the older ones so you
    can have... whereas TCP you just have a
  • 32:57 - 33:03
    constant stream of text, essentially, or
    image or whatever content you are
  • 33:03 - 33:08
    transferring... with UDP you had this
    message that's on the postcard, like
  • 33:08 - 33:14
    that's one postcard that you're sending,
    that's the fixed fixed message. TCP
  • 33:14 - 33:17
    doesn't have that concept, it's just
    information all the time until the
  • 33:17 - 33:25
    connection closes. SCTP you can have a
    connection concept where both sides are
  • 33:25 - 33:32
    aware of the communication status or the
    position and the communication, but you
  • 33:32 - 33:37
    will be able to use it. You will still be
    able to send messages like on the
  • 33:37 - 33:42
    postcards. So you have a fixed size piece
    of information that you want to transfer
  • 33:42 - 33:51
    and you can send that as a unit, whereas
    if you're only using TCP, like we do on
  • 33:51 - 33:59
    the web all the time, you have to build a
    lot of stuff around or on top of TCP in
  • 33:59 - 34:02
    order to achieve the same thing. So if I
    want to transfer an image or when my
  • 34:02 - 34:07
    browser wants to download an image,
    there's quite a lot of extra work that has
  • 34:07 - 34:16
    to go into making that possible with the
    regular TCP protocol that is being used
  • 34:16 - 34:24
    for now, so it would advantage SCTP
    certainly. It also has the retry, the
  • 34:24 - 34:31
    reliable delivery, if you want to, and you
    can also use multi-homing. So that's not
  • 34:31 - 34:35
    so common yet. As I said typically in the
    wireless home routers they only have the
  • 34:35 - 34:42
    single Internet connection but that might
    change, we might in the future see several
  • 34:42 - 34:48
    different kinds of Internet connections
    that we're using, and SCTP would be able
  • 34:48 - 34:54
    to take advantage of that quite easily
    whereas the other ones cannot. So SCTP
  • 34:54 - 35:00
    can send the same information over several
    different connections and whatever comes
  • 35:00 - 35:06
    first arrives first at the destination and
    is accepted. This is of course a bit
  • 35:06 - 35:14
    wasteful but in some cases maybe it's not
    a problem. So that's an exciting... I
  • 35:14 - 35:22
    think exciting new feature. Let's see what
    the future brings. It seems that TCP is
  • 35:22 - 35:37
    going away slowly but surely. Let's see
    what happens. But then some companies,
  • 35:37 - 35:46
    they're providing systems where they want,
    they want to control much more of how the
  • 35:46 - 35:50
    software is using the network, how the
    software is communicating on the network,
  • 35:50 - 35:56
    and the way that these systems are built.
    Cell phones typically are smartphones.
  • 35:56 - 36:03
    It's not so easy to do that with either
    TCP or SCTP, but it's quite easy to do it
  • 36:03 - 36:11
    if they're using UDP, so I think that's a
    big motivator for them to try to move away
  • 36:11 - 36:22
    from TCP and use UDP even more. Let's see.
    Sorry. So then we'll get in to some
  • 36:22 - 36:30
    applications. Now we've written on the
    postcard, we've written addresses, IP
  • 36:30 - 36:36
    addresses, the system that we want to
    communicate with, and we've chosen either
  • 36:36 - 36:44
    UDP or TCP depending on what what is most
    suitable. Actually it depends typically on
  • 36:44 - 36:49
    the application. So some applications
    require one or the other and a few
  • 36:49 - 36:58
    applications can do either or. The first
    thing I'd like to mention here is DNS. I
  • 36:58 - 37:03
    call it the phone book, the Internet phone
    book. But there is one big difference. A
  • 37:03 - 37:07
    phone book is something we get from from
    one publisher, right? The phone company
  • 37:07 - 37:13
    typically. And they, or the POC here at
    Congress, and they've just collected or
  • 37:13 - 37:18
    they know all the phone numbers and they
    send us the list, right, with the names.
  • 37:18 - 37:27
    DNS is different in that everybody who has
    who has a name in the DNS, in the domain
  • 37:27 - 37:32
    name system, so anybody can register a
    domain name. And anybody who does that can
  • 37:32 - 37:39
    can publish some information there. You
    can decide what you publish. Actually you
  • 37:39 - 37:44
    can decide if you publish. So let's say
    you have a thousand IP addresses you can
  • 37:44 - 37:50
    decide if you want to publish names for
    all of those thousand or if you just maybe
  • 37:50 - 37:56
    publish a few of them that are going to be
    interesting for other people to use. And
  • 37:56 - 38:03
    90 percent of them are just internal
    internal systems. So everybody gets to
  • 38:03 - 38:09
    choose what they what they publish and
    everybody can publish. Also can run the
  • 38:09 - 38:14
    infrastructure, storing this information
    on their own. So it's not that you have to
  • 38:14 - 38:20
    send this in somewhere necessarily and
    they publish it for you. You can actually
  • 38:20 - 38:26
    do that on your own. So it's
    decentralized. Very good. still it's super
  • 38:26 - 38:33
    super old protocol, from from those days
    of from those early days of the internet.
  • 38:33 - 38:46
    Nobody was thinking about security and
    nobody had done a lot of attacks on these
  • 38:46 - 38:51
    protocols, Whether it it be reliability
    attacks or or just forgery attacks and so
  • 38:51 - 38:59
    on. That wasn't a concerned because this
    was designed for companies working for
  • 38:59 - 39:04
    the government. Right. So everybody was
    interested in collaborating and there were
  • 39:04 - 39:11
    no bad actors. The Internet now is, again,
    quite different. So most of these these
  • 39:11 - 39:21
    old protocols actually aren't so great
    anymore. The basic functionality of DNS or
  • 39:21 - 39:26
    the phonebook is to publish IP addresses
    but you can publish other things as well.
  • 39:26 - 39:32
    If you're interested in DNS there's a good
    talk about that later on. I mentioned it a
  • 39:32 - 39:38
    bit. So the next application I
    want to talk about is SMTP or simple
  • 39:38 - 39:44
    mail transfer protocol. This is what is
    used to deliver every single email in the
  • 39:44 - 39:54
    world. All the time. All day long. Now one
    thing that's a bit interesting or quite
  • 39:54 - 40:03
    interesting but also problematic, I'd say,
    about email and not SMTP per se but the
  • 40:03 - 40:10
    scope of SMTP is, that SMTP is used only
    to send email. So SMTP doesn't have
  • 40:10 - 40:19
    anything to do with receiving email. This
    means that there's a separate mechanism
  • 40:19 - 40:28
    for receiving email. And the way these two
    these two different protocols or
  • 40:28 - 40:38
    mechanisms work end up putting the cost of
    email with the person receiving mail. So I
  • 40:38 - 40:43
    have to pay in order to be there with
    information or with money to get an email
  • 40:43 - 40:48
    address where I have some some gigabytes
    of storage. Whereas people sending email
  • 40:48 - 40:52
    they don't have to pay anything. They just
    need an internet access and then they can
  • 40:52 - 40:57
    send all the emails they want, all day
    long, to every single possible address
  • 40:57 - 41:04
    email address in the world. And that's why
    we have a spam problem on the Internet.
  • 41:04 - 41:13
    Yeah that's a bug. Let's see if this can
    get fixed. Email is so tightly integrated
  • 41:13 - 41:23
    into our everyday lives that ... I'm not
    sure. But let's see. That would be great.
  • 41:23 - 41:31
    So the last application protocol I want to
    mention is the HTTP hypertext transfer
  • 41:31 - 41:38
    protocol that's used for web. You
    recognize it from the web browser URLs.
  • 41:38 - 41:44
    Webpage used to be just hypertext so text
    with some links. That's all they could do
  • 41:44 - 41:55
    in the very beginning. I'd like to show an
    example of SMTP. Actually I have to do
  • 41:55 - 42:18
    something about this, because it's not so
    not so easy to read. Let's see... I
  • 42:18 - 42:26
    should've done that already. Sorry about
    that. Um so this is an example of an email
  • 42:26 - 42:40
    delivery. This is all it takes to send an
    email on the Internet. The arrow pointing
  • 42:40 - 42:47
    left is received from the email server,
    from the SMTP server. And the arrow
  • 42:47 - 42:52
    pointing this way [right] is what we send
    to the email server when we want to send
  • 42:52 - 43:00
    an email. So if we connect to an email
    server, for example mine, it will send us
  • 43:00 - 43:09
    some text. We are using TCP and we're
    using port 25 for SMTP. So we get a stream
  • 43:09 - 43:18
    of text going back and forth. The the
    server tells us 220 and its name, that's
  • 43:18 - 43:25
    some kind of welcome code. We say HELO my
    name is laptop. Because I'm doing this
  • 43:25 - 43:31
    from my laptop. The the mail server says
    OK, good to meet you. And then we say I
  • 43:31 - 43:41
    want to send an email where the sender
    address is test@stuge.se. And if you're
  • 43:41 - 43:48
    paying attention here the sender of the
    e-mail gets to say what the sender address
  • 43:48 - 43:55
    is. So this is why it's super easy for
    anyone to forge email from any sender
  • 43:55 - 44:10
    address. It's just part of the message.
    The server accepts the sender, even though
  • 44:10 - 44:15
    the sender might not even exist. I tell it
    the recipient (RCPT). This is for me,
  • 44:15 - 44:23
    meant for me. The server says OK. Then I
    say here's the DATA for this email and the
  • 44:23 - 44:29
    server says: go on, start sending me the
    contents. And then I send send an email
  • 44:29 - 44:40
    where the the sender is Trollolol and just
    some fake sender address, whatever subject
  • 44:40 - 44:50
    and some text. And in the end I finish
    with a dot to say ok, end of message. The
  • 44:50 - 44:54
    server says OK. And then I say to the
    server I want to QUIT not, I don't want to
  • 44:54 - 45:01
    talk to you anymore. The server says
    "closing" goodbye. And this is e-mail on
  • 45:01 - 45:14
    the network. Last example: a web page,
    access over HTTP. So this is even even
  • 45:14 - 45:20
    simpler. I've simplified this even a
    little bit more. If you want to try this
  • 45:20 - 45:29
    yourself, please do. So HTTP is also TCP
    and port 80. I tried talking to the
  • 45:29 - 45:37
    events.ccc.de web server. Same thing here:
    Arrows pointing this way [right] is what
  • 45:37 - 45:46
    we send when we contact the server. So.
    Connection opens. I send "GET / HTTP1.0"
  • 45:46 - 45:55
    because I want to get the main page and
    I'm saying I'm speaking HTTP version 1.0.
  • 45:55 - 46:00
    And then I tell it OK I want to access
    this start page on the hostname
  • 46:00 - 46:09
    events.ccc.de. Then I send it an empty
    line. That's to say OK this is my request.
  • 46:09 - 46:15
    And then there comes the response (arrows
    going in the other direction [left]) where
  • 46:15 - 46:21
    the web server says what you're asking for
    is not available here where you're asking
  • 46:21 - 46:26
    for it. You have to go somewhere else.
    It's a redirect. The 301 is the HTTP code
  • 46:26 - 46:32
    for redirect. And this content that
    you're asking for, this page, it's been
  • 46:32 - 46:43
    moved permanently. The new location is
    https://events.ccc.de. So I was using an
  • 46:43 - 46:53
    IP and TCP connection with no encryption.
    And that's why I can just type in the GET
  • 46:53 - 46:58
    and the "Host:" line. But the web server
    tells me I'm sorry I don't want to talk to
  • 46:58 - 47:08
    you without encryption. So you have to go
    to this HTTPS address instead. Thank you
  • 47:08 - 47:15
    events.ccc.de! I like encryption. That's
    good. And thank you also to all the
  • 47:15 - 47:21
    angels that make Congress possible because
    without them and without you, who are
  • 47:21 - 47:26
    here, who are angels, there wouldn't be
    any Congress. And also I want to say a
  • 47:26 - 47:33
    huge "thank you" to you in the audience,
    for being curious and wanting to learn
  • 47:33 - 47:36
    something new.
  • 47:36 - 47:45
    applause
  • 47:45 - 47:48
    Herold Angel: Thank you
    very much Peter. Now we have some time
  • 47:48 - 47:52
    left for Q and A so if you have questions
    please do line up at the microphones that
  • 47:52 - 47:57
    you find here. If you want to ask
    anything. Do we have a question from the
  • 47:57 - 48:02
    Internet. No. The Internet is out of
    questions. Do I see anybody standing at
  • 48:02 - 48:14
    any microphone? Please make yourself known
    if I overlook you. Any questions? Oh, at
  • 48:14 - 48:19
    microphone five. Please do ask your
    question.
  • 48:19 - 48:27
    Question: You mentioned that you think
    SMTP has a kind of bug, in the sense that,
  • 48:27 - 48:31
    you can just send an e-mail and the
    responsibility is on the side of the
  • 48:31 - 48:37
    receiver. So if you call it a bug it seems
    you have an easy solution.
  • 48:37 - 48:43
    Answer: I'm sorry, but, no, I don't. I
    mean I wish! That that would be great!
  • 48:43 - 48:50
    It's not so easy to fix because it is a
    property of SMTP, right, and of the e-mail
  • 48:50 - 48:54
    system that we're using. So there was a
    proposal a long long time ago, by somebody
  • 48:54 - 49:00
    much smarter than me, called "Internet
    Mail 2000" where actually the whole thing
  • 49:00 - 49:06
    is switched around, so that the sender has
    to store the message, and the receiver can
  • 49:06 - 49:14
    go and pick it up. So there, the cost is
    is is placed on the sender. And I think
  • 49:14 - 49:19
    that would go a long way to solving the
    spam problem. But it's not compatible with
  • 49:19 - 49:25
    the e-mail software that we have today. So
    it's not clear to me, how we would be able
  • 49:25 - 49:33
    to migrate in a good way, unfortunately.
  • 49:33 - 49:38
    Harald Angel: Thank You. Do we have any other
    questions? That does not seem to be the
  • 49:38 - 49:42
    case, so please give another warm round of
    applause to Peter Stuge. Thank you very
  • 49:42 - 49:44
    much for the talk.
    Peter: Thank you.
  • 49:44 - 49:46
    applause
  • 49:46 - 49:52
    postroll music
  • 49:52 - 50:09
    subtitles created by c3subtitles.de
    in the year 2018. Join, and help us!
Title:
35C3 - How does the Internet work?
Description:

more » « less
Video Language:
English
Duration:
50:09

English subtitles

Revisions