Subject: AW: [Tsvwg] ICMP issue with SCTP IG

From: "Meyknecht, Bernward" <[email-masked]>
Date: Wed, 12 Oct 2005 15:12:47 +0200

Hi all,

I'm not content with the new section on ICMP handling for the SCTP IG, incl. 
the 'MUST' for ICMP handling within an SCTP specification, and propose to replace 
it by a weaker wording and moving the section to another place.

I would of course never propose to delete the ICMP section from the IG, but for me 
it is something to be described in an appendix of the SCTP specification, as it is 
done in the actual issue 15 of the IG, without the wording 'MUST', but with 
something like '...should be followed to assure proper utilization of the information 
being provided by layer 3', which is the current wording.

Adding ICMP handling to SCTP was motivated by attack scenarios described in the 
draft draft-stewart-tsvwg-sctpthreat-03.txt, okay.
But the other enhancements being described for SCTP within the new IG section, 
i.e. amplification control, path verification (small hb.max.burst) and aborting 
when receiving an ack for an unsent TSN, etc.
these are exactlay the counter measures taken on SCTP level to prevent the 
attacks. Besides that there is a number of circumstances on which the attacks 
depend, i.e. which are necessary to allow the attack at all.
With an SCTP implementation having the SCTP enhancements as mentioned above I 
don't see the relevance of these attacks on SCTP any more.

Besides that I see ICMP as something belonging to a layer below SCTP, the SCTP 
RFC should describe only the SCTP level, hints on ICMP handling could be part
of an extra document/draft, even in a future RFC.

Kind regards,

Bernward

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Randall Stewart
Gesendet: Freitag, 7. Oktober 2005 19:00
An: Michael Tuexen
Cc: [email-masked]; [email-masked]; Vlad Yasevich; Coene, Lode; Schruefer, Wolfgang; Kacheong Poon; Scott Bradner
Betreff: Re: [Tsvwg] ICMP issue with SCTP IG

All:

In an attempt to draw this discussion and all the points
we have discussed to a close here is the text I am proposing
we add to the I-G. This I think covers all of our issues...

Our new section 11.5 now looks as follows:

*********************************************************
---------
New text
---------

11.5 Protection of non-SCTP capable hosts.

To provide non-SCTP capable host with the same level of
protection against attacks as SCTP capable ones all SCTP
stacks MUST implement the ICMP handling described in Appendix C.

When an SCTP stack receives a packet containing multiple
control or DATA chunks and the processing of the packet
requires the sending of multiple chunks in response,
the sender of the response chunk('s) MUST NOT send
more than one packet. If bundling is supported multiple
response chunks that fit into a single packet MAY be
bundled together into one single response packet. If bundling
is not supported then the sender MUST NOT send more
than one response chunk and MUST discard all other
responses. Note that this rule does NOT apply to a
SACK chunk since a SACK chunk is, in itself, a response
to DATA and a SACK does not require a response of more DATA.

An SCTP implementation SHOULD abort the association if
it receives a SACK acknowledging a TSN which has not been sent.

An SCTP implementation that receives an INIT that would
require a large packet in response, due to the inclusion
of multiple ERROR parameters, MAY (at its discrection)
elect to omit some or all of the ERROR parameters
to reduce the size of the INIT-ACK. Due to a combination
of the size of the COOKIE parameter and the number
of addresses a receiver of an INIT may be indicating
to a peer, it is always possible that the INIT-ACK will
be larger than the original INIT. An SCTP implementation
SHOULD attempt to make the INIT-ACK as small as possible
to reduce the possibility of byte amplification attacks.

*************************************************************
The ICMP section that goes with it looks as follows:
*************************************************************
---------
New text: (Appendix C)
---------

Appendix C ICMP Handling

Whenever an ICMP message is received by an SCTP endpoint the
following procedures MUST be followed to assure proper
utilization of the information being provided by layer 3.

ICMP1) Ignore all ICMPv4 messages where the type field is
        not set to "Destination Unreachable".

ICMP2) Ignore all ICMPv6 messages where the type field is
        not "Destination Unreachable, "Parameter Problem" or
        "Packet Too Big".

ICMP3) Ignore any ICMPv4 messages where the code does not
        indicate "Protocol Unreachable" or "Fragmentation Needed".

ICMP4) Ignore all ICMPv6 messages of type "Parameter Problem" if
        the code is not "Unrecognized next header type encountered".

ICMP5) Use the payload of the ICMP message (V4 or V6) to locate the
        association which sent the message that ICMP is responding to.
        If the association cannot be found, ignore the ICMP message.

ICMP6) Validate that the verification tag contained in the ICMP
        message matches the verification tag of the peer.
        If the verification tag is not 0 and does NOT match,
        discard the ICMP message. If it is 0 and the ICMP message contains
        enough bytes to verify that the chunk type is an INIT chunk
        and that the initiate tag matches the tag of the peer continue
        with ICMP7. If the ICMP message is too short, the chunk type
        or the initiate tag does not match, silently discard the packet.

ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4
        "Fragmentation Needed" process this information as defined for
        PATH MTU discovery.

ICMP8) If the ICMP code is a "Unrecognized next header type
        encountered" or a "Protocol Unreachable" treat this message
        as an abort with the T bit set if it does not contain an
        INIT chunk. If it does contain an INIT chunk and the association
        is in COOKIE-WAIT state, handle the ICMP message like an ABORT.

ICMP9) If the ICMP code is an "Unrecognized next header type
        encountered" or a "Protocol Unreachable" then the message
        MUST be treated as an abort with the T bit set, checking
        the Verification Tag in the ICMP message for validation.

ICMP10)If the ICMPv6 code is "Destination Unreachable" the
        implementation MAY mark the destination into the unreachable
        state or alternatively increment the path error counter.

*************************************************************************
The path verification procedure end up as follows:
************************************************************************
---------
New text: (Section 5.4)
---------
5.4 Path Verification

During association estabilishment the two peers
exchange a list of addresses. In the predominant case
these lists accurately represent the addresses owned
by each peer. However there exists the possibility that
a mis-behaving peer may supply addresses that it does
not own. To prevent this the following rules are applied
to all addresses of the new association:

1) Any address passed to the sender of the INIT by its
    upper layer is automatically considered to be CONFIRMED.

2) For the receiver of the COOKIE-ECHO the only CONFIRMED
    address is the one that the INIT-ACK was sent to.

3) All other addresses not covered by rules 1 and 2 are considered
    UNCONFIRMED and are subject to probing for verification.

To probe an address for verification, an endpoint will send
HEARTBEAT's including a 64 bit random nonce and a path
indicator (to identify the address that the HEARTBEAT
is sent to) within the HEARTBEAT parameter.

Upon reception of the HEARTBEAT-ACK a verification is
made that the nonce included in the HEARTBEAT parameter
is the one sent to the address indicated inside the
HEARTBEAT parameter. When this match occurs, the address
that the original HEARTBEAT was sent to is now considered
CONFIRMED and available for normal data transfer.

These probing proceedures are started when an association
moves to the ESTABLISHED state and are ended when all
paths are confirmed.

Each RTO a probe may be sent on an active UNCONFIRMED path
in an attempt to move it to to the CONFIRMED state.
If during this probing the path becomes inactive this rate
is lowered to the normal HEARTBEAT rate. At the expiration
of the RTO timer the error counter of any path that was
probed but not CONFIRMED is incremented by one and subjected
to path failure detection defined in section 8.2. When probing
UNCONFIRMED addresses, however, the association overall error count
is NOT incremented.

The number of HEARTBEATS sent at each RTO SHOULD be limited
by the HB.Max.Burst parameter. It is an implementation decision
as to how to distribute HEARTBEATS to the peers addresses
for path verification.

Whenever a path is confirmed an indication MAY be given to
to the upper layer.

An endpoint MUST NOT send any chunks to an UNCONFIRMED
address with the following exceptions:

- A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED
   address.

- A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address.

- A COOKIE-ACK MAY be sent to an UNCONFIRMED address but
   it MUST be bundled with a HEARTBEAT including a nonce.
   An implementation that does NOT support bundling MUST
   NOT send a COOKIE-ACK to an UNCONFIRMED address.

- A COOKE-ECHO MAY be sent to an UNCONFIRMED address but
   it MUST be bundled with a HEARTBEAT including a nonce
   and the packet MUST NOT exceed the path MTU. If the
   implementation does NOT support bundling or the bundled
   COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed
   the path MTU, then the implemenation MUST NOT send
   a COOKIE-ECHO to an UNCONFIRMED address.

*************************************************************
With the corresponding parameter defaults as follows:
*************************************************************
The following protocol parameters are RECOMMENDED:

RTO.Initial              - 3  seconds
RTO.Min                  - 1  second
RTO.Max                  - 60 seconds
Max.Burst                - 4
RTO.Alpha                - 1/8
RTO.Beta                 - 1/4
Valid.Cookie.Life        - 60 seconds
Association.Max.Retrans  - 10 attempts
Path.Max.Retrans         - 5  attempts (per destination address)
Max.Init.Retransmits     - 8  attempts
HB.Interval              - 30 seconds
HB.Max.Burst             - 1

****************************************************************

I think this covers all that we had talked about... the byte
amplification of INIT-ACK is mentioned/noted and I think
we should move on... Implementations can minimize there
INIT-ACK's as they deem appropriate and are now allowed
to omit errors...

Note, commens and suggested changes, as always, are most
welcome :-D

R

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

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Thu, 20 Oct 2005 07:24:02 -0400

Bernward:

I agree with Michael and Brian.. and I think
most all the other developers that have not
chimed in here objecting (I think you are
alone in objecting to the must)..

This is a MUST

R