Subject: RE: [Sigtran] Sending ABORT upon receipt of INIT-ACK

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 16 May 2007 13:26:53 -0400

Emmanuel -
 
If we send an ABORT in response to an INIT ACK, the server will receive
an ABORT for which it has no TCB.  So it seems unneccessary to state
this as a MUST requirement since the server can't really do anything
with the ABORT.
 
Regards,
Lincoln

________________________________

From: Emmanuel Mavrommatis [mailto:[email-masked]] 
Sent: Wednesday, May 16, 2007 11:51 AM
To: Haresign Lincoln
Cc: [email-masked]
Subject: Re: [Sigtran] Sending ABORT upon receipt of INIT-ACK

Hi Lincoln,

In the RFC is stated: 

If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but
decides not to establish the new association due to missing mandatory
parameters in the received INIT or INIT ACK, invalid parameter
values, or lack of local resources, it MUST respond with an ABORT
chunk.

That means "ABORT" the initiation of an association. There is not need
to be in ESTABLISH state. 

In what you quoted:

 Note: A receiver of an INIT ACK  with the MIS value set to 0
      SHOULD destroy the association discarding its TCB.

It deletes the TCB to prevent resource attacks, but must also send a
ABORT. Look on the Figure 3: State Transition Diagram of SCTP page 51. 

Regards,
Emmanuel 
- Hide quoted text -

On 5/16/07, Haresign Lincoln <[email-masked]> wrote: 

	TO whom it may concern:
	
	Section 3.3.3 of RFC 2960 states:

	      If the value of the Initiate Tag in a received INIT ACK
chunk is
	      found to be 0, the receiver MUST treat it as an error and
close
	      the association by transmitting an ABORT.
	
	I'm just curious what the thinking is regarding sending an
ABORT.  The
	server has retained no knowledge of the connection. So when it
recieves
	the ABORT, it will be considered "out of the blue".  So ...
Whats' the 
	point.  In other error scenarios for processing INIT-ACK, the
RFC
	states:
	
	      Note: A receiver of an INIT ACK  with the MIS value set to
0
	      SHOULD destroy the association discarding its TCB.
	
	This seems more appropriate.
	
	Regards,
	Lincoln

This message has been scanned for viruses by MailController
<http://www.MailController.altohiway.com/> .

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 16 May 2007 12:02:20 -0600

Lincoln,

Because such an ABORT may be blocked by firewalls for security reasons (e.g.
port scanning), the 2960bis documents downgrades the MUST to SHOULD in all
cases and permits an implementation to not send the ABORT in the scenarios
described.

--brian

Haresign Lincoln wrote:                       (Wed, 16 May 2007 13:26:53)
> 
>    Emmanuel -
> 
> 
> 
>    If  we  send  an  ABORT  in  response  to an INIT ACK, the server will
>    receive an ABORT for which it has no TCB.  So it seems unneccessary to
>    state  this  as  a  MUST  requirement since the server can't really do
>    anything with the ABORT.
> 
> 
> 
>    Regards,
>    Lincoln

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Haresign Lincoln" <[email-masked]>
Date: Wed, 16 May 2007 15:54:31 -0400

Brian,

Thanks...I did see this in the rfc4460.  I guess the server really can't
do anything with the ABORT since it doesn't have a TCB.  However, I
guess it might help in debugging in trying to determine why an
association is not coming up.

Regards,
Lincoln 

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Wednesday, May 16, 2007 2:02 PM
To: Haresign Lincoln
Cc: Emmanuel Mavrommatis; [email-masked]
Subject: Re: [Sigtran] Sending ABORT upon receipt of INIT-ACK

Lincoln,

Because such an ABORT may be blocked by firewalls for security reasons
(e.g.
port scanning), the 2960bis documents downgrades the MUST to SHOULD in
all cases and permits an implementation to not send the ABORT in the
scenarios described.

--brian

Haresign Lincoln wrote:                       (Wed, 16 May 2007
13:26:53)

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/