address pair exploration, flooding and state loss

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Following with the approach suggested in the previous mail, there are 
three functions required that are conceptually different. The 
mechanisms for their provision are likely to require some form of 
packet exchange. the roadmap then is to define what is required for 
each of them and then see potential optimizations that could result 
from the merging of some of the packets involved.
So the three functions are the following:

Address pair Exploration:
------------------------
The goal here is to determine if a given address pair is working i.e. 
that a packet carrying one of the addresses as source address and the 
other one as destination address can actually reach the destination 
from the source.
Note that reachability can be unidirectional, and it is an explicit 
goal to be able to discover unidirectional paths.

The next question is what is the form of the packet exchange required 
for Address pair Exploration and what information need to be included 
in those packets. The faildet draft defines a mechanisms where nodes 
send multiple poll messages using different address pairs. In each of 
those poll packets, the node includes reachability information obtained 
from previously received poll packets.
So, what is the information that needs to be included in these poll 
packets?
It seems that the minimum required is to include enough information to 
allow the node to identify which packet was received by the peer.
Consider the following situation:
node A with address A1 and A2, node B with address B1 and B2

- node A starts address pair exploration sending a poll packet 1 using 
A1 and B1.
- node B replies sending a poll packet 2 using B1 and A1.

The packet needs to carry enough information to allow node A to 
understand that the poll packet 2 is a reply to poll packet 1 i.e. that 
the path from A1 to B1 is working.
Such information could be simply the address pair or a identification 
number of poll packets.

Now, consider a situation where the reverse path is not working (as 
depicted in the faidet draft)

- node A starts address pair exploration sending a poll packet 1 using 
A1 and B1.
- node B replies sending a poll packet 2 using B1 and A1 but this 
packet is lost.
- node B send another poll packet 3, now using A1 and B2, and this 
packet reaches node A

Packet poll 3 should carry information about the fact that poll packet 
1 was properly received by node B (A1 to B1 path is working). This 
again can be achieved carrying the poll packet 1 identifier in poll 
packet 3.

Note that poll packet identifier are assigned by the issuer of the poll 
packets, since it will be used by itself to bind received poll packets 
with issued poll packets. I am assuming here that one poll packet will 
result in many replies and all of the replies will carry the initial 
poll packet identifier.

So, each poll packet needs to contain the following information:
- its own poll packet identifier
- the poll packet identifiers of previously received poll packets, in 
the case that this poll packet is issued as a reply to a poll packet.

Anything else? security stuff?

Flooding protection:
-------------------
The goal here is to determine if the receiver is willing to accept the 
packets belonging to a communication established with a given ULID 
through an  alternative locator.

In this case, it is required to include information about the ULID 
involved in the communication. Note that unidirectional connectivity is 
also a possibility here.

So, this exchange essentially consists in two packets:
- one query packet, that asks if a node is willing to receive packets 
associated with communication involving ULID U though locator Y
- one reply packet that informs that the node is willing to receive 
packets associated with a communication involving ULID U though locator 
Y

Now, note that because of unidirectional connectivity, reply packets 
may have the same addresses than query packet. However, the reply 
packet must contain some information carried in the query packet so 
that the receiver can proof that he is able to receive packets through 
the alternative locator.

So, the information to be carried in the Query packet is:
- the ULID
- the alternative locator (included in the destination address)
- a query identifier
(this packet must include the alternative locator in the dst address 
field)

The reply packet will include:
- the ULID
- THe alternative locator
- the query identifier
(the addresses included in the packet can be any address, no need to be 
the alternative locator or the ULID. The query identifier needs to be 
randomly generated, i.e. its value must not be predictable)

State Loss:
-----------

The goal here is to detect if the context state has been lost. The 
reasons for this lost may be related with failures, or with early 
garbage collection.

The packet exchange would require the following information:

- a packet that refers to an existent context. This packet need to be 
identified as a shim packet and must contain context identification 
(i.e. context tag). In addition, the packet needs to include a packet 
identifier, so that it is possible to bound the reply to this initial 
packet (this is so in order to prevent some forms of attacks similar to 
TCP reset attacks, where an attacker can force a node to act as if the 
peer has lost its state)

In case that the context exists, a affirmative reply packet could be 
defined

In case that the context does not exists, then the reply packet should 
contain:
- inform that the refered context does not exist
- information about the context i.e. context identifier
- initial packet identifier, so that it is possible to proof that this 
packet is a reply to recently sent packet.

Including the context identifier does provide some protection to the 
TCP reset type of attacks, since the attacker need to discover the 
context identifier.
The additional protection provided by including a packet identifier, 
comes form the fact that the attacker needs to have intercepted a 
packet recently (and it is not enough to intercept one packet at any 
time since the session was established) Not sure if the achieved 
protection is worthy though...

Well, once we came up with the set of required information for each 
exchange, then we could move to optimizations, merging these packet 
exchanges...


Regards, marcelo