Subject: [Tsvwg] SCTP PAD chunk ordering issues

From: Mark Butler <[email-masked]>
Date: Fri, 14 Apr 2006 14:49:25 -0600

A couple of comments:

Aborting due to protocol violation just because it is a violation is 
enormously counterproductive, and contrary to the principle of being 
exacting in what you send and forgiving in what you accept.   Suppose 
one needs to communicate in an emergency situation, and the two 
endpoints refuse to speak to each other simply due to minor protocol 
inconsistencies - not problems of the type that would keep 
communications from occuring at all, but simple technicalities.  Dumping 
a connection under such circumstances is positively dangerous.

Valid reasons for not tolerating a protocol violation (on my view) are:

  a) Security considerations
  b) Resource constraints
  c) Implementation complexity
  d) Other undesirable side effects

On this principle, it is perfectly rational for a a specification to 
have different requirements for what a implementation sends, and what an 
implementation receives.  Short of explicit negotation, changing the 
send ordering constraints is not a good idea (even if RFC2960 
specification is silent or ambiguous about the control / data status of 
unknown chunk types).  However, recommending that implementions accept 
packets with chunks that are not in the proper order is an independent 
question. 

Sysctl variables are not necessarily for this kind of stuff, just a 
common sense implementation of the "be exact with what you send / 
forgiving in what you receive" principle.

 - Mark B.

---

From: Randall Stewart <[email-masked]>
Date: Sat, 15 Apr 2006 18:05:17 -0400

Mark:

Lixia once told me that 90% of the time whatever
the default behavior is that is what will occur, so
pick your defaults carefully..

This is exactly why I plan on allowing control
to be interspersed with data (in a future BSD
version... right now any such control would
cause a KAME-BSD implementation to just STOP processing
the packet)... but I will skip the control (since it
is in violation of the RFC).. this does not make
the two endpoints non-interoperable.. but may well
degrade performance.. in fact even current behavior
will not make the implementations inter-operable.. but
it will surely degrade performance since the data
chunks past the mixed up control would be dropped...
thus causing a "loss".

I will give the sysadmin the option of being completely
liberal.. or being very conservative... since there will
be sysadmin's that want to be liberal.. and there WILL
be those (especially in private networks with stricter
requirments) want to be more strict...aka aborting when
you do something wrong...

Using sysctl's to influence behavior in a BSD stack has
been a long accepted mechanism.. for example right now
for TCP in 7.x FreeBSD I have many controls.. here
are just a few:
-----------------------------
net.inet.tcp.syncookies: 1
net.inet.tcp.do_tcpdrain: 1
net.inet.tcp.rfc3042: 1
net.inet.tcp.rfc3390: 1
net.inet.tcp.local_slowstart_flightsize: 4
net.inet.tcp.newreno: 1
net.inet.tcp.sack.enable: 1
net.inet.tcp.icmp_may_rst: 1
net.inet.tcp.hostcache.purge: 0
net.inet.tcp.log_in_vain: 0
net.inet.tcp.blackhole: 0
net.inet.tcp.delayed_ack: 1
-------------------------------

There are actually to many to comfortably put in an email
more than I actually thought :-D

The point is these influence both a) Options and b) security
considerations of the admin.

This is exactly why I plan on putting my little sysctl
in when I get around to fixing this issue in BSD... since
right now it is broken :-<

R

-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)