Andrey Konstantinov | 2 Mar 2009 08:56
Picon

SCTP: new chunks definition

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

Michael Tüxen | 2 Mar 2009 09:31
Picon

Re: SCTP: new chunks definition

Hi Andrey,

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

Best regards
Michael

On Mar 2, 2009, at 8:56 AM, Andrey Konstantinov wrote:

> 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
(Continue reading)

Andrey Konstantinov | 2 Mar 2009 13:23
Picon

Re: SCTP: new chunks definition

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

2009/3/2 Michael Tüxen <Michael.Tuexen <at> lurchi.franken.de>:
> Hi Andrey,
>
> first question: Why would you like to have such a mechanism?
>
> Best regards
> Michael
>
> On Mar 2, 2009, at 8:56 AM, Andrey Konstantinov wrote:
>
>> Dear experts,
>>
>> I am looking for the possibility to change local V-Tag of the
>> association in run time without it's restart.
>>
(Continue reading)

Brian F. G. Bidulock | 2 Mar 2009 13:55
Favicon

Re: SCTP: new chunks definition

Andrey,

Andrey Konstantinov wrote:                   (Mon, 02 Mar 2009 15:23:58)
> Hi Michael,
> 
> I can not provide to you full background information due to security
> reasons (at least now).

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

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

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

> 
> 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
(Continue reading)

Andrey Konstantinov | 2 Mar 2009 14:17
Picon

Re: SCTP: new chunks definition

Hi,

2009/3/2 Brian F. G. Bidulock <bidulock <at> openss7.org>:
> Andrey,
>
> Andrey Konstantinov wrote:                   (Mon, 02 Mar 2009 15:23:58)
>> Hi Michael,
>>
>> I can not provide to you full background information due to security
>> reasons (at least now).
>
> It seems unlikely that you could write a useable draft given those
> kinds of constraints.
I believe that constraints will be removed some when. I understand the
limitation.
I am not right person who decide to open the information.
>
>> 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.
>
> 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).
Sure, it should know both V-Tags.
> If you know the existing v-tags, why not just use them for the new
> association?
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.
(Continue reading)

Michael Tüxen | 2 Mar 2009 14:20
Picon

Re: SCTP: new chunks definition

Hi Andrey,

comments in-line.

Best regards
Michael

On Mar 2, 2009, at 1:23 PM, Andrey Konstantinov wrote:

> Hi Michael,
>
> I can not provide to you full background information due to security
> reasons (at least now).
So it is hard to discuss if your solution is appropriate for
your problem...
>
> 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.
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  
> available.
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...
(Continue reading)

Andrey Konstantinov | 2 Mar 2009 14:46
Picon

Re: SCTP: new chunks definition

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 <randall <at> lakerest.net>:
> 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,
>>
>> 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).
(Continue reading)

Michael Tüxen | 2 Mar 2009 14:50
Picon

Re: SCTP: new chunks definition

On Mar 2, 2009, at 2:46 PM, Andrey Konstantinov wrote:

> Hi,
>
> 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?
>
> Thanks, I'll take it into account.
>
> Best regards,
> Andrey Konstantinov
>
> 2009/3/2 Randy Stewart <randall <at> lakerest.net>:
>> 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.
>>
(Continue reading)

Brian F. G. Bidulock | 2 Mar 2009 14:55
Favicon

Re: SCTP: new chunks definition

Andrey,

> 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

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
bidulock <at> openss7.org
http://www.openss7.org/

Randy Stewart | 2 Mar 2009 15:01

oopps

Yes this is one of my alternates..

I must have clicked the migrate all on the
tsvg woops

-----
Randall Stewart
randall <at> lakerest.net


Gmane