Subject: RE: [Tsvwg] Establishment of SCTP association

From: [email-masked]
Date: Thu, 8 Jan 2004 14:17:40 +0200

Randall,

Based on the scenario you presented and assuming that both hosts have 2 network interfaces Host-A has at least the following entries in its routing table

Destination	    Gateway        Iface
0.0.0.0         ips1-router    eth0            #IP-1 assigned to interface eth0
ips4-subnet     ips2-router    eth1            #IP-2 assgined to interface eth1 

Host-Z's routing table looks like

Destination	    Gateway        Iface
0.0.0.0         ips4-router    eth0            #IP-4 assigned to interface eth0
ips1-subnet     ips3-router    eth1            #IP-3 assgined to interface eth1 

Without the second entry in both routing tables, administrator would have to manually reconfigure the routing table in case eth0 fails. How else host would know where to send the IP packet after an interface failure? (Or are you assuming that in case of an interface failure there is some magic script which removes the old void default route entry and adds a new one?)

So, when host-Z sends INIT-ACK back it is going to choose eth1 (IP-3 as source IP address) because of the longest prefix match rule. Not eth0 as you stated. 

Host-Z's routing entries could be in other order where host-Z's default route is ips3

Destination	    Gateway        Iface
0.0.0.0         ips3-router    eth0            #IP-3 assigned to interface eth0
ips2-subnet     ips4-router    eth1            #IP-4 assgined to interface eth1 

But this would not change the situation as IP-3 would be still chosen as the source IP address.

Obviously having separate routing entries for each and every possible subnet is not very practical. Therefore the use of multiple routing tables when multi-homing is used makes lots of sense. In that case each routing table would have a default route entry. The selection of the routing table would be based on the source IP address. Which also guarantees that scenarios like you, Randall, presented would not happen, i.e. IP packet would be sent through IPS' subnet but the IP packet's source IP address did not come from the IPS' subnet thus causing the packet to be filtered.

/Mikael

> 
> Host-A                                                        
>             
>    Host-Z
> 
> IP-1    ---------------||net-isp1                        
> net-isp3||-------IP-3
> 
> IP-2    ---------------||net-isp2                        
> net-isp4||-------IP-4
> 
> 
> Now Host-A chooses (for whatever reason.. admin etc) a default
> route of net-isp1. Host-Z chooses a default route of net-isp4..
> Both sides bind all addresses.
> 
> Host-A sends an INIT to IP-3.
> 
> We choose the default route, and thus pick up the source address IP-1 
> destination IP-3
> and off goes the INIT
> 
> ----------Src:IP-1---Dest:IP-3(INIT(IP-1,IP-2))----------------->
>      
> 
> Host-Z processes the INIT, having a listner it responds to 
> IP-1 out its
> default route, choosing the best source address for net-isp4 
> (the default
> route) which is IP-4. Note that if it did has you request the 
> packet should
> be ingress-filtered and dropped.
> 
> <------------------Src:IP-4---Dest:IP-1(INIT-ACK(IP-3,IP-4))----------
> 
> 
> This is one of the scenarios that were discussed back when
> SCTP was developed and the wording you asking to change was
> discussed... The wording was put in for a VERY SPECIFIC 
> purpose... this 
> one :->
> 

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 8 Jan 2004 14:34:00 +0100

On 8. Jan 2004, at 13:17 Uhr, <[email-masked]> wrote:
Mikael,

assume host 1 has a route for 10.1.1.0/16 through eth0 (10.1.1.1/24) 
and 10.2.0.0/16 through eth1 (10.2.1.1/24).
Furthermore host 2 has only one interface 10.1.2.1 and a default route 
to eth0 (10.1.2.1/24).

Assume that the default router of host 2 has connectivity to both 
routers used by host 1.

If host 2 sends a INIT to host 1 using 10.1.1.1 as distination address 
host 1 will send back the
INIT-ACK to 10.1.2.1 and 10.1.1.1 as source address. Everything is fine.

But if host 2 sends the INIT to host 1 using 10.2.1.1 as destination 
address host 1 wil send
back the INIT-ACK to 10.1.2.1 using eth0 and therefore would choose 
10.1.1.1 as a source address
of the INIT-ACK.

Using your rule the association could not be established in this 
scenario. You do not have
redundancy here, but that is clear. But is is important to accept 
INIT-ACK from addresses not
being the destination address of the INIT.

You could say the host 1 could use the other address still using the 
router but the router
may do ingress filtering.

Best regards
Michael

> Randall,
>
> Based on the scenario you presented and assuming that both hosts have 
> 2 network interfaces Host-A has at least the following entries in its 
> routing table
>
> Without the second entry in both routing tables, administrator would 
> have to manually reconfigure the routing table in case eth0 fails. How 
> else host would know where to send the IP packet after an interface 
> failure? (Or are you assuming that in case of an interface failure 
> there is some magic script which removes the old void default route 
> entry and adds a new one?)
>
> So, when host-Z sends INIT-ACK back it is going to choose eth1 (IP-3 
> as source IP address) because of the longest prefix match rule. Not 
> eth0 as you stated.
>
> Obviously having separate routing entries for each and every possible 
> subnet is not very practical. Therefore the use of multiple routing 
> tables when multi-homing is used makes lots of sense. In that case 
> each routing table would have a default route entry. The selection of 
> the routing table would be based on the source IP address. Which also 
> guarantees that scenarios like you, Randall, presented would not 
> happen, i.e. IP packet would be sent through IPS' subnet but the IP 
> packet's source IP address did not come from the IPS' subnet thus 
> causing the packet to be filtered.
>
> /Mikael
>
>>
>> Host-A
>>
>>    Host-Z
>>

---

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Thu, 08 Jan 2004 08:24:29 -0600

>So, when host-Z sends INIT-ACK back it is going to choose eth1 (IP-3 as source IP address) because of the longest prefix match rule. Not eth0 as you stated. 
I never said anything about assigning specific routes to 
isp3-subnet/isp1-subnet as
you describe above.. Most systems do NOT have specific routes to
various sub-nets. Take a look at most machines and you will find only one
default route period.

Now you can, in linux and with KAME-mpath, get multiple default routes. But
you will only end up using the first route (until the first one fails).

So lets go back to my diagram:

Host-A                                                         Host-Z
IP-1    ---------------||net-isp1              net-isp3||-------IP-3
IP-2    ---------------||net-isp2              net-isp4||-------IP-4

Invision a big cloud between all the ISP's and Host-A and Host-Z
are just two random hosts that communicate upon the
internet.. there network admin's have no idea that
today for what ever reason the two will talk.. they just
happen to.. maybe a new employee joins and decides
to converse with an ole friend :->

The routing tables for Host-A may look like:

Internet:
Destination        Gateway            
default                isp -1                
isp-2/24               link#1          

Or if multi-path is in paly you might see:

Internet:
Destination        Gateway         
default                isp-1                
default                isp-2

But our Host-A would NOT have any sort of route in for isp-3 or isp-4.

This is the environment that SCTP must work in.. not something 
pre-configured.

In the multi-path case SCTP needs to be able to ask the routing system when
it thinks there is problems with an endpoint something like

rt_find_alternate(dest, old-route);

instead of the typcial

rt_alloc(dst)

call... I.e. to be effective with default routes the routing system needs a
method to query it for an different route to the same place (if such 
exists). We
implemented this in KAME and it works quite nicely.....

>But this would not change the situation as IP-3 would be still chosen as the source IP address.
Sorry.. the above is NOT how the routing tables would look. You would
have NO specific entyr to ips2-subnet...

>
>Obviously having separate routing entries for each and every possible subnet is not very practical. 
>

Exactly.. you have to deal with one default.. and possibly multipe 
defaults as
well...

>Therefore the use of multiple routing tables when multi-homing is used makes lots of sense. In that case each routing table would have a default route entry.
>
Or MULTIPLE default routes.. linux as allowed this for a long
time.. not that I they have any interface to use this besides the
first outbound route interface failing completely.... at least back
last time I looked... which as been some time..

The point is multiple defaults are something I think we will see as
bandwidth and connections get cheaper...

> The selection of the routing table would be based on the source IP address. Which also guarantees that scenarios like you, Randall, presented would not happen,
>

Source based routing is still a research item and only shows up
in some limited places (I think ISP's sometimes have this for example).

We do not select destination routes using the source address... not yet..

> i.e. IP packet would be sent through IPS' subnet but the IP packet's source IP address did not come from the IPS' subnet thus causing the packet to be filtered.
>
Which is exactly all of my points.. it just seems you are not making the
connection...

As I stated.. this was discussed in much detail when SCTP was created... 
you can
go back and check the mailing list archives if you would like.. I also 
have even
more email than that stashed away somewhere...

Basically there are specific reasons why the source address may NOT
be where the packet was sent on either the INIT or INIT-ACK.. this is
ok.. the protocol allows for it by design.

R

-- 
Randall R. Stewart
815-477-2127 (office)
815-342-5222 (cell phone)