summaryrefslogtreecommitdiffstats
path: root/net/dccp
diff options
context:
space:
mode:
authorVlad Yasevich <vladislav.yasevich@hp.com>2007-12-20 14:13:31 -0800
committerDavid S. Miller <davem@davemloft.net>2008-01-28 14:59:25 -0800
commitd6701191329b51793bc56724548f0863d2149c29 (patch)
tree2833f850724af85622b844d27f42e285176e2f7f /net/dccp
parent75205f478331cc64ce729ea72d3c8c1837fb59cb (diff)
downloadlinux-d6701191329b51793bc56724548f0863d2149c29.tar.gz
linux-d6701191329b51793bc56724548f0863d2149c29.tar.bz2
linux-d6701191329b51793bc56724548f0863d2149c29.zip
[SCTP]: Follow Add-IP security consideratiosn wrt INIT/INIT-ACK
The Security Considerations section of RFC 5061 has the following text: If an SCTP endpoint that supports this extension receives an INIT that indicates that the peer supports the ASCONF extension but does NOT support the [RFC4895] extension, the receiver of such an INIT MUST send an ABORT in response. Note that an implementation is allowed to silently discard such an INIT as an option as well, but under NO circumstance is an implementation allowed to proceed with the association setup by sending an INIT-ACK in response. An implementation that receives an INIT-ACK that indicates that the peer does not support the [RFC4895] extension MUST NOT send the COOKIE-ECHO to establish the association. Instead, the implementation MUST discard the INIT-ACK and report to the upper- layer user that an association cannot be established destroying the Transmission Control Block (TCB). Follow the recomendations. Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/dccp')
0 files changed, 0 insertions, 0 deletions