Move path control to separae source file

Author: huitema

CMakeLists.txt

@@ -90,6 +90,7 @@ set(PICOQUIC_LIBRARY_FILES
     picoquic/newreno.c
     picoquic/pacing.c
     picoquic/packet.c
+    picoquic/paths.c
     picoquic/performance_log.c
     picoquic/picohash.c
     picoquic/picoquic_lb.c

picoquic/packet.c

@@ -1851,166 +1851,6 @@ int picoquic_incoming_0rtt(
     return ret;
 }
 
-/*
-Find path of incoming packet
-
-A path is defined by a pair of addresses. The path is created by the client
-when it learns about a new local or remote address. It is created by the
-server when it receives data from a not yet identified address pair.
-
-We associate a local CID with a path. This is the CID that the peer uses
-to send packet. This is a loose association. When a packet is received, the
-packet is associated with a path based on the address tuple. If this is a
-new tuple, a new path should be created, unless too many paths have been
-created already (some heuristics needed there). 
-
-Different scenarios play here:
-
- - If the incoming CID has not yet been seen, we treat arrival as a
-   migration attempt and pursue the validation sequence.
-
- - If this is the same incoming CID as an existing path, we treat it
-   as an indication of NAT rebinding. We may need some heuristic to
-   decide whether this is legit or an attack. If this may be legit, we
-   create a new path and send challenges on both the new and the old path.
-
- - If this is the same tuple and a different incoming CID, we treat that
-   as an attempt by the peer to change the CID for privacy reason. On this
-   event, the server picks a new CID for the path if available. (May need
-   some safety there, e.g. only pick a new CID if the incoming CID sequence
-   is higher than the old one.)
-   
-NAT rebinding should only happen if the address was changed in the
-network, either by a NAT or by an attacker. NATs are:
-
- - rare but not unheard of in front of servers
-
- - rare with IPv6
- 
-  - rare if the connection is sustained
-  
-A small problem here is that the QUIC test suite include some pretty
-unrealistic NAT rebinding simulations, so we cannot be too strict. In
-order to pass the test suites, we will accept the first rebinding
-attempt as genuine, and be more picky with the next ones. They may have
-to wait until validation timers expire.
-
-Local CID are kept in a list, and are associated with paths by a reference.
-If a local CID is retired, the reference is zeroed. When a new packet arrives
-on path with a new CID, the reference is reset.
-
-If we cannot associate an existing path with a packet and also
-cannot create a new path, we treat the packet as arriving on the
-default path.
-*/
-
-int picoquic_find_incoming_path(picoquic_cnx_t* cnx, picoquic_packet_header* ph,
-    struct sockaddr* addr_from,
-    struct sockaddr* addr_to,
-    int if_index_to,
-    uint64_t current_time,
-    int* p_path_id,
-    int* path_is_not_allocated)
-{
-    int ret = 0;
-    picoquic_path_t* path_x = NULL;
-    picoquic_tuple_t* tuple = NULL;
-    int path_id = (ph->l_cid == NULL)?0:picoquic_find_path_by_unique_id(cnx, ph->l_cid->path_id);
-
-    if (path_id < 0) {
-        /* Either this path has not yet been created, or it was already destroyed.
-        * The packet decryption was successful, which means that the CID is valid,
-        * but on the server side we might have a "probe".
-         */
-        if (cnx->nb_paths < PICOQUIC_NB_PATH_TARGET &&
-            (cnx->quic->is_port_blocking_disabled || !picoquic_check_addr_blocked(addr_from)) &&
-            picoquic_create_path(cnx, current_time, addr_to, addr_from, if_index_to, ph->l_cid->path_id) > 0) {
-            /* if we do create a new path, it should have the right path_id. We cannot
-            * assume that paths will be created in the full order, so that means we may
-            * have to create "empty" paths in invalid state. Or, more simply,
-            * create a path and override the unique path id, which should be OK
-            * as that unique ID does not exist.
-            * TODO: modify path creation to force path_id, return error if impossible.
-             */
-            path_id = cnx->nb_paths - 1;
-            path_x = cnx->path[path_id];
-
-            /* when creating the path, we need to copy the dest CID and chose
-             * destination CID with the matching path ID.
-             */
-            path_x->first_tuple->p_local_cnxid = picoquic_find_local_cnxid(cnx, path_x->unique_path_id, &ph->dest_cnx_id);
-            picoquic_assign_peer_cnxid_to_tuple(cnx, path_x, path_x->first_tuple);
-        }
-    }
-    else
-    {
-        path_x = cnx->path[path_id];
-        tuple = path_x->first_tuple;
-
-        /* If the local CID is not set, set it */
-        if (path_x->first_tuple->p_local_cnxid == NULL) {
-            path_x->first_tuple->p_local_cnxid = picoquic_find_local_cnxid(cnx, path_x->unique_path_id, &ph->dest_cnx_id);
-            if (!cnx->client_mode && cnx->is_multipath_enabled && path_x->first_tuple->challenge_verified) {
-                /* If the peer renewed its connection id, the retire connection ID frame may already
-                 * have arrived on a separate path. If the server noticed that, it should also renew
-                 * its "remote path" ID */
-                (void)picoquic_renew_connection_id(cnx, path_id);
-            }
-        }
-
-        /* Treat the special case of the unkown local address, which should only happen
-         * for clients and for the first tuple. */
-        if (path_x->first_tuple->local_addr.ss_family == AF_UNSPEC) {
-            picoquic_store_addr(&cnx->path[path_id]->first_tuple->local_addr, addr_to);
-        }
-
-        /* Look for the best match among existing tuples */
-        while (tuple != NULL) {
-            /* If the addresses match, we are good. */
-            if (picoquic_compare_addr(addr_from, (struct sockaddr*)&tuple->peer_addr) == 0 &&
-                picoquic_compare_addr(addr_to, (struct sockaddr*)&tuple->local_addr) == 0) {
-                break;
-            }
-            else
-            {
-                tuple = tuple->next_tuple;
-            }
-        }
-        if (tuple == NULL) {
-            /* If the addresses do not match, we have two possibilities:
-            * either the creation of a new tuple, or a NAT rebinding on an existing tuple.
-            * In all cases, we need to create a new tuple. In the NAt rebinding cases, we
-            * may be a bit more agressive, i.e., immediately promote the new tuple
-            * as the default.
-            */
-
-            if (picoquic_check_cid_for_new_tuple(cnx, path_x->unique_path_id) == 0 &&
-                (tuple = picoquic_create_tuple(path_x, addr_to, addr_from, if_index_to)) != NULL){
-                if (picoquic_assign_peer_cnxid_to_tuple(cnx, path_x, tuple) == 0) {
-                    picoquic_set_tuple_challenge(tuple, current_time, cnx->quic->use_constant_challenges);
-                    tuple->challenge_required = 1;
-                }
-            }
-            /* TODO: clean up in case of failure. */
-        }
-        else {
-            /* If the addresses do match, but the CID do not, we have a case of NAT rebinding.
-             */
-            if (tuple == path_x->first_tuple &&
-                picoquic_compare_connection_id(&path_x->first_tuple->p_local_cnxid->cnx_id, &ph->dest_cnx_id) != 0) {
-                path_x->first_tuple->p_local_cnxid = picoquic_find_local_cnxid(cnx, path_x->unique_path_id, &ph->dest_cnx_id);
-                if (cnx->client_mode == 0) {
-                    (void)picoquic_renew_connection_id(cnx, path_id);
-                }
-            }
-        }
-    }
-    *p_path_id = path_id;
-    cnx->path[path_id]->last_packet_received_at = current_time;
-
-    return ret;
-}
-
 
 /*
  * ECN Accounting. This is only called if the packet was processed successfully.