Subject: Re: [Tsvwg] Comments about draft-ietf-sigtran-addip-sctp-01.txt

From: "Randall R. Stewart" <[email-masked]>
Date: Wed, 14 Mar 2001 11:08:16 -0600

[email-masked] wrote:
> 
>         Hi all!
> 
>         I have some comments (should I say several thousands ;-)) about this
> draft, especially about section 4.1... Anyway, let's start from the
> beginning:
> 
>         - Section 3.2: What about checking if the IP address requested to be
> added is one of our source address? If this is made by an attacker, and he
> manages to make us send anything to ourselves, the tags won't match and we
> will discard it, unless it is a SHUTDOWN COMPLETE with the T bit set to 1,
> or an ABORT (by the way, to accept an ABORT with our tag instead of the
> peer's one, should its T bit be set to 1 as well? RFC 2960, section 8.5.1,
> B), third paragraph, doesn't say so...), and in those cases it really
> doesn't matter. The server can easily choose the same Verification Tag as
> the client, but I haven't found any easy way to do the opposite... I guess
> that we shouldn't bother about a server being able to make life harder to
> the clients (even if real life is full of them ;-)). Maybe we don't need to
> add any new error cause, but I think that it could be nice to check this
> before accepting the request...
> 
I don't think a server should pick the same tag has the client. This is
a VERY VERY bad practice that WILL lead to trouble in restart cases.
And yes, the ABORT T bit should be set before you allow a tag that
is your peers.

As far as the attacker adding your own IP address, Yes we can add
some language to ABORT the association if an attacker does this...but
if you think about it.. it is not really an attacker but one of
your clients. There is a difference after all .. an attacker is
someone you have no relationship wish. In this case you DO have a
valid association... so you do have some relationship with the peer.

I will put this down has a MUST NOT.. but I think the only one 
it will harm is the "attacker" since it will disrupt communication
between it and its server... it does not really hurt other associations.

>         About section 4.1, I have quite a lot comments... I decided that the
> best thing was commenting them, but also, in the hypothetical case you
> happen to accept the changes that I would like to propose (which are
> actually quite many), I have modified the section following the next
> comments, and I send the modified section 4.1 as an attachment to this
> mail... maybe it would make your life easier... The comments are:

I will look at and think on your proposed changes...

> 
>         - Section 4, first paragraph: The whole section also manages the Set
> Primary Address REL-REQ parameter, so I guess it shouldn't be omitted in the
> introduction of the section. Maybe it would be better something like:
> 
>    "This section will lay out the specific procedures for the Add/Delete
>     IP Address, and Set Primary Address REL-REQ Parameters. The generic
>     procedures for transmitting reliable SCTP control chunks are covered in
>     [RELREQ]."
> 

Yes, I missed this when I added the set primary.. I will make the change
but
I think this will be re-worked if we get rid of the REL-REQ draft (which
I think the authors all feel we should).

>         - Section 4.1, D1): I think it would be helpful to already state
> here that the address that is about to be add is already valid for the
> association to receive data from, since the very moment we send the REL-REQ.
> Reading D1 and D2 can make you believe that the added IP address can only be
> used as a source address (weird, but nothing is stated against this), at
> least until you read later about the first example of DATA chunks out of
> order. Maybe the example given at the end of the section could be included
> here...

How about adding this sentence to the end of D1)
"
The receiver of the add IP address request may use the address has a
destination immediately. 
"
> 
>         - Section 4.1, D3): The section 4.1 is about adding/deleting IP
> address. But D3) is also related with the Set Primary IP Address REL-REQ
> parameter. I guess that it would be better including this paragraph before
> section 4.1, maybe at the beginning of section 4, or as a note at the end of
> the section...

Maybe a change of the title of 4.1 might be better say:

4.1 "General rules"
and
4.2 "Specific considerations for setting of the primary address"

I think this is better because I feel the rule belongs where it is...

>         - Section 4.1, D4): "... the IP address MUST be considered a valid
> source address for DATA chunks until...". I guess there is a mistake here.
> Wouldn't it be something like "... the IP address MUST be considered valid
> for the association to receive SCTP packets from until...". I think that it
> should be destination and not source (as is later on explained)... anyway
> the few common sense I still have tells me that the idea is that it can
> still RECEIVE any chunk, and not SEND them... And also not only DATA ones
> but any SCTP datagram...
> 

I see your point.. it is supposed to be for all chunks... how about:

" 
    D4) When deleting an IP address from an association, the IP address
        MUST be considered a valid destination address for the reception
        of SCTP packets until the REL-ACK arrives and MUST NOT be used
        has a source address for any subseqent packets. This means that 
        any datagrams that arrive before the REL-ACK destined to 
        the IP address being deleted MUST be considered part of the 
        current association. One special consideration is that ABORT 
        chunks arriving destined to the IP address being deleted MUST 
        be ignored.
"

>         Also, I would add that the IP address to be deleted must not be
> considered a valid source address for any chunk we send (I think there was
> kind of mixture between this idea and the immediate one I have commented).
> 
>         - Section 4.1, D4), at the end: "... (see Section 4.1 for further
> details).". We are already in that section, maybe it should say "the end of
> Section 4.1", or maybe better, including the example after D4, so you don't
> have to go forward and backward... SCTP RFC is much bigger document than
> this one, but I remember (and I know some other people too) how painful it
> was having to be changing quite often the page I was reading to look for
> something explained in a more detailed way in another section...
> 

I think striking the reference is better. I don't want to put
the examples up with the rules I think this is more confusing...

>         - Section 4.1, D6): The paragraph is a little bit complicated to
> understand due to its structure... I would propose something like:
> 
>    "D10) An endpoint MUST NOT send a REL-REQ chunk from a source address
>         (of the IP packet containing the SCTP packet) that is asked to be
>         deleted inside that REL-REQ chunk."

Don't you mean D6) here not D10)?
 
If so I agree :)

> 
>         - Section 4.1, D9): "... the endpoint MUST NOT use the deleted IP
> address as a source of any SCTP packet.". In my opinion there is again the
> same typo as in D4... I guess that the idea is that in the moment we send
> the REL-REQ we stop sending datagrams from than address, and once we receive
> the REL-ACK we stop listening in that address. So, shouldn't it be something
> like "... the endpoint MUST NOT consider the deleted IP address as valid for
> the association to receive SCTP packets from."?

With the change above I think we can kill  D9 altogether.

> 
>         - Section 4.1, D1) - D13): I think that things are a little bit
> mixed here... In my opinion it would be easier to follow the general
> procedure, if the order were the next:
> 
>         D3): At the beginning of the section.
>         D1) and D2): About the IP add procedure.
>         D10), D11) and D12): About the 'Operation Refused due to Resource
> Shortage' error code possibly received when sending the IP add request.
>         D4) and D9): About the IP delete procedure.
>         D5) and D7): About not deleting the last address.
>         D6) and D8): About not deleting the address used as source address
> for the REL-REQ chunk.
>         D13): About deleting the primary address.
> 

Hmm I will think about the above for a while... I want to make a
copy.. rearrange and read through :> .. but not today.. the
kernel crashes I have put into FreeBSD's SCTP stack are calling :0

>         - Section 4.1, first example of DATA out of order: I think that not
> only DATA chunks can cause this... also HEARTBEAT or some other chunk types,
> like SHUTDOWN, SHUTDOWN ACK or even REL-REQ... (maybe not SACK, SHUTDOWN
> COMPLETE, REL-ACK, or the ones for the initialization... and definitely not
> HEARTBEAT ACK). Also, maybe it would be better including this example after
> D1.

Yes, this is true ... but the illustrations are to show a point.. i.e.
you must expect things out of order and may have deleted or added
a address and then get something on it... I could have used HB or any
such chunk but I thought Data was more relevant :0

I again want to keep the examples seperate... at least this
is my leaning...

> 
>         - Section 4.1, second example of DATA out of order: I think that if
> we have already stopped listening in that address, we won't actually receive
> the old DATA packet... So I believe that there isn't any possibility of
> treating it as an OOTB, since actually we have already closed the socket

No this is NOT true. Your kernel will always be there and hear messages
on sockets that have no listner and then respond with a OOTB abort..

> listening on that address and port, and so, the DATA will be lost... Only if
> another association has started to use it, the DATA will be received, by
> that other association, that eventually will answer with an ABORT that will
> be discarded by the sender of the DATA since it comes from another
> association. But we don't bother about this...
> 
>         And again, this can happen with any SCTP datagram, not only DATA
> chunks...

Of course, I used DATA has an example like I said above..

> 
>         - Section 4.1, third example of DATA out of order: Again, not only
> DATA chunks... In any case, I think that it would be better including this
> example after D4.

see above

> 
>         - Section 4.2, first paragraph: "In other words a sender MUST NOT
> bundle a set primary with an add of a new IP address unless the add request
> is to be processed BEFORE the set primary." Why this? I don't see the
> problem of doing that, unless both the address addition, and the request to
> set it to be the primary, affect to the same address... I'm sure I'm missing
> something, what is the reason of this?

You send me

1:SETPRIMARY(X)   --------------------->
2:ADD(X)

                          I process SETPRIMARY(X) ... error I have no X
(ignore)
                          ADD(X)... add it to the assoc.
 
<------------------REL-ACK

Now you think the setprimary took effect and in reality I ignored
it since you were setting primary to a NON-EXISTANT address (in my
view).

> 
>         - Section 4.2, last paragraph: "If a request arrives that asks the
> receiver to set an address as primary that does not exist, the receiver
> should NOT honor the request, leaving its existing primary address
> unchanged.". In this case, should we just send the REL-ACK without including
> anything for that specific request, so the requestor will think that we
> actually made the change (actually this is not a bad option at all since the
> peer doesn't have to know which is our primary address)? or should we send
> an error back to the requestor? In case we send something telling about the
> failure, I can think about one new error cause, 'Address not in use', that
> could be also be sent with debugging purposes when the peer sends us an IP
> deletion request and we are not using that address... maybe it is not worth
> having a new error code, since both situations are not "critical" at all...
> maybe some other extensions could also make use of it... just thinking...

I did not see any setprimary has a error. Since this is just nothing
more than a HINT to the receiver of it to move the primary and it
is not required to honor it.

> 
>         And also, I found some typos:
> 
>         - Section 1: "It also provides a method for a endpoint..." should be
> "It also provides a method for an endpoint..."
> 
>         - Section 1: "... type of services that exist in telephony
> signalling,..." should be "... type of services that exist in telephony
> signaling,..."
> 

This one depends on if you use the British or American spelling :)

>         - Section 3: "We also describe a REL-ACK parameter...". There are
> three parameters. Jon Berger already pointed it in the first version, but
> this change have been forgotten when updating the draft... No matter how
> much coffee you drink, it is never enough! ;-)
> 
You got that right :0 got it this time...

>         - Section 3.1.3: "... 10.1.1.1 be made the primary destination
> addrss would look..." should be "... 10.1.1.1 be made the primary
> destination address would look..."

got it

> 
>         - Section 3.2.1: This is not a typo just a make up issue, but it is
> kind of funny that you have written "var" as the Cause Length in three
> places, and you have done it as "var", "Var" and "VAR" ;-)

I have made them all to be Variable... like the first 3...

> 
>         - Section 4.1, D8): "... the receiver MUST send a Error Cause TLV
> set..." should be "... the receiver MUST send an Error Cause TLV set..."

> 
>         - Section 4.1, D10): "... error code "Operation Refused due to
> Resource Shourtage"." should be "... error code "Operation Refused due to
> Resource Shortage".".
> 

ok
>         It was such a big mail... I hope that some of you even reached this
> paragraph. In any case thanks for the time I have stolen you!
> 
>         BR Iván Arias Rodríguez
> 
>   ------------------------------------------------------------------------
>                                                         Name: draft-ietf-sigtran-addip-sctp-01(section 4.1).txt
>    draft-ietf-sigtran-addip-sctp-01(section 4.1).txt    Type: Plain Text (text/plain)
>                                                     Encoding: quoted-printable

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

---

From: [email-masked]
Date: Thu, 15 Mar 2001 19:16:29 +0200

Thanks for your answer Randall! Sorry but I have some more comments
inline...

> And yes, the ABORT T bit should be set before you allow a tag that

	No, I was just concerned about the possibility of having a client
that is allowed to pick the same tag as the server, and then, add one of the
source IP address of the server as a valid destination IP address for the
server, and then disconnecting. This would cause that the server would send
things to itself and it would accept them as valid thinking that they come
from the client...	If for example the heartbeat mechanism was enabled,
even if the client disconnects from the association, the server would still
hold that association, since it would reply to its own HEARTBEAT thinking
that the HEARTBEAT ACK chunks come from the peer... Maybe this could be an
"attack" somehow similar to the SYN attack, since only one side of the
association is alive and wasting resources...

	BUT, since I haven't found (not yet! ;-)) any easy way so the client
can pick the same tag than the server, this may not be a problem. Only the
server could easily pick the same tag of the client, but as you say this
would only cause troubles to itself, or somehow allow it to make this
"attack" to the client (how would like to connect to a malicious server?)...
so we shouldn't bother about it...

> valid association... so you do have some relationship with the peer.

	Yep, it would be one of your clients... But I don't see any kind
reason to make the server send things to itself...

> between it and its server... it does not really hurt other 

	Ok.

> I think the authors all feel we should).

	I think that REL-REQ draft is not a bad thing. Maybe it adds some
more header overload and makes it possible to have only one request
unacknowledged (maybe if you use different chunks, there wouldn't be this
restriction for chunks that request for different type of things), but, in
any case, even if you don't use the REL-REQ and REL-ACK chunks I think that
it would be useful at least to define a method of doing this sending of
reliable control chunks without affecting the congestion mechanism either...
so some other drafts can add their own chunks to do that work, but in the
way is explained in the REL-REQ draft...

> The receiver of the add IP address request may use the address has a

	Well... this is not exactly what I was thinking about, but it is
true that this should also be stated... Maybe this could be included in D10)
stating that if the receiver of the REL-REQ with the Add IP has resources,
then it starts using it as a destination address (maybe first checking that
the address is not one of its own source addresses), otherwise it sends the
'Operation Refused due to Resource Shortage'.

	But what I was thinking here was about the REL-REQ sender side, not
the receiver, something like:

	"The sender of the add IP address request must immediately consider
SCTP datagrams directed to that address as datagrams directed to the
association".

	Also, in case the REL-REQ sender receives that 'Operation Refused
due to Resource Shortage', it shouldn't consider that address as valid for
receiving SCTP datagrams anymore... In D11) is only said that in that case
the address is not used as source (actually it has never been allowed to use
that address as source), but maybe it should say also that datagrams
directed to that address are not considered as valid datagrams from the
REL-REQ point of view.

	But, thinking about the problem of the source addresses... Things
are like this (I hope I'm not wrong in this basic issue):

	- One SCTP endpoint manages several IP addresses (which correspond
with network cards of the host), maybe all of them, maybe not, and it uses
one port number.
	- In the same host can be several SCTP endpoint, as far as they
don't share the management of any of the host's addresses if they use the
same port number. In other words, there can't be any IP address which is
managed by more than one SCTP endpoint at the same time if those SCTP
endpoints use the same port number.
	- The SCTP endpoint can have several associations (which are in any
state at any moment). Each one uses the port of the SCTP endpoint and all or
part of the addresses the SCTP endpoint manages.

	So, if we really can't decide at all the source address, it leads to
several considerations:

	- If the host has several IP address, if the SCTP endpoint manages
only part of them, maybe it is not possible to force the SCTP datagrams
being sent by that endpoint to be sent only from the addresses that SCTP
endpoint manages. This possibly maybe makes impossible to have SCTP
endpoints that don't manage all the address of the host, since eventually
one datagram sent by one endpoint would be sourced from an address that it
doesn't manage.
	- If the associations of one SCTP endpoint can use part of all the
addresses that the SCTP endpoint manages, and not necessarily all of them,
maybe it is not actually possible to force a datagram sent by one
association of the SCTP endpoint to be sent only from the addresses that
association manages. This possibly makes compulsory that the associations of
a SCTP endpoint have to use all the addresses the SCTP endpoint manages
(which should be all of the host, due to the above statement).
	- If any association inside a SCTP endpoint must use all the
addresses that SCTP endpoint manages, and the SCTP endpoint must use all the
addresses of the host, maybe it is only possible to add or delete addresses
if at the same time we physically connect or disconnect the network cards...
or if the IP addresses corresponding with the network cards are modified.
I'm sure that you have had to think about this before... But how can we
solve this "source" address problem?

	If we could choose the source address (actually I think this is
possible if all our cards are connected to the same network, but in that
case the multihomming would be maybe of little use...), then we don't have
the restrictions stated above, but if there is a possibility of having two
associations inside the same endpoint, that use the same port but different
sets of addresses of the SCTP endpoint (and there isn't any IP address used
by both associations), which I don't know if is possible, then, there must
be a mechanism to avoid them to add an IP address that is being used by the
other association, or not trying to add the same IP address at the same
time. Maybe this shouldn't be mentioned in the draft...

> I think this is better because I feel the rule belongs where it is...

	Also, in D3), maybe it should be said that not only we stop sending
Add IP, Delete IP or Set Primary if the REL-REQ parameter is not understood,
but also if the REL-REQ chunk itself is not understood (as it is said in
section 4.1 of the srwnd draft...).

>         chunks arriving destined to the IP address being deleted MUST 

	Exactly.

> the examples up with the rules I think this is more confusing...

	In my opinion, those examples make clearer the rules (at the
beginning I was curious why ABORT chunks should be discarded, it's not that
easy to immediately know why)... I guess that what most people will do would
be, either going to the example before reading the next rule, either reading
again the rule after reading the example... The examples are not so big that
they make you forget about the previous rules...

> With the change above I think we can kill  D9 altogether.

	Yep... Also, maybe we could go again to the REL-REQ receiver side,
and saying that from the very moment the REL-REQ delete IP is received, the
receiver shouldn't send any more datagram to that address, and shouldn't
consider datagrams coming from that address as part of the association...

> on sockets that have no listner and then respond with a OOTB abort..

	You are COMPLETELY right here... It is not possible... I was
confusing here deleting one address from one association and deleting one
address from one SCTP endpoint... Yes, the example MUST be there to explain
the situation...

> it since you were setting primary to a NON-EXISTANT address (in my

	Yep, I'm completely with you that this example is right, and what
you say will happen. But the point is that, both the SETPRIMARY and ADD
affect to the same address... That's what I was saying... I don't see the
problem of doing:

1:SETPRIMARY(X)   --------> I process SETPRIMARY(X) 
2:ADD(Y)                    It is supposed that X is
                            being used. So it doesn't
                            fail.

                            I process ADD(Y)...
                            Add it to the assoc.
 
         <----------------- REL-ACK

> This one depends on if you use the British or American spelling :)

	Ups! My mistake! :-O

	Thanks a lot for your comments Randall!

	BR Iván Arias Rodríguez

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: [email-masked]
Date: Fri, 16 Mar 2001 13:03:39 +0200

Thanks Jon, more comments inline:

	[snip]

> [Jon] - Addition of IP addresses is only possible if 
>  - you can control the source address of all packets (this 
> allows you not to
> use
>    the new address until the peer endpoint has agreed).  If 
> you don't do
> this 
>    you run the risk of ABORTing the association.

	Why not saying something like this in the draft?... Also, as far as
I know, nowadays this is possible only if all your cards are plugged to the
same network...

>  - you "ask permission" of the SCTP stack before adding the 
> new card. (This
> allows 
>    the SCTP "negotiation" to take place before it is possible 
> to source
> packets 
>    from the new address but in general is not very practical.
> There are no such restrictions on deleting an IP address as
>  - obviously once a card has been removed, it can no longer 
> source packets

	And you should remove that address of every association of the
endpoint...

>  - the peer cannot refuse the deletion as it does not consume 
> resources.

	Unless it is the last address... but I hope nobody would extract one
network card before checking that there isn't any association in the host
using only that address at that moment...

	[snip]

	Thanks!

	BR Iván Arias Rodríguez

---

---

From: "Randall R. Stewart" <[email-masked]>
Date: Mon, 26 Mar 2001 08:14:23 -0600

> way is explained in the REL-REQ draft...

REL-REQ will not survive the next round of drafts.. we will remove
it has discussed at the tsvwg..

> SCTP datagrams directed to that address as datagrams directed to the

It already states this in the draft:
"
    For the ADD case an endpoint SHOULD consider the newly adding IP
    address valid for the association to receive data from during the
    interval when awaiting the REL-ACK. The endpoint MUST NOT source
data
    from this new address until the REL-ACK arrives but it may receive
out
    of order data as illustrated and MUST NOT treat this data as an OOTB
    datagram (please see [RFC2960] section 8.4). It MAY drop the data
    silently or it MAY consider it part of the association but it MUST
NOT
    respond with an ABORT.
"

> are like this (I hope I'm not wrong in this basic issue):

Hmm.. so you are saying the receiver of the ADD request refuses the
add, and then sends data destined to that added address. This is
quite a pathological case.

I agree we  can tighten D10 to clearify that if the operation fails
then the address is NOT part of the assocaition.. there is a window
of time while you await the refusal that you WOULD accept packets
from the peer destinated to the address. This is probably ok, since
if the peer continues to send to this "new" address, it will get
an ABORT ...

> with network cards of the host), maybe all of them, maybe not, and it uses

Yes, but several IP addresses may also be assigned to the same NIC.

> endpoints use the same port number.

Yes, this has always been the case...many implementations take a
short cut on this though, either 

A) You always get all the IP addresses "reserved" for you 

or

B) You can either bind one IP address with port or all IP addresses
   with port... but not subsets.

>         So, if we really can't decide at all the source address, it leads to

I don't see what you mean "can't decide at all the source address". An
implementation that has access to the routing tables can know what it
should use as a source address. There will be some implementations
that do not have this knowledge, but any kernel implementation won't
have this problem...

> one datagram sent by one endpoint would be sourced from an address that it

No, source addresses do not dictate what interface your packet travels
out. If you fill in a source address it is NOT even looked at to
decide which NIC to send the packet out. If you leave the source
address un-specified, i.e. all 0's, then the IP stack will fill
in one of the addresses of the NIC it sends the packet out. I really
don't understand your issue...

> (which should be all of the host, due to the above statement).

No, I can always fill in a source address in a packet (even from a
raw IP socket). Now I think you are under the mis-guided belief that
the source address will be changed if you fill it in based on what
address the packet is sent out. This is just NOT true... the IP stack
will leave the source address untouched unless you specify the address
to be '0'. 

> solve this "source" address problem?

Please look at the latest ref-implementation. It still as some bugs
but it solves this problem quite well I think... In 4.0.4 (next release
it will have a LOT of bug fixes) In 4.0.5 the FreeBSD ilk will get
a routing socket to make less "brain dead" decisions for selecting
the source address....

> time. Maybe this shouldn't be mentioned in the draft...

This is an implementation issue. If I allow subset address binding then
I
must make it possible to bind in an address on the fly. And BEFORE I
send out an ADD request I must do so. If the add request fails I must
"un-bind" this address.... If it suceeds I can start using it has
a source. During the time while I am waiting for the ACK to my add
I must specify source addresses until I get the ACK....

Spend some time looking at one of the BSDs IP stack's... It is
good code to read (easy when compared to Linux) and may straighten
out some of your mis-conceptions...

Now the reference implementation takes a "easier" approach. It does
NOT allow sub-set binding. I think many of your questions are more
related
to source address selection and how IP stacks work... have a look in
FreeBSD I think it will enlighten you :)

> section 4.1 of the srwnd draft...).

Again.. no more REL-REQ so this is not needed... there will be
quite a bit of word-smitthing in the next revision and of course
four additional chunk types will be allocated...

> they make you forget about the previous rules...

I think no matter what you must READ the WHOLE document before you
begin to code... :) 

> consider datagrams coming from that address as part of the association...

Ok this is reasonable. Lets add D13)
"
    D13) When an endpoint receives a valid request to DELETE an IP
address
         the endpoint MUST consider the address no longer as part of the
         association. It MUST NOT send SCTP packets for the association
to
         that address and it MUST treat subsequent packets received from
that
         address as Out Of The Blue.

"
>          <----------------- REL-ACK

You may be able to process it but you may have a sender that may well
be mis-lead in that it thinks you know it preference for primary when
you don't.

Besides which, why should we allow a sequence that is CLEARLY invalid?

---