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

Text archives Help


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


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


I could not agree more with yor response :>


one comments.. below..

Ivan.Arias-Rodriguez AT nokia.com
wrote:
>
> 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...
>

Or you can respond to the address that sent it to you.. in any case
you have a LIST of valid addresses at the point of sending
the cookie-echo ...

Note this IS legal and really any GOOD implementation will
do it. We probably should add this to the implementation guide
as a SHOULD and let the poor implementations that don't do
this just suffer the consequences of there bad implementation.. i.e.
the won't always be able to build associations.

R




>
> > --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 ¦
> >
>
> _______________________________________________
> 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)


Archive powered by MHonArc 2.6.19+.

Top of page