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

From: [email-masked]
Date: Fri, 22 Feb 2002 16:21:30 +0200

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
> > 
> > [email-masked] 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:[email-masked]]
> > > > Sent: 22. February 2002 5:39
> > > > To: Randall Stewart
> > > > Cc: Tuexen Michael; [email-masked]'; [email-masked]'
> > > > 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 ¦
> > > > [email-masked]    ¦ 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
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/tsvwg
> > > >
> > 
> > -- 
> > Randall R. Stewart
> > [email-masked] 815-342-5222 (cell phone)
> 
> -- 
> Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
> [email-masked]    ¦ 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Feb 2002 08:59:56 -0600

Ivan:

I could not agree more with yor response :>

one comments.. below..

>         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