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

Text archives Help


Re: [Tsvwg] RE: [SCTP-Discussion] Multihoming


Chronological Thread 
  • From: "Brian F. G. Bidulock" <bidulock AT openss7.org>
  • To: Randall Stewart <randall AT stewart.chicago.il.us>
  • Cc: Ivan.Arias-Rodriguez AT nokia.com, Michael.Tuexen AT icn.siemens.de, tsvwg AT ietf.org, discussion AT sctp.de
  • Subject: Re: [Tsvwg] RE: [SCTP-Discussion] Multihoming
  • Date: Fri Feb 22 15:12:01 2002
  • Dsn-notification-to: <bidulock AT openss7.org>
  • List-id: SCTP Discussions <discussion.sctp.de>
  • Organization: http://www.openss7.org/
Randall,

This is a different situation altogether that you are
talking about. What you describe is of course already
handled in most implementations I believe.

The RFC says the INIT ACK MUST be sent to the source
address of the INIT.

We are questioning whether it is required to send the
INIT ACK *from* the destination address of the INIT,
or whether it is permitted to send them from any
element in the list.

IMO the INIT process (INIT INIT-ACK exchange) is
restricted to pair of transport endpoints (the one
sending the INIT and the one replying with an INIT-ACK).

There is absolutely no need to inject other IP addresses
into the IP header (source or destination address). Multi-
homed addresses from which the INIT or INIT-ACK are sent
should appear at most in the address list in the chunk.

If you want to permit the behavior that the sender of
the INIT-ACK can use any old source address in the list,
there would be a conflict with the RFC restriction that
the INIT-ACK "MUST" be sent to the sender (source address)
of the INIT.

However, we discussed this before and it was the questioned
whether opening up the INIT/INIT-ACK exchange to the entire
address lists would not somehow weaken the secuity of the
INIT process.

If the INIT-ACK can come from any source address in the
list, where is the COOKIE-ECHO then sent?

--brian

On Fri, 22 Feb 2002, Randall Stewart wrote:

> Ivan:
>
> Well you hit the nail on the head as ususal... without
> doing this setup between multi-homed hosts does not
> work very well... consider
>
> Host-A Host-Z
> IP-1 IP-5
> IP-2 IP-6
>
> ---INIT(IP-1,IP-2)---\ /--INIT(IP-5,IP-6)---
> X
> toIP-1<-frm-IP-5-----/\------frm-IP-2------>toIP-6
>
> Now unless inspection is done of the INIT/INIT-ACK the
> two will NOT realize they are both setting up a association
> at the same time.
>
> Another consideration is Address filtering. Often times
> a host MUST use the IP address of the interface that you
> are sending from.. or get the packet filtered so in the above
>
> ----Frm-IP-1:INIT(IP-1,IP-2)------to(IP-5)----------->
> (route to IP-1 points out
> intf
> of IP6.. note this may
> be
> from either only one
> allowed
> default route.. or some
> other
> reason).
> <----------to(IP-1)--INIT-ACK(IP-5,IP-6)--------From-IP-6
>
> And we have the same secenario..
>
> As far as looking for this text in the RFC .. sadly the full text
> was chopped in one of the IESG passes (due to my lack of communication
> skills as to why it is there)... and now all that is left is the
> trival little statement of:
>
> "
> 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.
> "
>
> I think we will need to add a few lines to the implementors guide...
> Also
> there is NOTHING in the spec that makes this illegal as you point out.
> I remember we discussed this amongst the many emails and I addressed
> just
> these points.
>
> Well more grist for the implementors guide :>
>
> R
>
> Ivan.Arias-Rodriguez AT nokia.com
> wrote:
> >
> > Hi all!
> >
> > I also consider that situation to be legal. When I receive an INIT
> > ACK I always look inside the parameters to see if it belongs to
> > any open association (or in the COOKIE WAIT state). Moreover, I
> > also do it with INIT chunks, to realize about establishment
> > collisions or restart...
> >
> > If you don't allow this, I think it would be quite hard to detect
> > INIT collisions in multihomed hosts... :-/
> >
> > I must admit that I forgot about this possibility until after
> > having tested my implementation in a "brakeoff". But, could you
> > Brian point to the section of the RFC that forbids this
> > possibility? In my understanding it is a logical thing to do...
> >
> > Thanks!
> >
> > BR Iván Arias Rodríguez
> >
> > > -----Original Message-----
> > > From: ext Brian F. G. Bidulock
> > > [mailto:bidulock AT openss7.org]
> > > Sent: 22. February 2002 5:39
> > > To: Randall Stewart
> > > Cc: Tuexen Michael;
> > > 'tsvwg AT ietf.org';
> > >
> > > 'discussion AT sctp.de'
> > > Subject: Re: [Tsvwg] RE: [SCTP-Discussion] Multihoming
> > >
> > >
> > > Randall,
> > >
> > > On Thu, 21 Feb 2002, Randall Stewart wrote:
> > >
> > > > Now the above case IS legal and there is specific wording in
> > > > the RFC that covers this.
> > >
> > > Could you point to the section of the RFC that requires
> > > that this scenario be permitted?
> > >
> > > --brian
> > >
> > >
> > >
> > > --
> > > 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)

--
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