NAME

  ICMP_ShortPacket.seq - Handling ICMP message which is too short and Verification Tag is 0


PURPOSE

  To check the receiver silently discard ICMP message with Verification 
  Tag is 0 and not enough bytes to contains the chunk type and the 
  Initiate Tag.


SYNOPSIS

  ./ICMP_ShortPacket.seq [-tooloption ...] -pkt ./ICMP_ShortPacket.def
    -tooloption : v6eval tool option
  See Also: ../common/STD_PKT_COMMON.def
            ../common/SCTP_COMMON.def


PRE-TEST CONDITION

  Association not established between endpoint A and B. Also 
  arrange the data in endpoint B such that upper layers send 
  Associate primitive to startup an association with endpoint A.


TEST PROCEDURE

  Endpoint A                            Endpoint B             ULP
  (CLOSED)                              (CLOSED) 
  
                                                   <-----    Associate
                  <----------------       INIT
  
  ICMP            ----------------->      Silently discard
  (too short)
                  <----------------       INIT
  TEST DESCRIPTION:
  1. Attempt to terminate an association between endpoint A and endpoint 
     B by sending ICMP message which is too short.
  2. Check A: ICMP message is silently discard.
  3. Check B: INIT message is sent again after expiry of T1-Init timer.


NOTE

  None


REFERENCE

  RFC 4960
  Appendix C.  ICMP Handling
    Whenever an ICMP message is received by an SCTP endpoint, the
    following procedures MUST be followed to ensure proper utilization of
    the information being provided by layer 3.
    ICMP1) An implementation MAY ignore all ICMPv4 messages where the
           type field is not set to "Destination Unreachable".
    ICMP2) An implementation MAY ignore all ICMPv6 messages where the
           type field is not "Destination Unreachable", "Parameter
           Problem",, or "Packet Too Big".
    ICMP3) An implementation MAY ignore any ICMPv4 messages where the
           code does not indicate "Protocol Unreachable" or
           "Fragmentation Needed".
    ICMP4) An implementation MAY ignore all ICMPv6 messages of type
           "Parameter Problem" if the code is not "Unrecognized Next
           Header Type Encountered".
    ICMP5) An implementation MUST use the payload of the ICMP message (v4
           or v6) to locate the association that sent the message to
           which ICMP is responding.  If the association cannot be found,
           an implementation SHOULD ignore the ICMP message.
    ICMP6) An implementation MUST 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
           or 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", an implementation MAY process this
           information as defined for PATH MTU discovery.
    ICMP8) If the ICMP code is an "Unrecognized Next Header Type
           Encountered" or a "Protocol Unreachable", an implementation
           MUST 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 the COOKIE-WAIT state, handle
           the ICMP message like an ABORT.
    ICMP9) If the ICMPv6 code is "Destination Unreachable", the
           implementation MAY mark the destination into the unreachable
           state or alternatively increment the path error counter.
    Note that these procedures differ from [RFC1122] and from its
    requirements for processing of port-unreachable messages and the
    requirements that an implementation MUST abort associations in
    response to a "protocol unreachable" message.  Port-unreachable
    messages are not processed, since an implementation will send an
    ABORT, not a port unreachable.  The stricter handling of the
    "protocol unreachable" message is due to security concerns for hosts
    that do NOT support SCTP.