[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

error messages and silently discarding packets

Hi,
one issue that was brought by Iljitsch in his review is about error messages in shim6 and silently discarding packets 

The issue is two folded:

First, shim6 protocol sends a error message in the following situations:
- when a node receives a critical option that is not recognized. In order to do that, it sends an an ICMP parameter problem (type 4, code 1), with the Pointer referencing the first octet in the option Type field. - when the verification method in the locator list option is not supported, then the host MUST ignore the Locator List and the message in which it is contained, and the host SHOULD generates an ICMP parameter problem (type 4, code 0), with the Pointer referencing the octet in the Verification method that was found inconsistent. - when a node receives a I1 packet and it doesn't support the shim6 protocol, it sends a ICMP error with "Unrecognized Next Header" type (type 4, code 1) - If the Update message contains a Locator Preference option, then the Generation number in the preference option is compared with the peer generation number in the context. If they do not match, then the host generates an ICMP parameter problem (type 4, code 0) with the Pointer field referring to the first octet in the Generation number in the Locator Preference option. In addition, if the number of elements in the Locator Preference option does not match the number of locators in Ls(peer), then an ICMP parameter problem is sent with the Pointer referring to the first octet of the Length field in the Locator Preference option. In both cases of failures, no further processing is performed for the Locator Update message. - If a node receives a packet that contains a shim message type which is unknown to the receiver, then an ICMPv6 Parameter Problem error is generated and sent back. The pointer field in the Parameter Problem is set to point at the first octet of the shim message type. The error is rate limited just like other ICMP errors [5].
The question is whether we should use ICMP error message or if we should define a shim6 error message within the shim6 protocol
Iljitsch suggested we do define such an error message, while the current spec uses ICMP error messages, what should we do? 

Second, about silently discarding packets:
there are quite a few situations that the shim6 protocol silently discard packets that it considers an error or are not supported. 

Those include:
- receiving I1, R1, I2, R2, R1bis, I2bis, Update request, Update ack, packets with less than 16 bytes or that do not comply with validity checks specified in section 12.2 (included below for your convenience :-)
- receiving a R1 packet that does not match to any context in I1-SENT state (not matching any requested context)
- receiving an I2 packet and that at least one of the following verifications fail 
   Next the host verifies that the Responder Nonce is a recent one
   (Nonces that are no older than VALIDATOR_MIN_LIFETIME SHOULD be
   considered recent), and that the Responder Validator option matches
   the validator the host would have computed for the ULID, locators,
   responder nonce, and FII.

   If a CGA Parameter Data Structure (PDS) is included in the message,
   then the host MUST verify if the actual PDS contained in the message
   corresponds to the ULID(peer).

- receiving an I2 message and the folloiwng situations occur
  situation 1
      If the state is I1-SENT, then the host verifies if the source
      locator is included in Ls(peer) or, it is included in the Locator
      List contained in the the I2 message and the HBA/CGA verification
      for this specific locator is successful

      *  If this is not the case, then the message is silently discarded
         and the context state remains unchanged.
  situation 2
      If the state is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the host
      verifies if the source locator is included in Ls(peer) or, it is
      included in the Locator List contained in the the I2 message and
      the HBA/CGA verification for this specific locator is successful

      *  If this is not the case, then the message is silently discarded
         and the context state remains unchanged.

- receiving an R2 message and one of the following situations occur
   Upon the reception of an R2 message, the host extracts the Initiator
   Nonce and the Locator Pair from the message (the latter from the
   source and destination fields in the IPv6 header).  Next the host
   looks for an existing context which matches the Initiator Nonce and
   where the locators are Lp(peer) and Lp(local), respectively.  Based
   on the state:

   o  If no such context is found, i.e., the state is IDLE, then the
      message is silently dropped.

   o  If state is I1-SENT, I2-SENT, or I2BIS-SENT then the host performs
      the following actions: If a CGA Parameter Data Structure (PDS) is
      included in the message, then the host MUST verify that the actual
      PDS contained in the message corresponds to the ULID(peer) as
      specified in Section 7.2.  If the verification fails, then the
      message is silently dropped.

   o  If the state is ESTABLISHED, the R2 message is silently ignored,
      (since this is likely to be a reply to a retransmitted I2
      message).

- receiving an R1 bis in the following situations

   Upon the reception of an R1bis message, the host extracts the Packet
   Context Tag and the Locator Pair from the message (the latter from
   the source and destination fields in the IPv6 header).  Next the host
   looks for an existing context where the Packet Context Tag matches
   CT(peer) and where the locators match Lp(peer) and Lp(local),
   respectively.

   o  If no such context is not found, i.e., the state is IDLE, then the
      R1bis message is silently discarded.

   o  If the state is I1-SENT, I2-SENT, or I2BIS-SENT, then the R1bis
      message is silently discarded.

- receiving an I2 bis message and the following situation occurs

  situation 1: one of the following verifications fail
   Next the host verifies that the Responder Nonce is a recent one
   (Nonces that are no older than VALIDATOR_MIN_LIFETIME SHOULD be
   considered recent), and that the Responder Validator option matches
   the validator the host would have computed for the ULID, locators,
   responder nonce, and FII as part of sending an R1bis message.

   If a CGA Parameter Data Structure (PDS) is included in the message,
   then the host MUST verify if the actual PDS contained in the message
   corresponds to the ULID(peer).

   situation 2
   o  If the state is I1-SENT, then the host verifies if the source
      locator is included in Ls(peer) or, it is included in the Locator
      List contained in the the I2 message and the HBA/CGA verification
      for this specific locator is successful

      *  If this is not the case, then the message is silently
         discarded.  The the context state remains unchanged.

   situation 3
   If the state is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the host
      verifies if the source locator is included in Ls(peer) or, it is
      included in the Locator List contained in the the I2 message and
      the HBA/CGA verification for this specific locator is successful

      *  If this is not the case, then the message is silently
         discarded.  The the context state remains unchanged.

- when receiving an Update ACK
  Any Update Acknowledgement which doesn't match the current request
   nonce, for instance an acknowledgement for the abandoned Update
   Request, will be silently ignored.

- when receiving an UPDATE request message and
   If a CGA Parameter Data Structure (PDS) is included in the message,
   then the host MUST verify if the actual PDS contained in the packet
   corresponds to the ULID(peer).  If this verification fails, the
   message is silently discarded.
So the question is whether people think that it is ok to silently discard in the above situations or we should send some erro message back. If the second option, please let me know in which situations you think we should sent an error message and which one 

Thanks, marcelo

PS: Section 12.2 is included next

12.2.  Receiving Shim Control messages

   A shim control message has the checksum field verified.  The Shim
   header length field is also verified against the length of the IPv6
   packet to make sure that the shim message doesn't claim to end past
   the end of the IPv6 packet.  Finally, it checks that the neither the
   IPv6 destination field nor the IPv6 source field is a multicast
   address.  If any of those checks fail, the packet is silently
   dropped.

   The message is then dispatched based on the shim message type.  Each
   message type is then processed as described elsewhere in this
   document.  If the packet contains a shim message type which is
   unknown to the receiver, then an ICMPv6 Parameter Problem error is
   generated and sent back.  The pointer field in the Parameter Problem
   is set to point at the first octet of the shim message type.  The
   error is rate limited just like other ICMP errors [5].

   All the control messages can contain any options with C=0.  If there
   is any option in the message with C=1 that isn't known to the host,
   then the host MUST send an ICMPv6 Parameter Problem, with the Pointer
   field referencing the first octet of the Option Type.