Subject: [Tsvwg] Comments about the AddIP draft

From: [email-masked]
Date: Tue, 5 Feb 2002 21:01:57 +0200

Hi all!

	I have some comments/typos about this draft. Here they go!:

	- The flow limits procedures were taken out from the draft. I read the comment about the Abstract. However, the chunks themselves are called "Address/Stream...". I guess that the "Stream" part should maybe taken off... This affects to Section 3.1, Table 1 (both the ASCONF chunk and the title of the table) and the title of sections 3.1.1 and 3.1.2 (also in the index).

	Also, in that case, shouldn't the chunks be called ACONF and ACONF-ACK?

	- Section 3.1.1, first paragraph. Does TLV stand for Tag-Length-Value or Type-Length-Value (or most probably, both)?

	Another issue. Is there any restriction for the value of the Correlation IDs (apart from being unique inside the ASCONF)? Could they simply be set to 0, 1, 2, 3... in every ASCONF chunk?

	- Section 3.3, Table 3: The Cause Code Values are wrong... There are 0s missing...

	- Section 3.3.2, first paragraph: Shouldn't be the "ASCONF-REQ" chunk that appears there simply "ASCONF"?

	- Section 4.1.1, R2): What is the meaning of "if there is room in the cwnd"? I mean, there is room for a DATA chunk if the user data (but not the whole chunk) is not bigger than cwnd. How is this applied to an ASCONF chunk? I can think about not sending an ASCONF chunk whose total length is not bigger than the cwnd... But it wouldn't silly thinking about being able to send it if cwnd is at least 1 byte... or maybe I'm just silly :-)

	Moreover, imagine we have an ASCONF chunk that could not be sent due to cwnd, and several DATA chunks kept at the sender (I would say the normal situation when we are sending data using the whole cwnd). When a SACK chunk comes, which one has the priority? I mean, should we send as many DATA chunks as we can and then the ASCONF (if there is still room for it), or should we send the ASCONF first?

	- Section 4.3, D0): This happens when an attacker has sent an ASCONF chunk to our peer, knowing the Verification tag, the Serial Number and faking one of our addresses, and our peer sent the ASCONF-ACK to us. If we are going to abort the association, wouldn't it be nice to have an Error Cause to tell the peer about this? Otherwise, the peer will simply receive suddenly an ABORT chunk now knowing why... If there is such an attacker, we cannot do anything against it, but at least the peer would also know about it...

	- Section 4.3.2, first paragraph: IPv6 addresses can be renumbered and that makes that the ASCONF chunk has to carry in this case one of the old IP addresses in order to be able to find the association. Sorry, but I have never liked that much this... :-)

	Couldn't this be avoided simply sending an ASCONF including both an addition (the new address) and a deletion (the old one)? It is true that upon receipt, the datagram will come from the new address and thus it will seem to be an OOTB one at the first sight. But in this cases, we take a look inside the datagram and check if there is an ASCONF chunk, and then we check if the Address Bytes correspond to any of our addresses. As this is already a special case, why don't we look inside the ASCONF chunk and try to find there a Delete IP Address parameter with one of the old addresses (which should be the only address of an association)? Putting this parameter the first one inside the ASCONF chunk would make things mostly the same as they are now. However, it would violate the rule of not erasing the last address. It could also be the second one, as far as the first paragraph is an addition... which would not make things much harder either...

	The procedure now is like this:

		a) If we have an OOTB datagram, check all the other exceptions we already had. If we are not in any of those situations, look for an ASCONF chunk.
		b) If there is an ASCONF chunk check the Address Bytes and check if that address appears in any of your associations.

	The new one would be:

		a) Same as before.
		b) Check that the chunk has at least two parameters.
		c) If so, check that the second parameter is an deletion and check if that address is part of any of our existing associations.

	Or even simpler. We could require in this case that the peer simply sends an ASCONF carrying a single Delete IP Address parameter, and we could in this case add the source address of the SCTP datagram... I don't know, whatever, but... wouldn't the ASCONF chunk (without those Address Bytes) be... more "beautiful"? ;-)

	Or another possibility of change... why not simply adding an IPv4/IPv6 Address parameter when necessary (only in this special "renumbering case") instead of using the Address Bytes? We could force that in this case this parameter should be the first one in the ASCONF chunk.

	In any case, when we are facing renumbering and we receive the ASCONF chunk, wouldn't it be a good idea forcing the ASCONF to be the first one in the datagram (so it is easier to recognize the OOTB packets)?

	I know that this can happen in IPv6, but, can something similar happen in IPv4? If not, why including that Address Type?

	And the last comment about this. Should always the Address Type/Address Bytes fields of the ASCONF chunk be set to one valid address of the association? If not, and it should be set only in the "renumbering case", should we fix them to all 0s when they are meaningless?

	And finally, some minor typos:

	- Section 3.2.5, first paragraph of page 9: "... report an success..."

	- Section 3.2.6, first paragraph: "...the INITand INIT-ACK...", and "...specify a bit int the reserved...".

	- Section 4.1, last paragraph of page 12: I guess that "Each destination address a single RTO estimate" should be "Each destination address has a single RTO estimate".

	- Section 4.1.1, R2), R3), R4) and R7): "A ASCONF" and "... a ASCONF..." might be "an ASCONF".

	- Section 4.1.1, last paragraph of page 13: "... receives a Operational...".

	- Section 4.2, V2): "... in in the INIT ACK...".

	- Section 4.3, D6): "... set a IP header...".

	- Section 4.4, second paragraph: "... appear in a INIT or...".

	Well, that's all, thanks for your time!

	BR Iván Arias Rodríguez

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 05 Feb 2002 14:30:17 -0600

>         - The flow limits procedures were taken out from the draft. I read the comment about the Abstract. However, the chunks themselves are called "Address/Stream...". I guess that the "Stream" p…

And one in section 4 as well :0 I will change this in -05...

>         Also, in that case, shouldn't the chunks be called ACONF and ACONF-ACK?

I think ASCONF is easier to say.. so lets leave the S in just for fun :>

>         - Section 3.1.1, first paragraph. Does TLV stand for Tag-Length-Value or Type-Length-Value (or most probably, both)?
Hmm we should use only one term.. but both areactually the same :>

I see we use Type-Length-Value in RFC2960 so I will change -05 to match.

>         Another issue. Is there any restriction for the value of the Correlation IDs (apart from being unique inside the ASCONF)? Could they simply be set to 0, 1, 2, 3... in every ASCONF chunk?

I see no reason why there would be any restrictions.. since you can
only have one out at a time... One could use the same 0-N each
time...

Of course for added security one could even use random values :>

>         - Section 3.3, Table 3: The Cause Code Values are wrong... There are 0s missing...

You would like leading 0's then.. ok I will add them :>

>         - Section 3.3.2, first paragraph: Shouldn't be the "ASCONF-REQ" chunk that appears there simply "ASCONF"?

Yep .. just ASCONF

>         - Section 4.1.1, R2): What is the meaning of "if there is room in the cwnd"? I mean, there is room for a DATA chunk if the user data (but not the whole chunk) is not bigger than cwnd. How i…

I don't think we need to limit ASCONF's based on if they fit in the
cwnd. The idea here was to keep someone from pounding out ASCONF's
when one could not normally send data... Hmm I suppose we could
make it so it must fit in the cwnd.. but it really does not take
up any cwnd space.. i.e. it is not tracked as a "inflight" data since
it is not data. 

I think we can just allow a simple check

if(inflight > cwnd)
	delay sending asconf
else
        send asconf..

>         Moreover, imagine we have an ASCONF chunk that could not be sent due to cwnd, and several DATA chunks kept at the sender (I would say the normal situation when we are sending data using the…

Since the ASCONF does not take up any room one would send

ASCONF+DATA--->
DATA->
DATA-->

until the full cwnd was occupied by the data heading out.

Since one can only have one out at a time I think it is reasonable.

>         - Section 4.3, D0): This happens when an attacker has sent an ASCONF chunk to our peer, knowing the Verification tag, the Serial Number and faking one of our addresses, and our peer sent th…

Hmm.. yes we could add an error cause something like:

 - Association aborted due to illegal asconf-ack

>         Couldn't this be avoided simply sending an ASCONF including both an addition (the new address) and a deletion (the old one)? It is true that upon receipt, the datagram will come from the ne…

This is a lot of overhead considering there may be many addresses and
you thus have to grub through ALL the addresses. Having a fixed
place to look is much quicker... I don't think I like this idea..
sorry..

Having implemented this it is quite easy.. if you see it is an asconf
and you have not found the assoc, you look in one place.. instead
of having to parse all the asconf parameters...

>         Or even simpler. We could require in this case that the peer simply sends an ASCONF carrying a single Delete IP Address parameter, and we could in this case add the source address of the SC…

Nope. I don't see how the above would work with a single delete.. you 
may well end up deleting the LAST address... No it is far
easier to have one lookup location and look it up... There are
other cases we have seen in our testing (when renumbering occurs) that
the address bytes are really essential... 

An address can become unusable and yet its present for a while. No
delete shows up.. instead you just have the new one added and the
old one hanging on in a IFF_DETACHED state. This kills you unless
you have something like the address bytes.. 

I think that :

A) they are necessary
and
B) they are efficient.. and they are only 16 bytes on a really
   special case thing (ASCONF) that is not that often sent...

>         Or another possibility of change... why not simply adding an IPv4/IPv6 Address parameter when necessary (only in this special "renumbering case") instead of using the Address Bytes? We coul…

This is better but I see no advantage to a TLV other than saving
a few bytes on every message.. I don't see how it is worth it.. and even
more so one has to go looking for the TLV instead of looking in a
fixed postion. This requires the code that is worriing about
lookup/vtag verfication to know more about TLV's and things .. more
work in my mind.. I like the fixed location.. sorry that you dont :-0

>         In any case, when we are facing renumbering and we receive the ASCONF chunk, wouldn't it be a good idea forcing the ASCONF to be the first one in the datagram (so it is easier to recognize…

I think the ASCONF has to be the first one or you will get an
ABORT back.. You have to be ready for this case (since you could
get re-ordering or something) but still.. probably a good idea..

>         I know that this can happen in IPv6, but, can something similar happen in IPv4? If not, why including that Address Type?

Yes, it can... consider the administrator does:

ifconfig mynet 10.1.1.3 netmask 0xffffff00

Now bring up an sctp association etc... and things
are humming along..

Now my administrator (which may not be me) says .. oh no
I fat fingered it and my address is really 10.1.1.9

ifconfg mynet 10.1.1.9 netmaks 0xffffff00

And boom.. you have the same case.

I have tested with this scenario by the way.. it works very nicely
too..

>         And the last comment about this. Should always the Address Type/Address Bytes fields of the ASCONF chunk be set to one valid address of the association? If not, and it should be set only in…

I see no reason that it cannot be filled all the time. We do it this
way in our implementation since it makes building the chunk
much easier...

>         - Section 3.2.5, first paragraph of page 9: "... report an success..."

got it.

>         - Section 3.2.6, first paragraph: "...the INITand INIT-ACK...", and "...specify a bit int the reserved...".

got it

> 
>         - Section 4.1, last paragraph of page 12: I guess that "Each destination paddress a single RTO estimate" should be "Each destination address has a single RTO estimate".

yep.

>         - Section 4.1.1, R2), R3), R4) and R7): "A ASCONF" and "... a ASCONF..." might be "an ASCONF".

ok

>         - Section 4.1.1, last paragraph of page 13: "... receives a Operational...".

got it..

>         - Section 4.2, V2): "... in in the INIT ACK...".
ok
>         - Section 4.3, D6): "... set a IP header...".

yep
>         - Section 4.4, second paragraph: "... appear in a INIT or...".
got it..

>         Well, that's all, thanks for your time!
Thanks for your close look Ivan..

R

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