Subject: RE: [Tsvwg] RE: multihoming issues via SCTP

From: [email-masked]
Date: Wed, 12 Sep 2001 17:34:31 +0300

Hi people!

	Some comments inline...

	... snip...

> >         I was playing with that source address selection 
> issue, and even if
> > you can set the source IP address in the outgoing 
> datagrams, the source
> > network card (and so the path) used is something SCTP can't 
> control at all.
> > So in the worst case, you would be using one network card 
> for the outgoing
> > packets (artificially setting the source address, when the 
> corresponding NIC
> > is not used because the routing tables say you should use 
> the other one),
> > and receiving the SACKs through the other card (as they are 
> directed to the
> > source address you set in your outgoing datagram)... In that case,
> > multihoming not only doesn't help, but makes things worse 
> (as the failure of
> > any of your two source cards/paths would mean that the 
> whole association
> > will be down...) :-/
> 
> It is really quite SILLY to think that a kernel land SCTP can 
> NOT select
> the source address. Even most user land version can do this 
> since it is
> using raw sockets. I just finished writting a 
> "source-address-selection"
> module for the SCTP stack I am working on it:

	Either I'm silly enough to think that, or hopefully I haven't
practiced that much with kernel land implementations... :-)

	As far as I know after some time working on it (I might know just a
little) in Windows, using raw sockets, you can't even write the IP header
yourself. If I have two NICs (Ethernet0 and Ethernet1) and correspondingly
two IP addresses (IP0 and IP1), I have to open two sockets, each of them
bound to one of the addresses. Then, each created socket provides you the
data sent to the specific IP address it is bound to, which is received by
the corresponding NIC (Ethernet0 receives datagrams sent to IP0 and
Ethernet1 receives the ones sent to IP1). So far, everything is nice, the
problem is when you send data...

	If the routing tables say that a datagram directed to certain IP
address should be sent to a certain router, and that the source interface
should be Ethernet0 for example, even if I use the socket which is supposed
to be linked with the other NIC, Ethernet1, and the IP source address used
in the outgoing datagram is IP1, the packet will be sent using Ethernet0
(that's what Ethereal says)... :-/

	After several trials I gave up and just thought there was no way to
change this. I know LINUX/UNIX offer you more possibilities to control
everything and that might be the reason why you can control the card used
and I can't...

> 
> If bound to all addresses
> A) Will set the source address to 0, allowing the IP stack
>    to select the address of the interface that it emmits the
>    packet on. This is how UDP packets bound to all work as well.

	I don't know if this is a misunderstanding... Do you mean IP source
address or Ethernet source address? I meant Ethernet addresses (the physical
card used)... I don't have problems with IP source address selection...

> If not bound to all interaces
> B) If bound to a sub-set of the machines addresses it will generate
>    the route and then look to see if the interface is one of the
>    bound subset. If so it SETS the source address to the address
>    of this outbound interface.
> 
> C) If we are bound to a sub-set and the interface we will emmit
>    the packet on is NOT bound, then the implementation will rotate
>    the source address amongst its bound interfaces by setting the
>    source address of the packet round robin amongst the bound
>    interfaces.

	You mean here selecting the IP source address, right? But, ok, you
choose your source IP address but then the packet can go out from any
Ethernet card... (as far as I know... maybe there is any SETSOCKOPT or
something that makes compulsory the use of a certain NIC...)

	The more I think about this the more I believe that you shouldn't
really be able to choose your source NIC... Doing so could lead to packet
loss. Your routing tables tell you that to reach a certain IP destination
you must use certain gateway which is the one who knows how to route the
datagram correctly. That gateway might be reachable through a certain NIC
but not through the rest...

	I must confess that I'm not a routing guru and that I still had some
problems to set up the routing tables in the bake-offs and make them work (I
swear last time it was just a physical problem with those cross over wires!
:-))... So I would really appreciate somebody telling me what I'm missing in
the whole issue...

> Now TCP can NOT do this since it only has one address bound. Where
> the packet is emitted which has nothing to do with the source address
> selected...since this is set as part of the connection.
> 
> Now another issue with this that people keep forgetting is that
> in general the source address of the packet DOES NOT HELP the
> IP stack choose the interface the packet will be emitted on.
> Yes, you can in some instances turn on source based routing
> but this IS STILL A REASEARCH issue and is not generally done.

	Exactly, this is my concern... As you can't select the physical card
used, you can't control the path, and so those problems arise... In the most
common case you will be sending all your datagrams from a single NIC, unless
the destination addresses lead to the use of different gateways, reachable
through different NICs (which is what usually happens in the bake-offs)...

> So we launch packets out an interface paying NO attention to
> the source address. The source address is ONLY used by
> the remote endpoint to:
> 
> 1) Help find the association
> 2) Know the prefered return address to use. An endpoint
>    MAY NOT use this in SOME cases as documented in RFC2960
> 
> Now it is true that the routing infrastructure of the
> local host controls a lot of issues... 
> 
> If I am using a single default route (a somewhat bad idea
> if I am really concerned about redundancy) then I will
> get very little benefit from my multi-homing. But has
> Andreas as pointed out, if you are going to the extra
> effort of putting in two ISP connections and wanting
> to communicate across the network to a peer that
> is likewise setup, one would expect you to apply a bit
> of "engineering sense" and setup routing table entries
> to this peer that lead out the appropriate paths and
> NOT use the "default route".

	But that's the point, this is outside the scope of SCTP... You must
know the topology of the network and then decide that it is better use this
or that other gateway to route datagrams to a specific address... and then
change the routing tables... Is there any other way of doing this? How can
you choose the right gateway (and so the NIC used) if not because you know
"how the wires are connected"? I think I'm getting lost somewhere... :-(

> One could even image a system that allows two default
> routes. FreeBSD currently does not support this .. I
> will have to check and see if KAME's modifications do...
> With two default routes one could even build some intelegence
> into route selection to get the second default route for
> an SCTP endpoint... hmmm I need to go have a look at this
> and see if I can't put it in my work.... IF KAME has
> expanded the ability to have multiple default routes :>
> In linux I think this is possible and one could invision
> setting up routing entries in SCTP so that two destinations
> DON'T share the same default route outwards... this of
> course is an implementation issue that I think I will look
> into for KAME...

	... snip...

	I sincerely hope that somebody can help me to understand why I am
wrong... :-/

	Thanks!

	BR Iván Arias Rodríguez

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

---

From: Randall Stewart <[email-masked]>
Date: Wed, 12 Sep 2001 15:29:25 -0500

> everything and that might be the reason why you can control the card used

Ahh, you use that monitor (note not an O/S) called windows.. that
explains
it... I did hear that the win world may be getting a part of a BSD
stack in XP or something... rumor at least.. if this is true you
will have the ability to write the IP header completely...

My statements were for real O/S's :>

As far as that goes, I do believe there are hackers out there
who have did address spoofing with windows ... aka all those
SYN attacks of years ago.. so I am sure it is possible even
in the Windoz monitor to do this :->

> card used)... I don't have problems with IP source address selection...

ahh.. you did not specify.. Ethernet address.. this explains a
lot.. I will have to go back and re-read your email with this
in mind. I don't really see how the E-Net address matters.. It never
is seen outside of the link you are on... So why would anyone want
to use a different e-net address...

> something that makes compulsory the use of a certain NIC...)

No, the routing tables will choose the NIC to emit the packet on 
based on the destination address only... (in most cases)

> but not through the rest...

Why in the world would you ever want to choose a NIC address?? I don't
get it...

> :-))... So I would really appreciate somebody telling me what I'm missing in

This discussion I think was on source IP address... at least that
is what I have been discussing :>

> through different NICs (which is what usually happens in the bake-offs)...

This is a routing table configuration issue. Just like in the bake-offs
if you want to use the redundancy you must make sure your routing
tables are configured... If you just put in a default it will
go at that one address...

>         I sincerely hope that somebody can help me to understand why I am

Hmm. I don't think I have helped you but it is all food for thought :-)

R
-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)