Subject: [Tsvwg] SCTP mixed scope associations

From: Mark Butler <[email-masked]>
Date: Wed, 15 Mar 2006 18:02:55 -0700

The draft <draft-stewart-tsvwg-ipv4-00> from November 2002 recommended a 
set of IPV4 address advertsing rules so that link local address were not 
advertised when private addresses were available, private addresses were 
not advertised when global addresses were available, and so on.  One of 
the purposes of these rules was to keep associations from aborting 
improperly due to ABORTs received from different privately addressed 
endpoints than were intended (same address, different network).

The advertising rules as specified do not support the use of redundant 
paths in the case where a pair of hosts have access to two independent 
networks, one privately numbered and one globally numbered, however.  
This is a common configuration where the inability to failover to either 
path is a problem.  For example,  an organization with sites with links 
to both a private WAN and to the global Internet.

I suggest the following procedure to support mixed scope associations:

(1) Define a new INIT target address parameter that contains the type 
and address of addresses in the connect list. (this is helpful but not 
necessary).

(2) Application layer: Sort target addresses in order of decreasing 
scope (unless there is a reason to do otherwise)

(3) SCTP layer: When selecting local addresses to be placed as 
parameters in an INIT chunk, select those with greater or equal scope 
than the  scope of the specified target address with the narrowest 
scope.  Include any specified target addresses not used as the INIT 
destination address in target address parameters. 

(4) When processing an INIT received on an address with limited scope, 
compare target addresses with greater or equal scope against the list of 
valid addresses for the endpoint.  Exclude the INIT packet destination 
address. If any global address matches, or all the remaining private and 
link local addresses match (where there are one or more such addresses), 
continue INIT processing as usual.  Otherwise, return an ABORT with the 
T-bit set and a vtag of _zero_.

(5) When selecting local addresses to be placed as parameters in an INIT 
ACK, select those that have greater than or equal scope than the 
initiator address with the narrowest scope.

(6) When a valid T bit set ABORT chunk arrives, (including vtag zero in 
COOKIE WAIT state) remove the source address from the peer address 
list.  If there are no peer addresses left, abort the association.

Rationale:

(R2)  Attempting to connect to globally scoped addresses first avoids 
private address aliasing problems.

(R3)  No need to use private or link local addresses unless similarly 
scoped addresses are explicitly specified.

(R4)  Allows aliased targets to disambiguate INIT requests meant for 
other hosts using the included target addresses.  Zero T-ABORT vtag 
avoids improperly aborting associations, while giving the initiator 
notification to quit sending  traffic to that address.

(R5)  Same as R2.

(R6)  Same as R4.  Also protects against strange routing anomalies and 
misconfigurations.

Example:

Host A with addresses 63.55.1.1 and 10.0.1.1 connects to Host B with 
addresses 128.43.2.1 and 10.0.2.1.  If application on A binds to 
INADDR_ANY and requests a connection only to (128.43.2.1), only 
63.55.1.1 is included in the INIT parameter list, because the other 
local address is of a narrower scope.  If it specifies (128.43.2.1 and 
10.0.2.1), both local addresses are included in the INIT parameter list, 
and the global address is used as the destination address for the INIT.

However, suppose another host with address 10.0.2.1 exists on Host A's 
network. If it receives an INIT meant for Host B, it would look at the 
target address parameter list, determine that the request was not meant 
for it, and return a T-ABORT instead of a normal ABORT. Host A would 
notice that, remove 10.0.2.1 from the peer address list, and keep trying 
on 128.43.2.1.  A more likely case is where an alias of 10.0.1.1 exists 
on Host B's network, in which case it would return a T- ABORT to Host B, 
which would be safely handled without aborting the association.

Most of the problems, of course, are eliminated by the first part of 
(3), which allows mixed scope associations when explicitly requested, 
but does not create them by default.  The rest of the rules handle cases 
where mixed scope associations would otherwise fail unexpectedly, such 
as where organizations agree to share some private address space between 
them, but not other parts, such as shared 10/8 and private 192.168/16.

Comments? Problems?

 - Mark

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Thu, 16 Mar 2006 05:12:43 -0500

Mark:

Now it may not have been clearly specified but it did
handle this case...

So lets say I have two hosts
A/Z

A has 10.1.1.2
and   70.1.1.2

Z has 10.1.1.3
and   70.1.1.3

Now The way the draft would handle this is:

If A
----INIT---> 10.1.1.3

You will get in the INIT:
10.1.1.2 & 70.1.1.2

If A
----INIT--->70.1.1.2

You will get in the INIT no addresses
or at most 70.1.1.2.

Now the reason you do it this way is exactly has
you say.. there are a LOT of sites that might have
the above scenario.. and just because we
both have 10.1.1.x does NOT mean that the 10.1.1.x
I have is the same network as the 10.1.1.x you have.
The only way to know for sure is if we can
exchange packets on that network..

I don't see how we need anything else.. we
probably need to resurect those drafts (the v4 and v6
one).. and merge them togehter.. I think Michael
and I were doing this at one time.. but never
circled back.. since the site local stuff was
in such flux at the time... (for v6) we probably
need to look where they are at and make a new
composite scoping draft...

R

-- 
Randall Stewart
ITD - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

---

From: Mark Butler <[email-masked]>
Date: Thu, 16 Mar 2006 09:36:48 -0700

Randall Stewart wrote:

> <snip>

Okay that makes sense.  Using target address parameters has a few 
advantages, however.  One is that the INIT can be directed to the global 
address, and any ambiguity in the attached local addresses will be 
automatically resolved without aborting.

- Mark