a-params-class new >o r> o-stack >stack
    [: ['] a-params >body scan-vals ;] execute-parsing ;
: /span 2drop
    a-params:dispose o-stack stack> >r o> ;
synonym div span
: /div /span cr ;
synonym p div
synonym /p /div
synonym style span
synonym /style /span

object class{ table-params
    field: align$
    field: cellpadding$
    field: cellspacing$

    a-params-class new >o r> o-stack >stack
    [: ['] a-params >body scan-vals ;] execute-parsing ;
: /span 2drop
    a-params:dispose o-stack stack> >r o> ;
synonym div span
: /div /span cr ;
synonym p div
: /p /div cr ;
synonym style span
synonym /style /span

object class{ table-params
    field: align$
    field: cellpadding$
    field: cellspacing$

<h1>Ack cookies</h1>

<p>net2o has a very low bandwidth acknowledge protocol (one ack for 32 packets,
the ack is a small packet, 64 or at most 128 bytes, while the data is 32k). And
net2o's flow control relies on the receiver to signal correct time stamps.</p>


<p>So a malicious receiver can just spoof some answers and drive the sender to
create a lot of traffic. To prevent acknowledge spoofing, we require the
receiver to compute a "cookie" for every packet transmitted - this cookie is
something that proves he has received and correctly decrypted the packet, but
the cookie itself is actually never sent around. We use Keccak's hidden state
to create this cookie - reduced to a 64 bit number (this is more than
sufficient - anything an attacker can create is bandwidth). We xor all cookies
of one acknowledge lump together.</p>

<p>A malicious receiver who creates excessive traffic now will not receive the
packets anymore, which prevents him from creating a legit acknowledge.</p>

# Ack cookies #

net2o has a very low bandwidth acknowledge protocol (one ack for 32 packets,
the ack is a small packet, 64 or at most 128 bytes, while the data is
32k). And net2o's flow control relies on the receiver to signal correct time
stamps.

So a malicious receiver can just spoof some answers and drive the sender to
create a lot of traffic. To prevent acknowledge spoofing, we require the
receiver to compute a "cookie" for every packet transmitted — this cookie is
something that proves he has received and correctly decrypted the packet, but
the cookie itself is actually never sent around. We use Keccak's hidden state
to create this cookie — reduced to a 64 bit number (this is more than
sufficient — anything an attacker can create is bandwidth). We xor all cookies
of one acknowledge lump together.

A malicious receiver who creates excessive traffic now will not receive the
packets anymore, which prevents him from creating a legit acknowledge.

<h1>Handover</h1>Mobile communication is one of the things that didn't come to
the mind of the people who invented the Internet 30 years ago. There was
over-the-air communication even before, especially the ALOHAnet should be
mentioned, but the computers were too large to be carried around. And all
stations were within reach of each others (by using pretty strong signals - the
Hawaii islands are not that small). Handover means that an end node regularly
changes the station it's connected to. With a switching system like net2o, this
means, the address changes. The communication however should continue even when
such an address change happens frequently. And it should work even when both
nodes hop from station to station. No complicated renegotiation should happen,
and no routing server should be queried if such a thing happens on an open
connection. The idea to achieve this is fairly trivial:

<ul><li> net2o addresses are unique connections
<li>Any reply to an open connection is sent to the last
received return address
<li>When an end node changes the station, it will ping
all open connections and thus inform the peers about that change
<li>Changing
stations need a time overlap, during which the end node is reachable through
both the old and the new address.
</ul>

This overlap time is necessary if two
connected nodes change station at the same time. As the communication itself is
protected by encryption from intruders, this is save even without presenting
some ticket for the handover. The overlap time can be also achieved by
temporarily forwarding packets from the old destination - this is the preferred
way to migrate virtual machines to new hosts - the old host temporarily
forwards all received packets to the new host, and after a short time can be
used for something else. From a firewall point of view, this approach looks
scary. When a system opens a connection (which consists of some address
ranges), this address range is open to anybody. And worse yet, since the
address is not encrypted, everybody can know which are legitimate addresses, by
observing the traffic for a while. The blocking of intruders happens solely
through encryption, and that encryption is unknown to the firewall (which is
the whole point of encryption, after all).

# Handover #

Mobile communication is one of the things that didn't come to the mind of the
people who invented the Internet 30 years ago. There was over-the-air
communication even before, especially the ALOHAnet should be mentioned, but
the computers were too large to be carried around. And all stations were
within reach of each others (by using pretty strong signals - the Hawaii
islands are not that small). Handover means that an end node regularly changes
the station it's connected to. With a switching system like net2o, this means,
the address changes. The communication however should continue even when such
an address change happens frequently. And it should work even when both nodes
hop from station to station. No complicated renegotiation should happen, and
no routing server should be queried if such a thing happens on an open
connection. The idea to achieve this is fairly trivial:

* net2o addresses are unique connections
* Any reply to an open connection is sent to the last received return address

* When an end node changes the station, it will ping all open connections and
  thus inform the peers about that change

* Changing stations need a time overlap, during which the end node is
  reachable through both the old and the new address.


This overlap time is necessary if two connected nodes change station at the
same time. As the communication itself is protected by encryption from
intruders, this is save even without presenting some ticket for the
handover. The overlap time can be also achieved by temporarily forwarding
packets from the old destination - this is the preferred way to migrate
virtual machines to new hosts - the old host temporarily forwards all received
packets to the new host, and after a short time can be used for something
else. From a firewall point of view, this approach looks scary. When a system
opens a connection (which consists of some address ranges), this address range
is open to anybody. And worse yet, since the address is not encrypted,
everybody can know which are legitimate addresses, by observing the traffic
for a while. The blocking of intruders happens solely through encryption, and
that encryption is unknown to the firewall (which is the whole point of
encryption, after all).

	presentation (only Chaos West capture this time, as they did a very
	professional job).

## Discussions ##

* The [pki](pki.md) problem
* [Client authentication](client-auth.md)
* [Handover](handover.wiki)
* [Ack cookies](ackcookies.wiki)
* [Random number seat belts](rng.md)
* [Key format](key-format.md)
* [Key revocation](key-revocation.md)
* [NSA backdoor](nsa-backdoor.md)
* [Data retention](data-retention.md)
* [Onion Routing](onion-routing.md)
* [Threat Model](threat-model.md)

	presentation (only Chaos West capture this time, as they did a very
	professional job).

## Discussions ##

* The [pki](pki.md) problem
* [Client authentication](client-auth.md)
* [Handover](handover.md)
* [Ack cookies](ackcookies.md)
* [Random number seat belts](rng.md)
* [Key format](key-format.md)
* [Key revocation](key-revocation.md)
* [NSA backdoor](nsa-backdoor.md)
* [Data retention](data-retention.md)
* [Onion Routing](onion-routing.md)
* [Threat Model](threat-model.md)