Subject: Re: [Tsvwg] ICMP handling with SCTP

From: Bob Braden <[email-masked]>
Date: Fri, 21 Oct 2005 12:13:41 -0700 (PDT)

*> 
  *> But there-in lies the problem.. this is different than what
  *> RFC-1122 does.. and since it is different we have a running
  *> SHOULD/MUST debate.. that I am looking for your wisdom to
  *> help us decide..

Two points: First, in many cases the MUST/SHOULD decisions in RFC
1122,3 were a bit fluffy.  The general intent of the Host Requirements
RFCs was to stem the tide of an increasing number of sloppy or
deliberately substandard implementations of the protocols, by requiring
that every host implementation actually support (all) the protocol features.
Those features were there for a reason and had been adopted after
careful consideration.  The IETF community of that day (1988) did not
take kindly to individual host software implementors who thought they
"knew better".  But the 50 or so IETFers who contributed to the HR
RFCs had varying degrees of certainty about various features, and
that often led to backing off from MUST to SHOULD.  (Of course, there
were also cases where there were specific, carefully-considered
reasons for a MUST/SHOULD choice).  So there was a certain amount
of educated techie intuition at work here.

The second point follows from the first.  If a new transport protocol
has specific reasons for being MORE restrictive than RFC 1122, that
seems to be consonant with the general intent of RFC 1122.

I would like to point out one other feature of the HR RFCs: we tried
really hard to put down explanations for decisions, to avoid endless
future arguments.  So, it would also be in the spirit of RFC 1122 if
your documentation noted the diference and said why.  Probably 1-2
sentences are enough here; no long treatise is necessary/desirable.  (I
always liked the indented DISCUSSION paragraphs that we invented for
the HR RFCs; I think it is too bad that this documentation approach has
not been emulated by other IETF protocol specification documents.)

BTW, it seems a little strange to me to say "...following procedures
MUST be followed .." when the procedures themselves often contain MAY.
This seems like an overuse of MUST.  IETFers seem to have trouble with
this concept, but it is really OK to use the word "must" without
capitalization in an RFC!

Bob Braden

  *> 
  *> Does this case warrent being more strict on an SCTP implementation?
  *> 
  *> I think it does..
  *> 
  *> Thanks in advanced for your kind responses..
  *> ---------------------------------------------------
  *> Now.. Here is the actual text for the wg.. Note that ICMP9 and ICMP8
  *> were redundant (they were almost word-for-word identical.. so I
  *> collapsed them down).
  *> 
  *> For Brian and others.. note I put a lot of MAY's in so that
  *> the only ICMP binding thing is
  *> 1) use the data in the ICMP msg to find the assoc
  *> 2) use the Vtag to validate that the ICMP is not forged
  *> 3) treat the protocol unreachable message as an ABORT.
  *> 
  *> All others become just "MAY"
  *> 
  *> *********************************************************
  *> 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) 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
  *>         which sent the message that ICMP is responding to.
  *>         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 implemenation MAY 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" 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 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.
  *> 
  *> *************************************************************************
  *> 
  *> -- 
  *> 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: Fri, 21 Oct 2005 18:07:06 -0400

Bob:

Thanks for the response.. I really appreciate it..

A comment or two within..

> not been emulated by other IETF protocol specification documents.)

You know, I have read it several times and it never even struck me
.. maybe this would be a good way to handle this note .. I do
like the idea :-D

> capitalization in an RFC!

Well.. that is a combination of me being lazy.. and the difficulty
of finding a way to slip in the ICMP handling without being too
disruptive to the orginal document... sigh..

We really probably need to haul this into the main document that
way we don't have to have pointer from the security section to
an appendix... I agree its kinda cheezy...

Probably a whole section that introduces it.. then the
ICMP rules.. and then the 2 sentence note telling how
this difference from 1122...

R

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