Subject: [Tsvwg] SCTP: new chunks definition

From: Andrey Konstantinov <[email-masked]>
Date: Mon, 2 Mar 2009 10:56:37 +0300

Dear experts,

I am looking for the possibility to change local V-Tag of the
association in run time without it's restart.

The idea of the extension is following:
Local SCTP asks remote SCTP to change V-Tag (firstly defined by local
side during start-up).
I guess new chunk should be defined for this purpose. Remote side
changes it and acknowledges the operation with help of another new
chunk.
INIT and INIT_ACK chunks are extended in order to negotiate support of
the feature during start-up.

Could you point me out to a RFC or draft if a similar extension of
SCTP has been already defined?

If I am the first with such type of request could you provide me input
information how can we register, develop, review and approve this
extension with IETF?
The company which will possibly drive the development of the extension
is Ericsson and/or Tieto.

Thanks in advance,
Andrey Konstantinov

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 2 Mar 2009 09:31:12 +0100

Hi Andrey,

first question: Why would you like to have such a mechanism?

Best regards
Michael

---

From: Andrey Konstantinov <[email-masked]>
Date: Mon, 2 Mar 2009 15:23:58 +0300

Hi Michael,

I can not provide to you full background information due to security
reasons (at least now).
In two words, it is needed for possibility to replace old association
by new without restart event for remote side and with keeping data
buffers.

Using your answer I can guess that the needed extension is not available.

PS: I have got an aswer how to process new draft.

Best regards,
Andrey Konstantinov

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 2 Mar 2009 05:55:41 -0700

Andrey,

Andrey Konstantinov wrote:                   (Mon, 02 Mar 2009 15:23:58)
> I can not provide to you full background information due to security

It seems unlikely that you could write a useable draft given those
kinds of constraints.

> by new without restart event for remote side and with keeping data

That can be done more easily by NOT changing the v-tag.  To request
that the peer change its v-tag would certainly require the knowlege
of the existing v-tags for both sides (to preclude simple DoS attacks).
If you know the existing v-tags, why not just use them for the new
association?

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Andrey Konstantinov <[email-masked]>
Date: Mon, 2 Mar 2009 16:17:58 +0300

Hi,

> It seems unlikely that you could write a useable draft given those
I believe that constraints will be removed some when. I understand the
limitation.
I am not right person who decide to open the information.
> of the existing v-tags for both sides (to preclude simple DoS attacks).
Sure, it should know both V-Tags.
> If you know the existing v-tags, why not just use them for the new
There are some other internal limitations which does not allow to reuse V-Tag.
The idea is to define the set of ranges of V-tags per each SCTP
process in distributed SCTP layer.
Changing V-Tag makes possible to change over the handler of the association.

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 2 Mar 2009 14:20:10 +0100

Hi Andrey,

comments in-line.

Best regards
Michael

> I can not provide to you full background information due to security
So it is hard to discuss if your solution is appropriate for
your problem...
> by new without restart event for remote side and with keeping data
Since I do not know your problem, I'm not sure about the solution...
> Using your answer I can guess that the needed extension is not  
There is currently no method of changing the v-tag during the lifetime
of an association. The only reason to do so, would be that it is
a secret to off-path attackers and for long-living associations
they have a long time to guess. This issue has been considered during
the protocol development... And I think changing the v-tag from
time to time is not the right solution. There are others methods...
However, you possibly are considering another problem, who know...
> PS: I have got an aswer how to process new draft.
You might want to read
http://www.ietf.org/ietf/1id-guidelines.html

However, if you want the ID to become an RFC and would like
it to be a standards track document, one way is via getting
consensus about the document in the TSVWG.
However, not knowing why you want a mechanism, might make
it harder to get consensus. But this is only my opinion, and
there are other way for an ID to become an RFC.

---

From: Andrey Konstantinov <[email-masked]>
Date: Mon, 2 Mar 2009 16:46:34 +0300

Hi,

If extend it for V-Tag resetting it could suit...
Thanks, I'll take it into account.

Best regards,
Andrey Konstantinov

2009/3/2 Randy Stewart <[email-masked]>:
> Andrey:
>
> Please go take a close examination of:
>
> http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpstrrst-01.txt
>
>
> This already has a mechanism to do some of the things you are
> interested in I think.
>
> R
> On Mar 2, 2009, at 2:56 AM, Andrey Konstantinov wrote:
>
>> Dear experts,
>>
> -----
> Randall Stewart
> [email-masked]

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 2 Mar 2009 14:50:41 +0100

> If extend it for V-Tag resetting it could suit...
The problem remains: Why do you want this?
Without having a good reason why you want to change
the v-tag, I hesitating to put that into an ID.
It might be a good thing (then I would support adding
it), it might be a bad thing... Currently I see no
good reason why you want to change the v-tag...

Randy?

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 2 Mar 2009 06:55:27 -0700

Andrey,

> The idea is to define the set of ranges of V-tags per each SCTP

So, basically it is to keep from implementing a hash table.
Doesn't sound like a good reason to me...

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Randall Stewart <[email-masked]>
Date: Mon, 2 Mar 2009 09:09:35 -0500

Opps.

It appears my posting are not going .. need to get the right
from email address..

Bottom line.. Yes I agree with Michael and Brian here. We would
need a far vaster understanding of why one would want to do this.

It does not make sense to me.. I am sure there is more to
it then just the desire not to implement a hash table...

Andrey is most welcome to write a draft on the subject. But I don't
think he will find support in the SCTP community without more
details..

Regards

R

>>>> is Ericsson and/or Tieto.

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 02 Mar 2009 07:11:28 -0800

> first question: Why would you like to have such a mechanism?

Having a "V-Tag" that unambiguously identified an association would
benefit any form of SCTP-aware network adapter.

Currently, the host stack can implement strategies that greatly
minimize the risk of two associations having the same V-Tag. Giving
a guarantee, however, would require committing a resource before
the alleged peer did a round-trip.

That said, a totally unambiguous V-Tag is of most value for the
highest bandwidth associations. Those associations are the least
likely to come from far distances where the identity of the peer
is unknown. The greater the need for a clean tag, the less it is
actually needed.

If this were proposed for a clean-slate design it might be a good
idea. It could probably be done as a minor extension to ADD-IP.
You use authenticated chunks to propose the new V-Tag, then confirm
the transition with authenticated chunks using the new V-Tag.

But I'm skeptical that it would be worthwhile as a third round
option. In order for it to be a benefit, there would have to be
a substantial probability that your peer supported the option.

Statistically, the average synonym chain can already have zero
collisions. So it is only the worst-case analysis that is being
improved. But simplifying logic based on the knowledge that the
number of collisions *is* zero would not of much value unless
your probably supports the same feature.

-- 
Caitlin Bestler
[email-masked] - http://www.asomi.com/CaitlinBestlerResume.html

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 2 Mar 2009 16:22:08 +0100

> benefit any form of SCTP-aware network adapter.
Not sure if you really need "unambiguously". For example if you want
to use it for a hash table lookup, you must deal with the case
of multiple entries in the hash bucket anyway. So I do not this
you get much.
On the other hand, when you get an INIT and you choose a v-tag
and it has to be "unambiguously", then you need to mark it as
used. This would mean a state change on the reception of an INIT,
which is not a good thing...
So I think having a good random generator is the best for an
end-point.

Thinking about NAT boxes, you have to deal with collisions. But
this is described in our NAT ID....
> is unknown. The greater the need for a clean tag, the less it is
You could use the vtag for RSS, but you also compute something which
is less than 32 bits. But vtags or optimal for it...
> the transition with authenticated chunks using the new V-Tag.
I have not understood what you gain by this...