Subject: RE: [Tsvwg] sctp

From: "Amit Goel" <[email-masked]>
Date: Wed, 21 Jun 2006 01:44:57 -0700

Hi Brian,

> Some implementations cannot control the source address 
> of sent packets, they are automatically addressed with 
> a source address belonging to the outgoing interface.  

If an SCTP implementation uses raw sockets and also populates the source
address in the IP Header itself, for HB-ACK / SACK messages does it need
to care about filling correct source address (interface on which data
packet arrived) , or can SCTP also be careless about it since there is
no response expected for an ACK.

Thanks,
Amit.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 21 Jun 2006 05:13:43 -0600

Amit,

Amit Goel wrote:                           (Wed, 21 Jun 2006 01:44:57)
> no response expected for an ACK.

In general the source IP address can be any IP address belonging to the
association at the sending endpoint.  The exception is, of course, the
INIT-ACK chunk whose source IP address must be the destination IP
address to which the INIT was sent, and the recommendations in RFC 4460
Section 2.39.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 21 Jun 2006 23:21:35 +0200

Dear all,

see comments in-line.

Best regards
Michael

> address to which the INIT was sent, and the recommendations in RFC  
Not sure what you are referring to. If the INIT-ACK is not using the  
destination
address of the INIT as the source address, the destination address of  
the INIT
MUST be listed inside the INIT-ACK. This is at the SCTP layer OK.
However the address selection has some implications at the IP layer.  
I comment
on that in the answer to Amits next message.

---

From: Randall Stewart <[email-masked]>
Date: Thu, 22 Jun 2006 11:52:25 -0400

> address to which the INIT was sent, and the recommendations in RFC 4460

There is no mandate that says an INIT-ACK must be
sent from the soruce IP address of where the INIT was sent to..

Any valid address in the INIT-ACK may be a source address for
it.. of course it (the INIT-ACK) MUST at least list,
in its IP address list, the IP address to which the INIT was sent...
To assure that the sender of the INIT can locate the TCB....

This is for the very reason you stated earlier.. not always
can the sender control the source address of a packet...

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 22 Jun 2006 16:31:07 -0700

Would it be fair to state that generally a host should not transmit a  
packet with a source
IP address when there is no reason to believe that a packet with that  
destination address
would not come back to it?

The obvious exception is asymmetric routes, but those are created for  
very specific
reasons that the host should be aware of.

For a typical SCTP multi-homed host that is connected via two  
different networks
and two different NICs, I would venture that it is unwise to use your  
Network A
address on Network B unless Network B thinks that you are authorized  
to act
as a router between Network A and Network B.

In the very common case that Network A and Network B represent two  
different
ISPs I would guess that neither Network A or Network B  wants what  
they perceive
to be an end-node to start routing between the two networks. In fact  
it might even
violate your terms of service agreement.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 22 Jun 2006 17:41:51 -0600

Caitlin,

Caitlin Bestler wrote:                         (Thu, 22 Jun 2006 16:31:07)
> different networks and two different NICs, I would venture that it is
> unwise to use your  Network A address on Network B unless Network B
> thinks that you are authorized  to act as a router between Network A
> and Network B.

If by "different networks" you mean different subnetworks, yes.
If they are interfaces on the same subnetwork (e.g. same Class A
subnetwork) then no.

> different ISPs I would guess that neither Network A or Network B
> wants what  they perceive to be an end-node to start routing between
> the two networks. In fact  it might even violate your terms of service
> agreement.

Again, only if the ISPs are on two different subnetworks (not a
necessary condition, particularly in the case of resale).

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Mark Butler <[email-masked]>
Date: Fri, 23 Jun 2006 03:39:35 -0600

> would not come back to it?

Yes. e.g. the Linux network layer generally picks the primary IP address
of the outgoing interface / subnet as the source address unless you tell
it to do something different.

If contrary to popular prejudice you are trying to make your SCTP
implementation properly redundant using source address routing at the
end node, then the source address should map to the interface in the
same way, except the SCTP implementation has to specify which source
address to use, instead of letting the network layer select it from the
routing table by destination address alone  with the corresponding
interface address substituted in, as is the standard practice.

So for example on Linux if you want to do this, you have to customize
the SCTP implementation to failover based on (source / destination
address) combination and then configure the routing table for source
routing, such that when the source address is changed, the packet is
sent out the proper interface, instead typically following the default
route to the primary ISP.  I investigated this, and it is kind of a
mess, because the stack has a hard time anticipating various bizarre
routing configurations.

Of course you can also do the same thing without source routing by
setting up the proper static routes for each peer, at least two routes
per peer, unless the IP address blocks happen to be properly aligned for
a set of them.

In my opinion the proper way to fix the problem is to change the network
layer internally so that it properly handles multipath routes.  Then the
SCTP implementation queries layer 3 and asks, what source addresses are
valid for this destination, and caches them for future use, failing over
by (source,dest) address pair, instead of dest address alone.

> as a router between Network A and Network B.

I agree. It causes strange problems as well, because most responses end
up being sent through a radically asymmetrical path, and failure
detection doesn't work properly.

> violate your terms of service agreement.

A good ISP should have source address based ingress filtering unless you
arrange with them otherwise.  The reason is to prevent IP address
forging.  One cannot effectively route between two ISPs unless one of
them configures their routing tables to forward traffic for the other
ISP through you, which generally only happens by mistake.  If you are a
BGP customer they should be filtering your advertisements, of course if
they botch their routing configuration you are at their mercy.

- Mark B.

---

From: Mark Butler <[email-masked]>
Date: Fri, 23 Jun 2006 03:08:37 -0600

- Mark B.

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Jun 2006 07:36:55 -0700

> it to do something different.

That's an 1122-ism of TCP that presumably SCTP also follows.

...
> by (source,dest) address pair, instead of dest address alone.

This is a consequence of implementing a routing protocol in the
transport layer, i.e., SCTP is in the position to make the decision, but
didn't. It's not enough to have SCTP ask L3 for all possible routes that
L3 supports; SCTP has to pick the right one as well.

>> reasons that the host should be aware of.

A consequence of having two competing routing protocols (host and SCTP)
is that they need to coordinate more closely - especially in atypical
cases.

I'm not saying any of this is impossible, but it seems like the level of
complexity is higher than it might appear.

Joe