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

From: Randall Stewart <[email-masked]>
Date: Fri, 07 Oct 2005 13:00:07 -0400

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 Oct 2005 16:32:16 -0600

Randall,

> Our new section 11.5 now looks as follows:

I think this is too broad.  The Appendix is full of procedures
for ignoring ICMP messages.  I do not see how ignoring ICMP messages
ever protects a non-SCTP capable host.  Can this MUST be restricted
to only those procedures in Appendix C that actually protect non-SCTP
capable hosts?  That is... hey! Where in the Appendix C below does it
even say to stop on Protocol Unrechable?  I can't find it there.

> to reduce the possibility of byte amplification attacks.

Yes, this text is excellent.

Above sounds good.

> UNCONFIRMED addresses, however, the association overall error count

Why not increment the association error count?  Do we not want
the association with bogus addresses in it to fail just as quickly
as the one with all good addresses?  I think the reverse might be
desirable: that is to peg failures of unconfirmed addresses against
the association at a faster rate (say double).  I don't see any
problem with applying the same policy with regard to association
error peg counts to both confirmed and unconfirmed addresses.

>    a COOKIE-ECHO to an UNCONFIRMED address.

We need to be able to send COOKIE-ACK,SACK,DATA in response to
COOKIE-ECHO,DATA,[DATA].  Can we make this COOKIE-ACK,HB[nonce],
SACK,DATA,[DATA] to unverified addresses.

Overall very good.  Thank you for your wordsmithing efforts.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 12 Oct 2005 21:43:21 +0200

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

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 Oct 2005 17:32:13 -0600

Michael,

> What do you and others think?

Could not an ICMP(port unreachable) be generated by a middlebox or
firewall (i.e. port proxy).

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 13 Oct 2005 09:47:28 +0200

Hi Brian,

see my comment in-line.

Best regards
Michael

> firewall (i.e. port proxy).
Any reason it can not generate an ABORT? Since it decided that
the port is unreachable, it must have looked at the INIT. So it
knows SCTP.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Oct 2005 02:11:13 -0600

Michael,

> the port is unreachable, it must have looked at the INIT. So it

Well, we allowed ABORTs to be suppressed, didn't we?

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 13 Oct 2005 19:31:13 +0200

Brian,

see my comment in-line.

Best regards
Michael

On Oct 13, 2005, at 10:11 AM, Brian F. G. Bidulock wrote:

>>>> SCTP and sends back an ABORT or does not support SCTP and sends  
>>>> back
>>>> an
Yes. And I think if you do not want to see ABORTs you do not
want to see ICMP(port unreachable).

If an endpoint/middlebox want to say that a particular port number
is not reachable it should use ABORT instead of ICMP(port unreachable).

I think the ICMP(port unreachable) for TCP is there for historic  
reasons,
so it does not apply for SCTP. But possibly someone with better  
knowledge
can jump in here and tell us why an TCP implementation has to support
ICMP(port unreachable). If it has a reason in addition to the  
historic one,
it may also apply to SCTP and we have to adopt the text accordingly.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Oct 2005 12:05:47 -0600

Michael,

> want to see ICMP(port unreachable).

Maybe, maybe not.  But I don't think that they MUST be ignored.  I
think they MAY be ignored.

> is not reachable it should use ABORT instead of ICMP(port unreachable).

I don't think the SCTP specification (transport) should place requirements
on what the network layer should or should not send.

---

From: Randall Stewart <[email-masked]>
Date: Thu, 13 Oct 2005 17:02:34 -0400

> on what the network layer should or should not send.

I think the router requirments document already does this.. and I
don't remember anything in the I-G that requires a middlebox
to send anything.. if there is please point it out to me since
we should get rid of it..

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 13 Oct 2005 16:54:08 -0600

Randall,

> we should get rid of it..

No there was nothing in the document...  Michael was arguing, I believe,
that a non-SCTP aware host or router would not generate ICMP(port
unreachable), but rather generate ICMP(prototcol unreachable), and an
SCTP aware host or router would generate ABORT instead of ICMP(port
unreachable), and concluding that ICMP(port unreachable) should be
ignored when received by an SCTP capable node.

My point was that the I-G does not (and should not) dictate when
ICMP(port unreachable) is to be sent, or for what reasons.  That is,
indeed, up to the router requirements RFC to dictate.

An SCTP implementation receiving ICMP(port unreachable) should not be
required by the uncomping SCTP RFC to discard the messages, as in
accordance with the router requirements, they may indicate to the
sending SCTP that it can take action with regard to an association
in the absense of an ABORT that the router is no longer required to
send.

Perhaps the receiving SCTP host should indeed process ICMP(port
unreachable) rather than being required to discard it as Michael
originally proposed.

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 14 Oct 2005 16:58:30 +0200

Dear all,

my point is just to harmonize RFC 1122, Host Requirements, and the  
future
SCTP specification.

RFC 1122 states:
- An endpoint SHOULD delete the association on reception of an
   ICMP(protocol unreachable).
- An endpoint MUST process an ICMP(port unreachable) like an
   ABORT.

The first would require a change from MUST to SHOULD as indicated
in my original mail. Currently the IG says that you must ignore
ICMP(port unreachable). I do not want to change anything regarding
the sending of this ICMP message, I'm only wondering if we should also
change the IG or (what I would prefer) to not change the IG on the
ICMP(port unreachable) processing and stating that this is a difference
to RFC 1122.

Best regards
Michael

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 14 Oct 2005 15:04:47 -0600

Michael,

I would prefer if any necessary changes were made in RFC 1122.  That is
under the same WG is it not?

--brian

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 15 Oct 2005 00:24:32 +0200

Brian,

as far as I know there is noone working on a new version of RFC 1122.  
And
I do not see, that it is necessary.
So what do you think about the text I suggested?

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Thu, 20 Oct 2005 07:16:18 -0400

> even say to stop on Protocol Unrechable?  I can't find it there.

Let me see if I can first and formost of all tweak the wording
in the appendix for the throw aways to be "may" or "should"..

as to the question..

ICMP8 says:
"
    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.
"

So I think that covers it... But you are right in that
we need to tweak things just a bit so that only things
like ICMP8 are a MUST and the other things, such as
ICMP1:
"
    ICMP1) Ignore all ICMPv4 messages where the type field is
           not set to "Destination Unreachable".
"

One MAY do.. but does not have to..

> error peg counts to both confirmed and unconfirmed addresses.

If you peg the association error counter as well .. you have
a situation that may cause you to fail the association for a
good guy..

Consider:
E-A                                      E-Z

--SRC-IP1:INIT(IP1, IP2, IP3, IP4, IP5, IP6)------->

....association comes up....

** IP2-6 are down.. maybe there Inet provider
    is broken or down..

So, now E-Z starts to do 1 per RTO+jitter
verification, and E-A's app has sent a request
to compute pie to the Nth place and return the
result or some such thing that means there will
be no result for some time... so there is
no data to send for say 2minutes before the
server on E-Z responds...

-----IP-1:COOKE-ECHO+DATA---------->
<-------IP-1:COOKIE-ACK+SACK-------
IP-2<-----HB+N------
RTO
IP-3<-----HB+N------
RTO
IP-4<-----HB+N------
RTO
IP-5<-----HB+N------
RTO
IP-6<-----HB+N------
RTO
IP-2<-----HB+N------
RTO
IP-3<-----HB+N------
RTO
IP-4<-----HB+N------
RTO
IP-5<-----HB+N------
RTO

What will happen is our valid peer.. with valid address may not
be able to get a HB to IP-1, due to the timing.. and thus
the association fails...

If the guy is an attacker, there is a good chance someone
will send back an ICMP or ABORT to tear the association..

I don't think it is worth having a valid scenario that will
tear apart the association when it should not... that is
why I put the restriction in (note I did see this behavior
in testing at one point... of course that was with
HB.Max.Burst set at 4... which just emphasises a
problem .. even at 1 you could hit this...)

> SACK,DATA,[DATA] to unverified addresses.

But if we do this we are doing byte amplification...
Adding 4 bytes to a HB+nonce (the cookie-ack) is not
much of an amplification.. but the minute you start
allowing DATA to be added you WILL get cases of
amplification.. which we are trying to prevent..

I think just a CA+HB-nonce... will

a) prevent amplification
and
b) Still allow at least 2 address to get verified
    quickly.. and the rest can go through the normal
    verification process...

> Overall very good.  Thank you for your wordsmithing efforts.

I will attempt to get these final changes in today.. and run
it by the list... (the ICMP tweaks).. I also have a couple of
other emails highlighted... that I want to get through..

I would like to have this all wrappped up and submitted before
the cutoff on Monday.. which means I must be done Sunday :-0

R

---

From: Randall Stewart <[email-masked]>
Date: Thu, 20 Oct 2005 07:27:09 -0400

Michael:

I agree with you.. I will see if I cannot
incorporate your suggestions in this next
draft I put on the list..

R

Michael Tuexen wrote:
>             A host SHOULD generate Destination Unreachable messages  with
>             code:
> 
>             reported to the transport layer.  The transport layer  SHOULD
>             use the information appropriately; for example, see  Sections
> to do it. I would prefer the second, because either the receiver of  an 
> INIT supports
>> ********************************************************************** **
>> ---------
>> New text: (Section 5.4)
>> ---------
>> 5.4 Path Verification
>>

---

From: Randall Stewart <[email-masked]>
Date: Thu, 20 Oct 2005 07:30:09 -0400

> ignored when received by an SCTP capable node.

ahh..
> indeed, up to the router requirements RFC to dictate.

I agree.. the router requirements and I think to a lesser degree
host requirements already covers port unreachable...
> unreachable) rather than being required to discard it as Michael

hmm.. that is a good point... but I wonder in reality how many
port-unreachable messages are ever generated... for tcp I bet
most send back a RST..

But no matter.. it does not hurt to have the processing in
place for this.. since we CAN verify the V-tag ...

R

---

From: Randall Stewart <[email-masked]>
Date: Thu, 20 Oct 2005 07:32:56 -0400

Michael:

I have heard Fred Baker discuss the making of both requirements
documents... and if I remember his phrasing right.. " it was
a magic moment that cannot now be duplicated"..

And I think he is right.. I would very much doubt we will ever
see the requirments documents ever opened up.. if you think
SCTPbis is tough.. I can't even imagine how hard a host
or router requirements bis would be.. :-)

R

Michael Tuexen wrote:
> Brian,
> 
> as far as I know there is noone working on a new version of RFC 1122.  And

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 20 Oct 2005 17:33:59 -0600

Randall,

I'll conceded DATA with COOKIE-ACK.  If the receiver of the COOKIE-ECHO
needs to send DATA with COOKIE-ACK, I suppose it will just have to be
to the origin of the COOKIE-ECHO (the only verified address).

The others were handled by your new text, except the last one.

Why would an association need to persist more at initialization and
verification than it does during normal operation?  I still don't see
why we would not peg error counts just because we are verifying.  If
we sent simply HEARTBEATs (which I understand some implementations do
of the bat anyway) we would peg counts.  If we were sending HEARTBEATS
due to inactivity, we should peg counts.

Also, if the user does not wish associations brought down when only,
say, 5 out of 6 destinations are unreachable, why did they set the
path max retrans and association max retrans to do so?  And if the
user sets them to fail the association when 5 out of 6 destinations
are unreachable, why would we not do so regardless of whether it is
the normal or verification phases?

--brian