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

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

Hello Michael, Randy,

I agree to the harmonization with RFC 1122 (a good point) and to this proposal, 
i.e. changing the ICMP9 and making the implementation note on not processig 
an ICMP(port unreachable).
With that change, the text for section 11.5 would be fine and I like it.

Kind regards,
Bernward

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

Randy,

in general I like the text you submitted. But I think it
might be good to have the SCTP procedure in tune with the
ones described in RFC 1122 (Host Requirements).

Section 3.2.2.1 of RFC 1122 states
             A host SHOULD generate Destination Unreachable messages  
with
             code:

             2    (Protocol Unreachable), when the designated transport
                  protocol is not supported;

             A Destination Unreachable message that is received MUST be
             reported to the transport layer.  The transport layer  
SHOULD
             use the information appropriately; for example, see  
Sections
             4.1.3.3, 4.2.3.9, and 4.2.4 below.

and section 4.2.3.9 states (for TCP)

             o    Destination Unreachable -- codes 2-4

                  These are hard error conditions, so TCP SHOULD abort
                  the connection.

So I think to harmonize the future SCTP RFC with RFC 1122, we should  
change

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.

to

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

Furthermore RFC 1122 states in section 3.2.2.1

             A transport protocol
             that has its own mechanism for notifying the sender that a
             port is unreachable (e.g., TCP, which sends RST segments)
             MUST nevertheless accept an ICMP Port Unreachable for the
             same purpose.

This covers SCTP too. So we should either add this rule to the ICMP  
processing
rules or make an Implementation Note that we do not require an SCTP  
implementation
to do it. I would prefer the second, because either the receiver of  
an INIT supports
SCTP and sends back an ABORT or does not support SCTP and sends back an
ICMP(protocol unreachable). So an ICMP(port unreachable) should never  
be generated.
So I would like to make an explicit statement, that an SCTP  
implementation SHOULD
not process an ICMP(port unreachable).

What do you and others think?

Best regards
Michael

On Oct 7, 2005, at 7:00 PM, Randall Stewart wrote:

> 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