Subject: [Tsvwg] Questions about the AddIP extension

From: [email-masked]
Date: Fri, 22 Feb 2002 19:01:28 +0200

Hi all!

	Some questions...

	What happens if the peer tells us to set as primary one address that is not part of the association? There isn't any error cause to state this, so, either you report a success (which is not the case, but...), or you send an error cause (which one?)...

	The same applies to the deletion of one address... But in this case the situation is somehow worse... :-/

	Moreover... I'm thinking now about something... uhm... Not sure if it would be a problem at all. :-0

	Imagine that we (the server) send the INIT ACK including the same Initiate Tag as the INIT sender (client). Then, using AddIP we (the server) do so that we erase our address and include one of the addresses of the client... If we haven't acknowledged anything yet, the client would be sending DATA chunks to itself and acknowledging them... It would receive its own DATA and SACK chunks, believing that is the server the one that is sending them... Until the client ends sending data to itself it won't stop the association...

	As the server is the one doing this "attack" I don't see the point of doing it, but... Basically, what I was thinking about is what should be done if the peer tries to add one of "our addresses" as if it was one of its addresses... Again, if we report an error, which one?

	Wouldn't it be nice to have an error cause saying something like "invalid IP address to perform the operation"? It could be used for all these "strange" situations... and maybe some more I can not think about now...

	By the way the "Error Cause Indication" parameter can be used to "Return Info on Success", how? Is this a mistake or not?

	Thanks!

	BR Iván Arias Rodríguez

> -----Original Message-----
> From: ext Randall Stewart [mailto:[email-masked]]
> Sent: 22. February 2002 17:00
> To: Arias-Rodriguez Ivan (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]
> Subject: Re: [Tsvwg] RE: [SCTP-Discussion] Multihoming
> 
> 
> Ivan:
> 
> 
> I could not agree more with yor response :>
> 
> 
> one comments.. below..
> 
> [email-masked] 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
> > > >
> > > > [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
> 
> -- 
> Randall R. Stewart
> [email-masked] 815-342-5222 (cell phone)
> 

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

---

From: Peter Lei <[email-masked]>
Date: Fri, 22 Feb 2002 12:15:09 -0600

Ivan,

comments inline:

>         What happens if the peer tells us to set as primary one address that is not part of the association? There isn't any error cause to state this, so, either you report a success (which is not…

The SET_PRIMARY_IP_ADDRESS asconf is just a request for the receiver to mark
the address as primary... a receiver MAY choose to honor the request or not.
Our implementation currently sends back an "Unresolvable Address" (code 5)
error cause indication if it doesn't recognize the address given; it was the
closest to "Invalid Address"...

>         The same applies to the deletion of one address... But in this case the situation is somehow worse... :-/

Hmm... here our implementation currently simply sends a "success" ack, since the
peer is deleting the (deleted) address anyways; otherwise, if we send an error
back, an implementation might consider it still valid (since the delete failed)
and continue to use it and then eventually mark that address unreachable.  Yes,
in any case, it does indicate that something had gone wrong already...

>         By the way the "Error Cause Indication" parameter can be used to "Return Info on Success", how? Is this a mistake or not?

I hope that it is a mistake... :)

---

From: Randall Stewart <[email-masked]>
Date: Fri, 22 Feb 2002 13:45:23 -0600

>         What happens if the peer tells us to set as primary one address that is not part of the association? There isn't any error cause to state this, so, either you report a success (which is not…

For this one we never put in an error since it is completely optional
by the receiver of the set-primary to honor the request... its a
suggestion.
I do not think it is worth responding either way...

>         Moreover... I'm thinking now about something... uhm... Not sure if it would be a problem at all. :-0

The peer deleteing a non existant address is probably an indication
of an internal error of your peer.. not that it harms anything... if
I tell you sure you can delete an address that is NOT part of
the association.. does it harm anything (anymore than whatever
messed up state you are already in)?

>         By the way the "Error Cause Indication" parameter can be used to "Return Info on Success", how? Is this a mistake or not?

Seems to me you more illustrate an attack here. No peer that server or
client
would do this unless they either were:

a) -malicious
or
b) -messed up internally..

In either case at that point we should probably just abort the
association.
We may want to go examine our BSD code and think about doing this :>

R