First login?
Lost password?
 
 
sctp-discussion AT lists.franken.de 
SCTP Discussions

Text archives Help


RE: [SCTP-Discussion] Multihoming


Chronological Thread 
  • From: Tuexen Michael <Michael.Tuexen AT icn.siemens.de>
  • To: "'bidulock AT openss7.org'" <bidulock AT openss7.org>
  • Cc: "'tsvwg AT ietf.org'" <tsvwg AT ietf.org>, "'discussion AT sctp.de'" <discussion AT sctp.de>
  • Subject: RE: [SCTP-Discussion] Multihoming
  • Date: Thu Feb 21 14:27:02 2002
  • List-id: SCTP Discussions <discussion.sctp.de>
Brian,

I know this. But I do not see why accepting the INIT-ACK
coming from an unknown address, but the known one is
in the list of addresses, is a serious problem, at least
from the security point of view.
As I mentioned, the assoc will not gain the expected
network fault tolerance as it could be expected by only
looking at the number of paths, but does that satisfy
the non establishment of the assoc. It is sure that
the network is not configured as it should, but ...

Best regards
Michael


Michael Tuexen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN WN CS SE 5 E-mail:
Michael.Tuexen AT icn.siemens.de

> -----Original Message-----
> From: Brian F. G. Bidulock
> [SMTP:bidulock AT openss7.org]
> Sent: Thursday, February 21, 2002 2:05 PM
> To: Tuexen Michael
> Cc:
> 'discussion AT sctp.de'
> Subject: Re: [SCTP-Discussion] Multihoming
>
> Michael,
>
> Not even TCP will accept such an arrangement. Say TCP launches
> a SYN from B to A_1. If A responds with a SYN from A_2 to B the
> connection will not succeed.
>
> --brian
>
> On Thu, 21 Feb 2002, Tuexen Michael wrote:
>
> > Dear Roland,
> >
> > considering the case where the SCTP end point A only announces
> > A2, but A1 is used as a source IP address is definitly a
> > misconfiguration of the host!
> > If a SCTP end point only announces a proper subset of its IP-addresses
> > it must make sure that only addresses of this subset are used as
> > source IP addresses. The most simple way to make this sure is to
> > include all addresses. This is the reason why you can read the
> > Implemention note in RFC 2960. The sctplib also supports using this
> > subset but then your forwaring on the host must be in tune with this
> > configuration as stated in the documentation.
> >
> > Considering the other case: B sends traffic from B1 to A2. A replies
> > then from A1 to B1. This also means that your forwaring setup is
> > not in a proper way configured so that you can really make use of the
> > multihoming support of SCTP. The problems are described in
> > http://www.ietf.org/internet-drafts/draft-coene-sctp-multihome-03.txt
> > Nevertheless, when an SCTP endpoint receives an INIT-ACK it should
> > check if it can find a TCB based on the source IP address and the
> > IP addresses listed in the INIT-ACK. This seems not to be implemented
> > in pre17 and will be added in a future release. This would result
> > in being able to establish the association, but you do not have the
> > redundancy you think based on the number of paths.
> >
> > Best regards
> > Michael
> >
> >
> > Michael Tuexen Tel.: +49 89 722 47210
> > Siemens AG Fax: +49 89 722 48212
> > ICN WN CS SE 5 E-mail:
> > Michael.Tuexen AT icn.siemens.de
> >
> > > -----Original Message-----
> > > From: Roland Gloeckler
> > > [SMTP:gloeckle AT ind.uni-stuttgart.de]
> > > Sent: Thursday, February 21, 2002 1:13 PM
> > > To:
> > > bidulock AT openss7.org
> > > Cc:
> > > discussion AT sctp.de
> > > Subject: Re: [SCTP-Discussion] Multihoming
> > >
> > > Dear Mr. Bidulock, dear all:
> > >
> > > My question is not completely answered by your response.
> > >
> > > My problem (a little bit more detailed) is the following:
> > >
> > > A has two interfaces with distinct IP addresses (A_1 and A_2).
> > > B sends an INIT to one of them, e.g., A_2. The other interface A_1 is
> > > not
> > > known to B yet.
> > >
> > > In the sctp implementation A sends the INIT_ACK via the interface which
> > > is
> > > the default entry in the IP routing table, e.g., A_1.
> > >
> > > Now there are two error scenarios:
> > >
> > > A has initialised a multihomed instance with both IP addresses.
> > > For sending the INIT ACK it uses A_1 which is not known to B before it
> > > reads
> > > the address list (with A_1 and A_2) in this INIT ACK chunk.
> > > B responds with an ABORT.
> > >
> > > or
> > >
> > > A has initialised a singlehomed instance with the address A_2, which
> > > receives >
> > > the INIT.
> > > For sending the INIT ACK it uses A_1 which is not even initialised in
> > > the
> > > SCTP instance. In the cookie it uses A_2.
> > > So it is obvious that SCTP has no control over the IP source address.
> > > An association cannot be initialized.
> > >
> > > To resume:
> > >
> > > If the INIT_ACK chunk of an instance A uses in its IP header a source
> > > IP
> > > address that is different from the destination address of the INIT
> > > chunk from
> > > B, B refuses to accept it.
> > >
> > >
> > > Section 5.1.2.c of the RFC says:
> > >
> > > "IMPLEMENTATION NOTE: In some cases (e.g., when the implementation
> > > doesn't
> > > control the source IP address that is used for transmitting), an
> > > endpoint
> > > might need to include in its INIT or INIT ACK all possible IP addresses
> > > from
> > > which packets to the peer could be transmitted."
> > >
> > > B would have to read the list of IP addresses in the INIT ACK before it
> > > searches in its association list to know the chunk belongs to A.
> > >
> > > Or should the implementation force its IP layer to use the INIT
> > > destination
> > > address as the source address for the INIT ACK? The RFC tries to cover
> > > cases
> > > where this is not the case.
> > >
> > > Regards,
> > >
> > > Roland
> > >
> > >
> > >
> > > On Friday 01 February 2002 20:38, Brian F. G. Bidulock wrote:
> > > > Roland,
> > > >
> > > > The effect your describe was discussed on TSVWG. The
> > > > defficiency of SCTP was characterized as RFC2960's inability>
> > > > to provide for reliable initialization of an association.
> > > >
> > > > The effect you describe is required by RFC 2960 section 5.1
> > > > paragraph (B): "... The destination IP address of the INIT ACK
> > > > MUST be set to the source IP address of the INIT to which this
> > > > INIT ACK is responding."
> > > >
> > > > The behavior exhibited by SCTPlib is correct. The
> > > > implementation should reply with an ABORT in response to the
> > > > INIT ACK sent to the wrong address.
> > > >
> > > > --brian
> > > >
> > > > On Fri, 01 Feb 2002, Roland Gloeckler wrote:
> > > > > Dear all,
> > > > >
> > > > > when I was working with SCTPlib 1 pre14 I found an
> > > > > interesting behaviour.
> > > > >
> > > > > I had one PC (let's call it "A") with two network cards
> > > > > (let's call them A_1 and A_2) connected to another one
> > > > > (let's call it "B") with only one (B_1).
> > > > >
> > > > > The configuration was: Interfaces A_1 and B_1 were connected
> > > > > to the same LAN and A_2 was connected to the LAN via a
> > > > > router.
> > > > >
> > > > > After some minor changes to testengine.c I was able to use
> > > > > test_tool to initialise an SCTP multihoming instance on A
> > > > > for the addresses A_1 and A_2.
> > > > >
> > > > > In the script for B I tried to start an association with A,
> > > > > but only included one IP address, e.g., A_2.
> > > > >
> > > > > B successfully sent an INIT message to A_2, which responded
> > > > > with a valid INIT_ACK.
> > > > >
> > > > > If A responded via A_2 all went well.
> > > > >
> > > > > BUT: When A used the other interface A_1 to send the
> > > > > INIT_ACK (which included the list of its own addresses A_1
> > > > > and A_2 belonging to that instance) to B, B was not able to
> > > > > find the address A_1 in its association list, since it
> > > > > didn't know it yet, and answered with an ABORT message to A.
> > > > >
> > > > > If I change the destination address in B's script to A_1 and
> > > > > change the routing table in A to send packets to B via A_2
> > > > > the result is the same.
> > > > >
> > > > > To summarize:
> > > > >
> > > > > If the INIT_ACK chunk of a multihomed instance A uses a
> > > > > source IP address that is different from the one B sent the
> > > > > INIT chunk to, B refuses to accept it.
> > > > >
> > > > > When I was looking into the RFC to search for more details,
> > > > > I only found out that the behaviour is according to the>
> > > > > rules that no INIT_ACK is to be accepted which uses an
> > > > > unknown source transport address.
> > > > >
> > > > > Now I wonder if this is a general problem not answered by
> > > > > the RFC.
> > > > >
> > > > > I can think of several ways to come around the problem for
> > > > > my purposes, but they are not adequate for general purposes.
> > > > >
> > > > > Has anyone heard of this situation before? Please tell me.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Roland
> > > > > _______________________________________________
> > > > > discussion mailing list
> > > > > discussion AT sctp.de
> > > > > http://www.sctp.de/mailman/listinfo/discussion
> > > _______________________________________________
> > > discussion mailing list
> > > discussion AT sctp.de
> > > http://www.sctp.de/mailman/listinfo/discussion
>
> --
> Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
> bidulock AT openss7.org
> ¦ world; the unreasonable one persists in ¦
> http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
> ¦ Therefore all progress depends on the ¦
> ¦ unreasonable man. -- George Bernard Shaw ¦


Archive powered by MHonArc 2.6.19+.

Top of page