On 02/19/2011 10:07 PM, Shan Wei wrote: > > Hi vald: > > Vladislav Yasevich wrote, at 02/18/2011 10:43 PM: >> Hi Jiri >> >> I agree. Good catch. If we can not add the error header to that packet, then we definitely >> should not be adding the error payload either. > > I also agree this part. > >> We also don't want to abort as Shan Wei suggested. It is allowed, when exceeding the MTU to >> drop errors that would not otherwise fit into the packet. It just may so happen that we >> can report subsequent unknown parameters, but not this one in particular. > > RFC said that about Parameter Types' encode: > 3.2.1. Optional/Variable-Length Parameter Format > 11 - Skip this parameter and continue processing but report the > unrecognized parameter in an 'Unrecognized Parameter', as > described in Section 3.2.2. > > and > > 3.2.2. Reporting of Unrecognized Parameters > > If the receiver of an INIT chunk detects unrecognized parameters and > *has to* report them according to Section 3.2.1, it MUST put the > 'Unrecognized Parameter' parameter(s) in the INIT ACK chunk sent in > response to the INIT chunk. > > So, For unrecognized parameter can't fit into the packet, so droping the parameter. > This may not be consistent with the RFC. > > If i have missed something, please tell me. Thanks. > See Secton 11.4. Specifically: 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 discretion) 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. -vlad >> >> Acked-by: Vlad Yasevich <vladislav.yasevich@xxxxxx> >> >> -vlad >> >> >> >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
