ip_conntrack_proto_sctp INIT_ACK messages dropped

ip_conntrack_proto_sctp INIT_ACK messages dropped

[Ariel Rosenblatt]

Hello,

I have run into a problem using the sctp conntrack module.

When an association is terminated without a proper SHUTDOWN it is not
possible to re-establish the same association. The SCTP endpoint will send
an INIT message in the original direction to trying to re-establish the
association. However, the INIT_ACK message will be dropped, preventing the
association from becoming established.

The following patch solves the problem, the INIT "init_tag" is now saved
properly for an ESTABLISHED sctp association. The "init_tag" (of an INIT
message) wasn't being saved in the proper direction, causing the INIT_ACK to
be dropped while verifying the tag ("vtag") at the beginning of
sctp_packet().

I believe this should be the behavior as per RFC 2960, Section 5.2.2.

Cheers,

- Ariel

--- /usr/src/linux-2.6.10/net/ipv4/netfilter/ip_conntrack_proto_sctp.c
2005-02-04 16:22:24.000000000 -0500
+++ ip_conntrack_proto_sctp.c   2005-02-07 13:59:19.049791784 -0500
@@ -401,7 +401,11 @@
                        }
                        DEBUGP("Setting vtag %x for dir %d\n", 
                                        ih->init_tag, CTINFO2DIR(ctinfo));
-                       conntrack->proto.sctp.vtag[IP_CT_DIR_ORIGINAL] =
ih->init_tag;
+                       if (sch->type == SCTP_CID_INIT_ACK) {
+
conntrack->proto.sctp.vtag[IP_CT_DIR_ORIGINAL] = ih->init_tag;
+                       } else {
+                               conntrack->proto.sctp.vtag[IP_CT_DIR_REPLY]
= ih->init_tag;
+                       }
                    }   
 
                    conntrack->proto.sctp.state = newconntrack;
---

ip_conntrack_proto_sctp INIT_ACK messages dropped

[Ariel Rosenblatt]

Hello,

I have run into a problem using the sctp conntrack module.

When an association is terminated without a proper SHUTDOWN, it is not
possible to re-establish the same association. The SCTP endpoint will send
an INIT message in the original direction trying to re-establish the
association. However, the INIT_ACK message will be dropped, preventing the
association from becoming established.

The following patch seems to solve the problem, the INIT "init_tag" is now
saved properly for an ESTABLISHED sctp association. The "init_tag" (of an
INIT message) wasn't being saved in the proper direction, causing the
INIT_ACK to be dropped while verifying the tag ("vtag") at the beginning of
sctp_packet().

I believe this should be the behavior as per RFC 2960, Section 5.2.2.

Cheers,

- Ariel

--- /usr/src/linux-2.6.10/net/ipv4/netfilter/ip_conntrack_proto_sctp.c
2005-02-04 16:22:24.000000000 -0500
+++ ip_conntrack_proto_sctp.c   2005-02-07 13:59:19.049791784 -0500 @@
-401,7 +401,11 @@
                        }
                        DEBUGP("Setting vtag %x for dir %d\n", 
                                        ih->init_tag, CTINFO2DIR(ctinfo));
-                       conntrack->proto.sctp.vtag[IP_CT_DIR_ORIGINAL] =
ih->init_tag;
+                       if (sch->type == SCTP_CID_INIT_ACK) {
+
conntrack->proto.sctp.vtag[IP_CT_DIR_ORIGINAL] = ih->init_tag;
+                       } else {
+                               conntrack->proto.sctp.vtag[IP_CT_DIR_REPLY]
= ih->init_tag;
+                       }
                    }   
 
                    conntrack->proto.sctp.state = newconntrack;
---

Re: ip_conntrack_proto_sctp INIT_ACK messages droppedg

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

On Tue, Feb 08, 2005 at 07:37:22AM -0500, Ariel Rosenblatt wrote:
> The following patch seems to solve the problem, the INIT "init_tag" is now
> saved properly for an ESTABLISHED sctp association. The "init_tag" (of an
> INIT message) wasn't being saved in the proper direction, causing the
> INIT_ACK to be dropped while verifying the tag ("vtag") at the beginning of
> sctp_packet().

Thanks for your patch.  Patrick, would you please include the patch with
your next patches to davem?

> Cheers,
> - Ariel

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: ip_conntrack_proto_sctp INIT_ACK messages droppedg

[Patrick McHardy]

Harald Welte wrote:

>On Tue, Feb 08, 2005 at 07:37:22AM -0500, Ariel Rosenblatt wrote:
>
>>The following patch seems to solve the problem, the INIT "init_tag" is now
>>saved properly for an ESTABLISHED sctp association. The "init_tag" (of an
>>INIT message) wasn't being saved in the proper direction, causing the
>>INIT_ACK to be dropped while verifying the tag ("vtag") at the beginning of
>>sctp_packet().
>>
>
>Thanks for your patch.  Patrick, would you please include the patch with
>your next patches to davem?
>
Are you sure it is correct ? RFC2960 §5.2.2-5.2.4 talks about how to handle
unexpected INIT and INIT_ACKs. It says:

   After sending out the INIT ACK, the endpoint shall take no further
   actions, i.e., the existing association, including its current state,
   and the corresponding TCB MUST NOT be changed.

I sounds to me like we can translate this to "the conntrack must not change".

Regards
Patrick

RE: ip_conntrack_proto_sctp INIT_ACK messages dropped

[Ariel Rosenblatt]

Hello Patrick,

That is true, the conntrack must not change after the INIT_ACK is sent, and
as matter of fact once the endpoint sent the INIT_ACK it should do nothing
else to avoid DOS attacks; this until the 4-way cookie based handshake is
done and the TCB created. The COOKIE ECHO for an existing TCB case is
handled in 5.2.4, the special case I brought up is 5.2.4.A (Association
restart, 5.2.4.1).

The endpoint receiving the INIT_ACK is the "other" endpoint. So if the tag
was not properly saved when the INIT message left the originating endpoint
the INIT_ACK generated as a reply to the unexpected INIT will get dropped at
the INIT originating endpoint.

Note that the INIT_ACK is _NOT_ unexpected as the originating endpoint
previously sent an INIT (unexpected INIT_ACKs should always be discarded,
section 5.2.3), without the patch the INIT_ACK is being silently discarded.
The patch saves the initialization tag for the outgoing INIT, which will be
needed later to verify the incoming INIT_ACK. Without this a lost
association (e.g. power failure) can never be re-established before the
ESTABLISHED_TIMEOUT (currently set to 5 days) expires.

It is the destination endpoint that receives an unexpected INIT and it is
therefore bound to reply with an INIT_ACK, to get the 4-way handshake going
(section 5.2.2). However, as I mentioned above, the destination endpoint
shouldn't modify the existing association TCB or create a new one, otherwise
the destination endpoint will be vulnerable to DOS attacks.

I hope this makes sense...

Cheers,

- Ariel

-----Original Message-----
From: Patrick McHardy [mailto:kaber@trash.net] 
Sent: Tuesday, February 15, 2005 11:09 AM
To: Harald Welte
Cc: Ariel Rosenblatt; netfilter-devel@lists.netfilter.org
Subject: Re: ip_conntrack_proto_sctp INIT_ACK messages droppedg

Harald Welte wrote:

>On Tue, Feb 08, 2005 at 07:37:22AM -0500, Ariel Rosenblatt wrote:
>
>>The following patch seems to solve the problem, the INIT "init_tag" is now
>>saved properly for an ESTABLISHED sctp association. The "init_tag" (of an
>>INIT message) wasn't being saved in the proper direction, causing the
>>INIT_ACK to be dropped while verifying the tag ("vtag") at the beginning
of
>>sctp_packet().
>>
>
>Thanks for your patch.  Patrick, would you please include the patch with
>your next patches to davem?
>
Are you sure it is correct ? RFC2960 §5.2.2-5.2.4 talks about how to handle
unexpected INIT and INIT_ACKs. It says:

   After sending out the INIT ACK, the endpoint shall take no further
   actions, i.e., the existing association, including its current state,
   and the corresponding TCB MUST NOT be changed.

I sounds to me like we can translate this to "the conntrack must not
change".

Regards
Patrick

Re: ip_conntrack_proto_sctp INIT_ACK messages dropped

[Patrick McHardy]

Ariel Rosenblatt wrote:

>Hello Patrick,
>
>That is true, the conntrack must not change after the INIT_ACK is sent, and
>as matter of fact once the endpoint sent the INIT_ACK it should do nothing
>else to avoid DOS attacks; this until the 4-way cookie based handshake is
>done and the TCB created. The COOKIE ECHO for an existing TCB case is
>handled in 5.2.4, the special case I brought up is 5.2.4.A (Association
>restart, 5.2.4.1).
>
>The endpoint receiving the INIT_ACK is the "other" endpoint. So if the tag
>was not properly saved when the INIT message left the originating endpoint
>the INIT_ACK generated as a reply to the unexpected INIT will get dropped at
>the INIT originating endpoint.
>
>Note that the INIT_ACK is _NOT_ unexpected as the originating endpoint
>previously sent an INIT (unexpected INIT_ACKs should always be discarded,
>section 5.2.3), without the patch the INIT_ACK is being silently discarded.
>The patch saves the initialization tag for the outgoing INIT, which will be
>needed later to verify the incoming INIT_ACK. Without this a lost
>association (e.g. power failure) can never be re-established before the
>ESTABLISHED_TIMEOUT (currently set to 5 days) expires.
>
>It is the destination endpoint that receives an unexpected INIT and it is
>therefore bound to reply with an INIT_ACK, to get the 4-way handshake going
>(section 5.2.2). However, as I mentioned above, the destination endpoint
>shouldn't modify the existing association TCB or create a new one, otherwise
>the destination endpoint will be vulnerable to DOS attacks.
>  
>
As is conntrack if it modifies the saved tag of an established connection
without looking for a valid exchange of Tie-Tags and COOKIE-ECHO, if I don't
completely misunderstand. Someone simply needs to send an INIT for an 
existing
association and can prevent further packets from getting through. But I 
think
you're patch is what is intended by the code, so we probably should put 
it in
for now. Kiran, could you have a look at Ariel's patch please ?

Thanks,
Patrick

RE: ip_conntrack_proto_sctp INIT_ACK messages dropped

[Ariel Rosenblatt]

> -----Original Message-----
> From: Patrick McHardy [mailto:kaber@trash.net]
> Sent: Thursday, February 17, 2005 7:51 PM
> To: Ariel Rosenblatt
> Cc: 'Harald Welte'; netfilter-devel@lists.netfilter.org; Kiran Kumar
> Immidi
> Subject: Re: ip_conntrack_proto_sctp INIT_ACK messages dropped
> 
> Ariel Rosenblatt wrote:
> 
> >Hello Patrick,
> >
> >That is true, the conntrack must not change after the INIT_ACK is sent,
> and
> >as matter of fact once the endpoint sent the INIT_ACK it should do
> nothing
> >else to avoid DOS attacks; this until the 4-way cookie based handshake is
> >done and the TCB created. The COOKIE ECHO for an existing TCB case is
> >handled in 5.2.4, the special case I brought up is 5.2.4.A (Association
> >restart, 5.2.4.1).
> >
> >The endpoint receiving the INIT_ACK is the "other" endpoint. So if the
> tag
> >was not properly saved when the INIT message left the originating
> endpoint
> >the INIT_ACK generated as a reply to the unexpected INIT will get dropped
> at
> >the INIT originating endpoint.
> >
> >Note that the INIT_ACK is _NOT_ unexpected as the originating endpoint
> >previously sent an INIT (unexpected INIT_ACKs should always be discarded,
> >section 5.2.3), without the patch the INIT_ACK is being silently
> discarded.
> >The patch saves the initialization tag for the outgoing INIT, which will
> be
> >needed later to verify the incoming INIT_ACK. Without this a lost
> >association (e.g. power failure) can never be re-established before the
> >ESTABLISHED_TIMEOUT (currently set to 5 days) expires.
> >
> >It is the destination endpoint that receives an unexpected INIT and it is
> >therefore bound to reply with an INIT_ACK, to get the 4-way handshake
> going
> >(section 5.2.2). However, as I mentioned above, the destination endpoint
> >shouldn't modify the existing association TCB or create a new one,
> otherwise
> >the destination endpoint will be vulnerable to DOS attacks.
> >
> >
> As is conntrack if it modifies the saved tag of an established connection
> without looking for a valid exchange of Tie-Tags and COOKIE-ECHO, if I
> don't
> completely misunderstand. Someone simply needs to send an INIT for an
> existing
> association and can prevent further packets from getting through. But I
> think
> you're patch is what is intended by the code, so we probably should put
> it in
> for now. Kiran, could you have a look at Ariel's patch please ?
> 

You are right about the conntrack being susceptible to fraudulent INIT
messages. This holds true for INIT-ACKs as well as the first INIT send. 

Saving the verification tags harms more than it helps, because it makes the
connection tracking vulnerable to dos attacks. While the goal is dumping
invalid traffic, it could instead wind up discarding valid traffic. 

I thought about these issues and I don't see a way of using verification
tags without making the connection tracking susceptible to this problems.
Saving tie-tags for existing associations until the COOKIE-ECHO/ACK is
processed could alleviate the problem. However, it will still take one
fraudulent message to launch an attack and cause the module to discard valid
traffic or prevent the association from being established by overwriting the
valid tie-tag. 

And then again, SCTP is just a transport protocol and without authentication
(e.g. IPSEC AH), it will be vulnerable to masquerading attacks as well, so
maybe SCTP connection tracking doesn't really have to protect against these,
as IPSEC would provide the needed authentication and prevent malicious
messages from overwriting the connection tracking saved verification tags.
This is good, because we can leave things as they are and just patch the
code for the re-starting association case.

In the mean time I patched the module with the code below (please see a more
robust patch at the end of the message) to solve the saved vtag problem for
both directions.

Thanks,

- Ariel

> Thanks,
> Patrick
> 

--- /usr/src/linux-2.6.10/net/ipv4/netfilter/ip_conntrack_proto_sctp.c
2005-02-04 16:22:24.000000000 -0500
+++ ip_conntrack_proto_sctp.c   2005-02-21 13:06:58.373096368 -0500
@@ -392,6 +392,7 @@
                if (sch->type == SCTP_CID_INIT 
                        || sch->type == SCTP_CID_INIT_ACK) {
                        sctp_inithdr_t _inithdr, *ih;
+                       u_int32_t dir;
 
                        ih = skb_header_pointer(skb, offset +
sizeof(sctp_chunkhdr_t),
                                                sizeof(_inithdr),
&_inithdr);
@@ -401,7 +402,9 @@
                        }
                        DEBUGP("Setting vtag %x for dir %d\n", 
                                        ih->init_tag, CTINFO2DIR(ctinfo));
-                       conntrack->proto.sctp.vtag[IP_CT_DIR_ORIGINAL] =
ih->init_tag;
+                       dir = (CTINFO2DIR(ctinfo) == IP_CT_DIR_ORIGINAL)? 
+                           IP_CT_DIR_REPLY: IP_CT_DIR_ORIGINAL;
+                       conntrack->proto.sctp.vtag[dir] = ih->init_tag;
                }
 
                conntrack->proto.sctp.state = newconntrack;

Re: ip_conntrack_proto_sctp INIT_ACK messages dropped

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 3149 bytes --]

Ariel Rosenblatt wrote:
> You are right about the conntrack being susceptible to fraudulent INIT
> messages. This holds true for INIT-ACKs as well as the first INIT send. 
> 
> Saving the verification tags harms more than it helps, because it makes the
> connection tracking vulnerable to dos attacks. While the goal is dumping
> invalid traffic, it could instead wind up discarding valid traffic. 
> 
> I thought about these issues and I don't see a way of using verification
> tags without making the connection tracking susceptible to this problems.
> Saving tie-tags for existing associations until the COOKIE-ECHO/ACK is
> processed could alleviate the problem. However, it will still take one
	> fraudulent message to launch an attack and cause the module to 
discard valid
> traffic or prevent the association from being established by overwriting the
> valid tie-tag. 

How can it be attacked with a single message ? I'm thinking of something
like this (based on RFC 2960 5.2.4.1):

Endpoint A                                          Endpoint Z
<-------------- Association is established---------------------->
Tag=Tag_A                                             Tag=Tag_Z
<--------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
       & other info]  --------\ <- conntrack lets this packet pass
(Start T1-init timer)         \
(Enter COOKIE-WAIT state)      \---> (find a existing TCB
                                       compose temp TCB and Cookie_Z
                                       with Tie-Tags to previous
                                       association)
                                 /--- INIT ACK [Veri Tag=Tag_A',
                                /               I-Tag=Tag_Z',
(Cancel T1-init timer) <------/                Cookie_Z[TieTags=
                                                Tag_A,Tag_Z
                                                 & other info]
                                      (destroy temp TCB,leave original
                                       in place)

Conntrack notes the Tie-Tags if they match the used tags and
lets this message pass.

COOKIE ECHO [Veri=Tag_Z',
              Cookie_Z
              Tie=Tag_A,
              Tag_Z]----------\
(Start T1-init timer)         \
(Enter COOKIE-ECHOED state)    \---> (Find existing association,
                                       Tie-Tags match old tags,
                                       Tags do not match i.e.
                                       case X X M M above,
                                       Announce Restart to ULP
                                       and reset association).

Conntrack verifies the tags match the saved tags and resets the
association.

So without a full exchange no data is changed.

> In the mean time I patched the module with the code below (please see a more
> robust patch at the end of the message) to solve the saved vtag problem for
> both directions.

Thanks. I applied this slightly different version (no new variable) and
I'm going to submit it later today.

Regards
Patrick

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1056 bytes --]

# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/02/22 14:52:03+01:00 ariel@blueslice.com 
#   [NETFILTER]: Fix sctp association restart
#   
#   Signed-off-by: Patrick McHardy <kaber@trash.net>
# 
# net/ipv4/netfilter/ip_conntrack_proto_sctp.c
#   2005/02/22 14:51:54+01:00 ariel@blueslice.com +2 -2
#   [NETFILTER]: Fix sctp association restart
#   
#   Signed-off-by: Patrick McHardy <kaber@trash.net>
# 
diff -Nru a/net/ipv4/netfilter/ip_conntrack_proto_sctp.c b/net/ipv4/netfilter/ip_conntrack_proto_sctp.c
--- a/net/ipv4/netfilter/ip_conntrack_proto_sctp.c	2005-02-22 14:54:35 +01:00
+++ b/net/ipv4/netfilter/ip_conntrack_proto_sctp.c	2005-02-22 14:54:35 +01:00
@@ -400,8 +400,8 @@
 					return -1;
 			}
 			DEBUGP("Setting vtag %x for dir %d\n", 
-					ih->init_tag, CTINFO2DIR(ctinfo));
-			conntrack->proto.sctp.vtag[IP_CT_DIR_ORIGINAL] = ih->init_tag;
+					ih->init_tag, !CTINFO2DIR(ctinfo));
+			conntrack->proto.sctp.vtag[!CTINFO2DIR(ctinfo)] = ih->init_tag;
 		}
 
 		conntrack->proto.sctp.state = newconntrack;

RE: ip_conntrack_proto_sctp INIT_ACK messages dropped

[Ariel Rosenblatt]

> -----Original Message-----
> From: Patrick McHardy [mailto:kaber@trash.net]
> Sent: Tuesday, February 22, 2005 9:06 AM
> To: Ariel Rosenblatt
> Cc: 'Harald Welte'; netfilter-devel@lists.netfilter.org; 'Kiran Kumar
> Immidi'
> Subject: Re: ip_conntrack_proto_sctp INIT_ACK messages dropped
> 
> Ariel Rosenblatt wrote:
> > I thought about these issues and I don't see a way of using verification
> > tags without making the connection tracking susceptible to this
> problems.
> > Saving tie-tags for existing associations until the COOKIE-ECHO/ACK is
> > processed could alleviate the problem. However, it will still take one
> 	> fraudulent message to launch an attack and cause the module to
> discard valid
> > traffic or prevent the association from being established by overwriting
> the
> > valid tie-tag.
> 
> How can it be attacked with a single message ? I'm thinking of something
> like this (based on RFC 2960 5.2.4.1):
> 
> Endpoint A                                          Endpoint Z
> <-------------- Association is established---------------------->
> Tag=Tag_A                                             Tag=Tag_Z
> <--------------------------------------------------------------->
> {A crashes and restarts}
> {app sets up a association with Z}
> (build TCB)
> INIT [I-Tag=Tag_A'
>        & other info]  --------\ <- conntrack lets this packet pass
> (Start T1-init timer)         \
> (Enter COOKIE-WAIT state)      \---> (find a existing TCB
>                                        compose temp TCB and Cookie_Z
>                                        with Tie-Tags to previous
>                                        association)
>                                  /--- INIT ACK [Veri Tag=Tag_A',
>                                 /               I-Tag=Tag_Z',
> (Cancel T1-init timer) <------/                Cookie_Z[TieTags=
>                                                 Tag_A,Tag_Z
>                                                  & other info]
>                                       (destroy temp TCB,leave original
>                                        in place)
> 
> Conntrack notes the Tie-Tags if they match the used tags and
> lets this message pass.
> 
> COOKIE ECHO [Veri=Tag_Z',
>               Cookie_Z
>               Tie=Tag_A,
>               Tag_Z]----------\
> (Start T1-init timer)         \
> (Enter COOKIE-ECHOED state)    \---> (Find existing association,
>                                        Tie-Tags match old tags,
>                                        Tags do not match i.e.
>                                        case X X M M above,
>                                        Announce Restart to ULP
>                                        and reset association).
> 
> Conntrack verifies the tags match the saved tags and resets the
> association.
> 
> So without a full exchange no data is changed.
> 

Hi Patrick,

This is kind of what I had in mind. However, a malicious INIT-ACK, with
knowledge about the saved tags (these can be easily sniffed) can cause the
conntrack module to save a fictitious Tag_Z'' causing the conntrack to save
Tag_A' and Tag_Z'', thus discarding the valid INIT-ACK with Init_Tag=Tag_Z'.

Also, a malicious COOKIE-ECHO can cause the Tag_Z''' to be saved instead of
Tag_Z', having the same effect as a malicious INIT-ACK. 

As for saving Tag_A', this can be done at the INIT or the INIT-ACK. Saving
it at the INIT is bad as you mentioned before. Saving it during the INIT-ACK
is also bad because a malicious INIT-ACK can make Tag_A'' to be saved
causing the conntrack module to discard valid traffic tagged as Tag_A'.

It would seem that by keeping the Tag_A' used in the INIT (while Tag_A is
still in use) just to match it to the Tag_A' that should be used in the
INIT-ACK will solve the problem (kind of a two staged approach). However
this "kept" Tag_A' (or Tag_Z' for the INIT-ACK) can be easily overwritten
with a malicious INIT (or INIT-ACK), before the INIT-ACK arrives (or the
COOKIE-ECHO is sent). Timers will help for this two phase approach. However,
serious performance degradation will still be achieved if the vtags and
tie-tags are known to the attacker.

Tags (as well as cookies) can be sniffed, so malicious cookies can be
generated to trick the connection tracking into believing that the
association must be reset. The very fact that the connection tracking relies
on these messages to save the tags is what causes this vulnerability.

However, as I stated before, without proper network layer authentication
(e.g. IPSEC AH) SCTP endpoints are not exempt from masquerading attacks, and
there is so much connection tracking can do to enhance the lack of transport
layer security. 

Thanks,

- Ariel 

> Regards
> Patrick

RE: ip_conntrack_proto_sctp INIT_ACK messages dropped

[Patrick McHardy]

On Tue, 22 Feb 2005, Ariel Rosenblatt wrote:
> This is kind of what I had in mind. However, a malicious INIT-ACK, with
> knowledge about the saved tags (these can be easily sniffed) can cause the
> conntrack module to save a fictitious Tag_Z'' causing the conntrack to save
> Tag_A' and Tag_Z'', thus discarding the valid INIT-ACK with Init_Tag=Tag_Z'.
>
> Also, a malicious COOKIE-ECHO can cause the Tag_Z''' to be saved instead of
> Tag_Z', having the same effect as a malicious INIT-ACK.
>
> As for saving Tag_A', this can be done at the INIT or the INIT-ACK. Saving
> it at the INIT is bad as you mentioned before. Saving it during the INIT-ACK
> is also bad because a malicious INIT-ACK can make Tag_A'' to be saved
> causing the conntrack module to discard valid traffic tagged as Tag_A'.

In all these cases an attacker needs to know the tags, in which case
he can simply reset the association. We are trying to protect against
someone guessing src/dst/ports.

> It would seem that by keeping the Tag_A' used in the INIT (while Tag_A is
> still in use) just to match it to the Tag_A' that should be used in the
> INIT-ACK will solve the problem (kind of a two staged approach). However
> this "kept" Tag_A' (or Tag_Z' for the INIT-ACK) can be easily overwritten
> with a malicious INIT (or INIT-ACK), before the INIT-ACK arrives (or the
> COOKIE-ECHO is sent). Timers will help for this two phase approach. However,
> serious performance degradation will still be achieved if the vtags and
> tie-tags are known to the attacker.
>
> Tags (as well as cookies) can be sniffed, so malicious cookies can be
> generated to trick the connection tracking into believing that the
> association must be reset. The very fact that the connection tracking relies
> on these messages to save the tags is what causes this vulnerability.

Again, this is not what we are trying to protect against.

> However, as I stated before, without proper network layer authentication
> (e.g. IPSEC AH) SCTP endpoints are not exempt from masquerading attacks, and
> there is so much connection tracking can do to enhance the lack of transport
> layer security.

Still we should do the best we can, which seems to be makeing
sure the restart is valid before changing the tags. I'll see
if I can come up with a patch.

Regards
Patrick

RE: ip_conntrack_proto_sctp INIT_ACK messages dropped

[Ariel Rosenblatt]

> -----Original Message-----
> From: Patrick McHardy [mailto:kaber@trash.net]
> Sent: Tuesday, February 22, 2005 1:44 PM
> To: Ariel Rosenblatt
> Cc: 'Harald Welte'; netfilter-devel@lists.netfilter.org; 'Kiran Kumar
> Immidi'
> Subject: RE: ip_conntrack_proto_sctp INIT_ACK messages dropped
> 
> On Tue, 22 Feb 2005, Ariel Rosenblatt wrote:
> > As for saving Tag_A', this can be done at the INIT or the INIT-ACK.
> Saving
> > it at the INIT is bad as you mentioned before. Saving it during the
> INIT-ACK
> > is also bad because a malicious INIT-ACK can make Tag_A'' to be saved
> > causing the conntrack module to discard valid traffic tagged as Tag_A'.
> 
> In all these cases an attacker needs to know the tags, in which case
> he can simply reset the association. We are trying to protect against
> someone guessing src/dst/ports.

You are right!

> Still we should do the best we can, which seems to be makeing
> sure the restart is valid before changing the tags. I'll see
> if I can come up with a patch.

Please let me know if I can help with this and also the multi homing
support.

Thanks,

- Ariel

> Regards
> Patrick
> 
> 

Re: ip_conntrack_proto_sctp INIT_ACK messages dropped

[Patrick McHardy]

Ariel Rosenblatt wrote:
>>Still we should do the best we can, which seems to be makeing
>>sure the restart is valid before changing the tags. I'll see
>>if I can come up with a patch.
> 
> Please let me know if I can help with this and also the multi homing
> support.

Unfortunately we can't use the Tie-Tags since the format and content
of the cookie is up to its sender. We could probably add our own data
to the cookie, but I don't have time to play with this currently.

Regards
Patrick