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

Text archives Help


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


Chronological Thread 
  • From: <Ivan.Arias-Rodriguez AT nokia.com>
  • To: <bidulock AT openss7.org>, <randall AT stewart.chicago.il.us>
  • Cc: <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 17:37:34 2002
  • List-id: SCTP Discussions <discussion.sctp.de>
Hi all!

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

I think we have been all the time speaking about if it is legal or
not sending the INIT ACK from a different source address than the destination
address of the INIT...

Which other situation do you speak about? :-/

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

Yes, that's true. This is to check that the source address in the
INIT is the real one. Basically the whole cookie mechanism has been designed
to be able to make this check before reserving any resource...

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

Exactly, this is what we are speaking about.

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

I don't think so... When you receive the INIT ACK you already know
the addresses of your peer... Why limiting then?

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

Well... really there isn't any need at all... but... if you can
manage... Maybe the INIT ACK sender is clumsy and cannot really specify its
source address (but it is using all of them in any case)...

How was that sentence? "be careful about what you send, but accept as
much as you can...", something like that...

> If you want to permit the behavior that the sender of
> the INIT-ACK can use any old source address in the list,

Old source? They are not old? They are in use, and they will be used
in the association... Why old? If you are not using an address any more
definitely you shouldn't include it at all nor use it as your source address
(in fact, if it is old, it is because you don't use it any more... :-))

> there would be a conflict with the RFC restriction that
> the INIT-ACK "MUST" be sent to the sender (source address)
> of the INIT.

No, they are two different things. The destination is compulsorily
that of the source of the INIT chunk. But the source can be whichever
(whichever you use, of course).

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

How? Sending the COOKIE ECHO chunk you are proving that you received
the INIT ACK chunk, i.e. that you are who you are stating you are... What is
the difference if it comes from one or another address?

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

To any of the valid addresses of the association...

Thanks!

BR Iván Arias Rodríguez

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