Chronological Thread 

< Chronological >      < Thread >

---

\
I hope it is.. La Monte and I talked about this
case MANY times :>

R

"Guo, Xingang" wrote:
>
> Randall,
>
> As far as I know, this is exactly what lksctp does.
>
> www.sourceforge.net/projects/lksctp
>
> --Xingang
>
> > -----Original Message-----
> > From: Randall Stewart
> > [mailto:randall AT stewart.chicago.il.us]
> > Sent: Thursday, February 21, 2002 7:21 AM
> > To: Tuexen Michael
> > Cc:
> > 'bidulock AT openss7.org';
> >
> > 'tsvwg AT ietf.org';
> >
> > 'discussion AT sctp.de'
> > Subject: Re: [Tsvwg] RE: [SCTP-Discussion] Multihoming
> >
> >
> > Michael:
> >
> > From digging through this thread is this the scenario:
> >
> >
> > Endpoint 1 Endpoint 2
> > IP-A IP-C
> > IP-B IP-D
> > ------------Frm:IP-A:INIT(List-IP-A)--------->To:IP-C
> > <---------------To:IP-A---Frm:IP-D:INIT-ACK(List-IP-C,IP-D)----
> >
> > Now the above case IS legal and there is specific wording in
> > the RFC that covers this. The idea is that Endpoint-1 MUST
> > lookup not only the FROM address in the IP header but also
> > MUST lookup in the list of addresses (IP-C/IP-D in this case)
> > if it can't find its TCB.
> >
> > R
> >
> > Tuexen Michael wrote:
> > >
> > > 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 ¦
> > >
> > > _______________________________________________
> > > tsvwg mailing list
> > > tsvwg AT ietf.org
> > > https://www1.ietf.org/mailman/listinfo/tsvwg
> >
> > --
> > Randall R. Stewart
> > randall AT stewart.chicago.il.us
> > 815-342-5222 (cell phone)
> >
> > _______________________________________________
> > tsvwg mailing list
> > tsvwg AT ietf.org
> > https://www1.ietf.org/mailman/listinfo/tsvwg
> >

--
Randall R. Stewart
randall AT stewart.chicago.il.us
815-342-5222 (cell phone)

---

• RE: [Tsvwg] RE: [SCTP-Discussion] Multihoming, Tuexen Michael, 02/21/2002
  • <Possible follow-up(s)>
  • RE: [Tsvwg] RE: [SCTP-Discussion] Multihoming, Guo, Xingang, 02/21/2002
    • Re: [Tsvwg] RE: [SCTP-Discussion] Multihoming, Randall Stewart, 02/21/2002
  • RE: [Tsvwg] RE: [SCTP-Discussion] Multihoming, Ivan.Arias-Rodriguez, 02/22/2002
    • Re: [Tsvwg] RE: [SCTP-Discussion] Multihoming, Randall Stewart, 02/22/2002
      • Re: [Tsvwg] RE: [SCTP-Discussion] Multihoming, Brian F. G. Bidulock, 02/22/2002
  • RE: [Tsvwg] RE: [SCTP-Discussion] Multihoming, Ivan.Arias-Rodriguez, 02/22/2002
    • Re: [Tsvwg] RE: [SCTP-Discussion] Multihoming, Randall Stewart, 02/22/2002

---

Archive powered by MHonArc 2.6.19+.