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

From: [email-masked]
Date: Fri, 22 Feb 2002 12:53:50 +0200

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
> 

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Feb 2002 06:14:40 -0600

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

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 22 Feb 2002 08:07:29 -0600

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:

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