RE: Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization

Lars Eggert [mailto:lars.eggert <at> nokia.com] wrote:
> On 2007-2-11, at 17:56, ext Fernando Gont wrote:
> > We have published a revision of the port randomization draft
> > (draft-larsen-tsvwg-port-randomization). This version addresses
> > feedback from Alfred Hoenes and Carlos Pignataro, and comments from
> > FreeBSD's Mike Silbersack. The draft is targetted at tsvwg because
> > the same stuff can be applied to other protocols. But most (all?) of
> > the work on this has been done mainly for TCP.
> 
> The update is at http://tools.ietf.org/html/draft-larsen-tsvwg-port- 
> randomization.
> 
> The concepts in this draft are likely relevant to most of our  
> transport protocols, and hence would be in scope for TSVWG. 
> The TSVWG  
> chairs are interested in comments on whether there is group interest  
> in this draft - please comment on tsvwg <at> ietf.org.

The suggestions in this document are equally important for RTP 
so that attackers are forced to work harder to inject undesired
content into RTP media sessions.  It would be useful if the 
document scope were expanded slightly to explicitly include RTP.  
For example, the Abstract currently says:

   Recently, awareness has been raised about a number of "blind" attacks
   that can be performed against the Transmission Control Protocol (TCP)
   and similar protocols.

it is hard to say that RTP is similar to TCP.  Thus, I would suggest
changing it to something like this:

Re: Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying NewCongestion Control Algorithms) to BCP

----- Original Message ----- 
From: "Erblichs" <erblichs <at> earthlink.net>
To: <mallman <at> icir.org>
Cc: <tsvwg-chairs <at> tools.ietf.org>; <iccrg <at> cs.ucl.ac.uk>; "Pekka Savola" 
<pekkas <at> netcore.fi>; <tsvwg <at> ietf.org>; <ietf <at> ietf.org>
Sent: Wednesday, May 30, 2007 4:46 PM
Subject: Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying 
NewCongestion Control Algorithms) to BCP

> Mark Allamn,
>
> I always have a "internal fight" when I read these
> documents as whether they are meant as a BCP type
> document or...
>
> So, if I can add my thoughts..
>
> 1) Architecture design and implementation can be two completely
>    different items for acceptance criteria. Thus, I might propose
>    the floowing items:
>
>   - two or more implimentations using a new alternate cc algorithm
>     could be used as interoperability against each other and another
>     cc algor..

As long as they both use the same CC Alg's then this is OK...

>
>   - if possible, a Linux, xBSD, etc public reference should be

Clarification on sctp library.

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named
recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions
presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or
publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you
have 
received this email in error please delete it and notify the sender immediately. Before opening any mail
and 
attachments please check them for viruses and defect.

-----------------------------------------------------------------------------------------------------------------------

RE: Re: [tcpm] Revision of draft-larsen-tsvwg-port-randomization

At 19:38 01/06/2007, Dan Wing wrote:

> > The concepts in this draft are likely relevant to most of our
> > transport protocols, and hence would be in scope for TSVWG.
> > The TSVWG
> > chairs are interested in comments on whether there is group interest
> > in this draft - please comment on tsvwg <at> ietf.org.
>
>The suggestions in this document are equally important for RTP
>so that attackers are forced to work harder to inject undesired
>content into RTP media sessions.  It would be useful if the
>document scope were expanded slightly to explicitly include RTP.
[....]

Will do.

>Even without this change, I support adopting this document as a TSVWG item.

Thanks so much!

Kindest regards,

--
Fernando Gont
e-mail: fernando <at> gont.com.ar || fgont <at> acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

sctp abort during high traffic load exchange

Re: sctp abort during high traffic load exchange

Hi Arif,

a look at the source code of the SCTP dissector tells me

#define OUT_OF_RESOURCE                            0x04

so I guess you are running out of resources. Which SCTP implementation
are you using?

Best regards
Michael

On Jun 6, 2007, at 11:50 PM, arif khan wrote:

> hi,
>
> we have around 135 multihomed assoc. and all are exchanging traffic  
> (traffic rate is high) in the mean time server sctp endpoints send  
> abort to the client sctp.
> ethereal dump ecode of cause 4.
>
> how could we check reason of abort?
> could you suggest how we can verify it over single assoc with  
> changing the rto,rtt,max path retrans or hb interval value.
>
> tia
> -arif

Re: Clarification on sctp library.

Hi Bala,

question regarding the Linux SCTP implementation should be sent to
lksctp-developers <at> lists.sourceforge.net

Regarding you questions you might want to open an sctp socket,
put it into non blocking mode via a fnctl call and call sctp_connectx().
Please note that the function has recently be extended to provide
the assoc_id via a result parameter. This has been implemented in
the FreeBSD/MacOS X implementation, but not yet in the Linux one.

Best regards
Michael

On Jun 6, 2007, at 9:20 AM, Balamurugan T, TLS-Chennai wrote:

> Hi All,
>
>      I am new to sctp protocol and need the below clarifications. I  
> have installed lksctp-tools-1.0.6 on Suse linux.
>
>       1. How to get the association id  for a successful connection.?
>       2. Is there any system call available to set a sctp socket as  
> NON_blocking.
>       3. Is it possible to call sctp_connectx from a 1-to-1 sctp  
> socket (sctp client ) to 1-to-N socket (sctp server).
>       4. How to set non-blocking on sctp server socket.
>
> Thanks in Advance,
> Bala
>
>
>
>
>
> DISCLAIMER:
> ---------------------------------------------------------------------- 
> -------------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential  
> and intended for the named recipient(s) only.
> It shall not attach any liability on the originator or HCL or its  
> affiliates. Any views or opinions presented in
> this email are solely those of the author and may not necessarily  
> reflect the opinions of HCL or its affiliates.
> Any form of reproduction, dissemination, copying, disclosure,  
> modification, distribution and / or publication of
> this message without the prior written consent of the author of  
> this e-mail is strictly prohibited. If you have
> received this email in error please delete it and notify the sender  
> immediately. Before opening any mail and
> attachments please check them for viruses and defect.
>
> ---------------------------------------------------------------------- 
> -------------------------------------------------

RE: sctp abort during high traffic load exchange

Invitation to join new unofficial IETF mailing list: re-ECN

Folks,

You are invited to subscribe to a new unofficial IETF mailing list on 
re-ECN via <https://www1.ietf.org/mailman/listinfo/re-ecn>

Re-ECN is proposed as an extension to explicit congestion notification 
(ECN) intended to enable enforcement of fairness for congestion control & 
QoS including mitigation of DDoS and prevention of cheating between both 
networks & users.

Why has this list been created?:
At the last IETF in Prague, about 30-40 people got together at an 
unofficial BoF (Birds of a Feather) to hear about the architectural intent 
of re-ECN and to discuss how to move forward.

It was decided to take an ad hoc approach initially, somewhat along the 
lines of how HIP got started. If a community hangs together around this 
work, then it may form an IRTF or IETF working group.

The room was unanimous that re-ECN addresses a problem that is interesting, 
and about 75% were interested in using it, if it was implemented. Half a 
dozen people expressed interest in implementing the protocol. Full notes, 
transcript & slides as well as background papers are at:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/#Presentations>

If interested in discussion of design and implementation of the re-ECN 
protocol, pls subscribe via the link at the start.

---------------------------------------------------------------------------
Re-ECN is not an official working group of the IETF or IRTF. But the IETF 
has agreed to host the list to create a community around this work who may 
wish to bring it forward for standardisation. As such, if you subscribe, 
you will be asked to note well the normal IETF rules.

This invitation will only be sent to relevant lists once. But apologies if 
you are on more than one of these lists.

Cheers

Bob

____________________________________________________________________________
Bob Briscoe, <bob.briscoe <at> bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196  

Re: sctp abort during high traffic load exchange

Error code 4 is "out of resources"

I'd presume that it's caused by whatever has been sent to that endpoint just
prior to the abort, or shortly before.  Looking at the traces, does that give
you any clue as to the cause of the abort?
Is the T bit set?  if not, are you trying to set up another association?

- Al Weiner -
(not an SCTP guru, but getting there...   :)

-- original message --

>hi,
>
>we have around 135 multihomed assoc. and all are exchanging traffic (traffic
>rate is high) in the mean time server sctp endpoints send abort to the
>client sctp.
>ethereal dump ecode of cause 4.
>
>how could we check reason of abort?
>could you suggest how we can verify it over single assoc with changing the
>rto,rtt,max path retrans or hb interval value.
>
>tia
>-arif

----------------------------------------------------------------------------
Alan Jay Weiner / Valid8.com, Inc. - Conform, Perform & Excel(tm)
500 W Cummings Park, Suite #2700, Woburn, MA 01801, USA
a.weiner <at> valid8.com / Tel:+1-781-938-1221 x112, Fax +1-781-207-0550
http://www.VALID8.com <http://www.valid8.com/>