[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
the 9 step program
This is an overview of the different functions names and addresses
perform. I think it makes for a good tool to evaluate the behavior of
multihoming solutions with regard to session setup, session survival
and referrals.
1. The name or address value as it appears to the user. (FQDN, textual
representation of an IPv4 or IPv6 address, port number usually
implied.)
2. The values used by the application to set up a session or
association. (IPv4 or IPv6 address, source value usually set by the
system for outgoing sessions, destination value can often be any
address configured on the system for incoming sessions. Destination
port number provided by application, source port number usually set by
the system.)
3. The values used in the pseudo-header when calculating the checksum.
(IPv4 or IPv6 addresses, port numbers.)
4. The source and destination fields in the IP packet on egress for the
purpose of getting the packet to its destination. (IPv4 or IPv6
addresses.)
5. The destination field in the IP packet on ingress, for the purpose
of recognizing whether a packet is addressed to the local host. (IPv4
or IPv6 address.)
6. The source and destination fields and port numbers in the packet,
for the purpose of demultiplexing transport level sessions. (IPv4 or
IPv6 addresses and port numbers.)
7. The values used in the pseudo-header when calculating the checksum
(see 3).
8. The values used by the application to set up a session or
association (see 2).
9. The name or address value as it appears to the user (see 1).
In traditional IPv4 all the addresses and port numbers remain the same
once they're set. However, when using NAT or IPsec this isn't the case
(ignoring the port numbers for a moment):
IPv4 NAT IPsec tunnel mode
1. s=0, d=FQDNX s=0, d=FQDNX s=0, d=FQDNX
2. | s=A, d=X s=A, d=X | s=A, d=X
3. | s=A, d=X s=A, d=X | s=A, d=X
4. | s=A, d=X s=A, d=X | | s=B, d=Y
--- i --- n --- --- t --- r --- a --- n --- s --- i --- t ---
5. | s=A, d=X s=B, d=X | | s=B, d=Y
6. | s=A, d=X s=B, d=X | s=A, d=X
7. | s=A, d=X s=B, d=X | s=A, d=X
8. | s=A, d=X s=B, d=X | s=A, d=X
9. s=FQDNA, d=X s=FQDNB, d=X s=FQDNA, d=X
(More permuations are used today, such as redirecting TCP sessions such
as in tunneling over SSH.)
For client-server operation, there are very few restrictions: as long
as the checksum computation in 3 and 7 work, pretty much any and all
information can be modified at any step. However, above layer 7 there
is usually the requirement that the values in 1 and 9 match (in other
words, the host reached is really the owner of the FQDN or address used
in 1).
This changes radically when we introduce referrals: in that case, it's
vitally important that the values in step 2 of the original session
match those in step 5 or 8 of the session that is created after the
referral. In traditional IP this is easily accomplished because the
values never change, and in IPsec because the modified addresses are
restored to their original values before the application gets to use
them in a referral.
Session survivability can be accomplished by (after a rehoming event)
modifying addresses before or after 3 and changing them back somewhere
between 5 and 8. Note though that this seriously gets in the way of
firewalls sitting between 4 and 5, just like IPsec does.
Another issue comes up when an application wants to connect to a remote
host and the first (or only) address available in step 1 isn't
reachable. There are several ways to solve this, such as:
- changes to step 1 (ie, the application must try multiple addresses)
- modification of the values somewhere in step 2, 3 or 4 (but then one
of steps 5 - 9 must restore it for referrals to work)
Do you guys feel it will be useful to look at the proposed solutions or
solution groups in this light?