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

From: [email-masked]
Date: Wed, 14 Mar 2001 13:37:14 +0200

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

	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:

	- 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]."

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

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

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

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

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

	- 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."?

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

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

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

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

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

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

	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,..."

	- 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! ;-)

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

	- 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" ;-)

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

	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

---

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

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

> mail... maybe it would make your life easier... The comments are:

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

>     procedures for transmitting reliable SCTP control chunks are covered in

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

> order. Maybe the example given at the end of the section could be included

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, maybe at the beginning of section 4, or as a note at the end of

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

> still RECEIVE any chunk, and not SEND them... And also not only DATA ones

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

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

>         deleted inside that REL-REQ chunk."

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

> the association to receive SCTP packets from."?

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

>         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

> HEARTBEAT ACK). Also, maybe it would be better including this example after

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

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

>         And again, this can happen with any SCTP datagram, not only DATA

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

> DATA chunks... In any case, I think that it would be better including this

see above

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

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

> signalling,..." should be "... type of services that exist in telephony

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

> much coffee you drink, it is never enough! ;-)
You got that right :0 got it this time...

> destination address would look..."

got it

> places, and you have done it as "var", "Var" and "VAR" ;-)

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

> Resource Shourtage"." should be "... error code "Operation Refused due to

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

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