Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Mon, 3 Mar 2003 21:42:14 +0200

Brian,

> > >Collision cannot be detected until COOKIE-ECHO is received
> > >(RFC 2960 5.2.4 (B)).  One does not have to peer into the
> > >address list of the INIT or INIT-ACK to detect collision.
> > >  
> > >
> > 
> > Collision detection is not what Ivan is talking about.. you 
> MUST find
> > the old association (if there is one) so you can populate 
> the tie-tags so
> > you CAN do a collision detection as discussed in that section.
> > 
> > You cannot do the detection without the tie tags being properly
> > populated, and you cannot populate the tie-tags without this
> > address lookup.. unless of course you have a special implementation
> > (as you do) that has pre-knowledge on all of the addresses 
> the peer has.
> > Please think beyond your specialized implementation where you
> > have NO KNOWLEDGE of any of the peer addresses...
> > 
> > Then maybe you can answer Ivan's question above, which you seem
> > to be ignoring..
> 
> The information from the IP and SCTP header is sufficient to identify
> a fully formed TCB and populate tie tags.  There is no need to look in
> the source address list of the INIT or INIT-ACK.
> 
> --brian

	Can you give us any practical example (I mean, with Addresses, VTs, ports, states and stuff) of the cases we are discussing, instead of continue doing cut&paste with the previous paragraph?

	That might be more convincing than simply trusting you just because... especially since we "doubt" you are right :-/

	It is a pity that only you know how to do it and you don't want to share that knowledge with us... :-(

	BR Iván Arias Rodríguez

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Mar 2003 13:37:59 -0700

Ivan.Arias-Rodriguez,

On Mon, 03 Mar 2003, [email-masked] wrote:

> 	Can you give us any practical example (I mean, with Addresses, VTs,
> 	ports, states and stuff) of the cases we are discussing, instead of
> 	continue doing cut&paste with the previous paragraph?
> 
> 	That might be more convincing than simply trusting you just because...
> 	especially since we "doubt" you are right :-/
> 

Ivan,

You example is the INIT collision example.  Correct?

Something like the following:

      Host A                                             Host B/C
                                                                 
      INIT (VT:W, A:1000-->B:1000) (-)                           
      -------------\                                             
      TCB formed (A:1000<->B:1000)                               
                     \                                           
                      \          INIT (VT:X, C:1000-->A:1000) (B)
                       \        /--------------------------------
                        \      /   TCB formed (A:1000<->B/C:1000)
                         \    /                                  
                          \------------------------------------->
                            /        TCB found on A:1000<->B:1000
                           /      Tie tags populated (VT:X, PT:0)
                          /                                      
                       INIT-ACK (VT:Z, PT:W, C:1000-->A:1000) (B)
      <----------------------------------------------------------
      TCB (VT=W) expanded to (A:1000<->B/C:1000)                 
                      /                                          
      <--------------/                                           
      Host A has no TCB for C:1000,A:1000, no tie tags populated.
      INIT-ACK (VT:Y, PT:X, A:1000->C:1000) (-)                  
      ---------------------------------------------------------->
                                               TCB found on VT=Z.
                                                                 
      COOKIE-ECHO (tie tags in cookie)                           
      ---------------------------------------------------------->
                                Tie tags used to detect collision
                                per 2960 5.2 case B.   VT updated
                                from Z to X.  established.       
                                                                 
      COOKIE-ECHO (no tie tags)                                  
      <----------------------------------------------------------
      TCB (VT=W) established.                                    

      One association.  VT:W, A:1000 <---> VT:X B/C:1000         
      <--------------------------------------------------------->

Never needed to look in the source address list.  Can your modify
this in any way to make it necessary?

--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: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Mar 2003 13:53:41 -0700

Ivan.Arias-Rodriguez,

Ivan,

Here, I believe, is Caitlan's example:

        HOST A                                                 HOST B/C
                                                                       
        INIT (VT:0 PT:X, A:1000->B:1000)                               
        -------------------------------------------------------------->
        TCB (VT:X, A:1000<->B:1000)                              No TCB

        INIT (VT:0 PT:Y, A:1000->C:1000)                               
        -------------------------------------------------------------->
        TCB (VT:Y, A:1000<->C:1000)                              No TCB

                               INIT-ACK(VT:X, PT:W, C:1000->A:1000 (B))
        <--------------------------------------------------------------
        TCB found (VT:X) and expanded (VT:X, A:1000<->B/C:1000)        
                                                                       
                               INIT-ACK(VT:Y, PT:Z, C:1000->A:1000 (B))
        <--------------------------------------------------------------
        TCB found (A:1000<->C:1000)                                    
        INIT-ACK discarded per RFC 2960 5.2.3.                         

        COOKIE-ECHO (VT:W)                                             
        -------------------------------------------------------------->
                                                        TCB established
                                                                       
        One association. (VT:X A:1000 <--> VT: W B/C:1000)             
        <------------------------------------------------------------->

Never had to look in the source address list.  Could you point out where
you think it is necessary?

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 03 Mar 2003 15:19:59 -0600

>        INIT (VT:0 PT:X, A:1000->B:1000)                               
But you do look at the source address list here.. in
processing the INIT-ACK. You must... and
you also must look through and find the TCB
with VT:Y unless you wish to leave it hanging..

I think this is Caitlin's point.. you must clean up this
extra TCB... and you do that by looking at the peers address
list and making sure you don't have a seperate TCB hanging
around... You have just shown one example of looking at
the address list in the INIT-ACK.

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Mar 2003 15:12:06 -0700

Randall,

> with VT:Y unless you wish to leave it hanging..

I look at the source address in the IP header of the INIT-ACK to find
the TCB.  The source address list is copied to the TCB without analysis
as there is no need to check the IP addresses in the source address list
for overlap.

The IG passage I have the problem with is:

   D) When searching for a matching TCB upon reception of an INIT
      or INIT-ACK chunk the receiver SHOULD use not only the
      source address of the packet (containing the INIT or
      INIT-ACK) but the receiver SHOULD also use all valid
      address parameters contained within the chunk.

I don't need to use the source address list within the INIT-ACK
chunk to find the proper TCB above.  I only need the source address
of the packet: quite the opposite of what this IG passage claims.

> the address list in the INIT-ACK.

How the implementation cleans up extra TCBs is its own business and
has no bearing on the passage in the IG.  The passage says "When
searching for a matching TCB".

I don't see anywhere here where it is necessary to analyze the source
address list in the INIT-ACK "[w]hen searching for a matching TCB."
Could you modify the example to show such a case as stated in IG 2.18.2?

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 03 Mar 2003 16:58:41 -0600

>as there is no need to check the IP addresses in the source address list
So if the source address is NOT the address you sent the INIT to but instead
it is one of the alternate addresses listed in the INIT-ACK (along with
the original address that the INIT was sent to) how are you going to
find the TCB... Your current code will.. ONLY because you have
pre-listed in its TCB all of the addresses that might be present
in the INIT-ACK..

This is fine for your very specialized stack NOT for a general
purpose stack.. so you now have just proved my point as to
where you must examine the INIT-ACK's address... thank you..

>of the packet: quite the opposite of what this IG passage claims.

You are 100% wrong.. if you sent the INIT to IP-A and the source address
is IP-B how will you find the TCB.. your implementation does ONLY
because you pre-listed IP-B in the TCB of the sender of the INIT.. this is
ok to do (that is why the SHOULD is there and NOT a MUST). But for
MOST implementations that are general.. obviously NOT yours.. you
must go through the INIT-ACK to find the TCB...

How much clearer do you need Ivan, Caitlin and I to be.. we all understand
this.. you seem not to since all you can see is your very very limited
implementation that places requirements on the user to pre-know
all addresses of the peer.. sorry this is ok for the SS7 world.. but it
is NOT ok for a general stack...

Expect the language to stay in... you are alone in your objections...

>Could you modify the example to show such a case as stated in IG 2.18.2?

My previous email to you showed you such a case.. and you ignored it.. this
email shows the very same case.. and you ignore it..

The ONLY reason your implementation works is because you require
the user to preset all of the peers addresses in before sending an INIT..
Its ok to do, thats why the passage is a SHOULD.. the rest of us
who are developing general purpose stacks that will make there way
into a lot of varied products can NOT work in such a narrow way..

You are very much alone in your objections...Bottom line..
the passage remains as is.....

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Mar 2003 16:36:28 -0700

Randall,

> pre-listed in its TCB all of the addresses that might be present

I use VT.  I don't need the source address list.
Read what the example says:  "TCB found (VT:X)"

> where you must examine the INIT-ACK's address... thank you..

I don't need to know the peer's addresses to find the TCB.
The TCB is the TCB with VT:X, the same VT I sent in the INIT.

> must go through the INIT-ACK to find the TCB...

I use VT.  I don't use a pre-determined address list.

> is NOT ok for a general stack...

I use VT.  I don't use a pre-determined address list.  I don't need to
look in the source address list.

> Expect the language to stay in... you are alone in your objections...

It is just a draft, so the recommendations don't count for anything yet.

> email shows the very same case.. and you ignore it..

Your previous mail shows the opposite: as you said in that: the TCB can be
found by VT and looking in the source address list is not necessary.

> into a lot of varied products can NOT work in such a narrow way..

That has nothing to do with the examples we are dicussing.  When our
implementation knows the addresses of the peer, the second INIT would
never even be launched.  When it does not, it relies on VT to find the
TCB and doesn't need the addresses in the address list to do so.

> the passage remains as is.....

I understand that the IG will never make it past draft anyway, so it
doesn't really matter if it is just your personal view...

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 03 Mar 2003 18:29:47 -0600

Brian 

>doesn't really matter if it is just your personal view...
Everyone but you seems to understand the concept.. it is not
my personal view...  you are the one who seems to have
a personal view..

And you are most likely correct the IG will most likely not
go past draft but be rolled together with 2960 and 3309 into
a new RFC... hopefully DS...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Mar 2003 17:50:07 -0700

Randall,

> a new RFC... hopefully DS...

Then we can pick this up again at LC.  I'm pretty sure in that
process that RFC 2119 will be respected and the SHOULD dropped.

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Mon, 03 Mar 2003 20:27:02 -0600

Brian F. G. Bidulock wrote:

>process that RFC 2119 will be respected and the SHOULD dropped
>

I doubt it for at least three reasons (I am sure there will be
others by the time we go to LC):

1) By using the Vtags for a hash lookup  you have serverly compromised
    the security associated with them. I have spent a bit more time 
reviewing
    your code.. and basically anytime the source port and Vtag match
    you ship the packet up the stream to the processing layer of your SCTP
   stack. This means that if I know a port that you are likely to have a
   listener , say for example we are using SCTP for http.. not to far
   fetched.. and I know there will be quite some number of connections
   (invision CNN or google)... then instead of having a 1 in 4 billion
   chance of guessing a Vtag.. I now have a N in 4 billion chance
   (where N is the number of connections you have up right now) and
   even more so I don't even need to know a source address and
   port you think are valid.. you don't care.. you will accept any as
   long as the V-tag and destination port are correct. This is an extreme
   mis-use of a security feature that works to compromise the
    security put into the protocol.. I doubt that the IESG would support
    such mis-use of a feature in the protocol.

2) Your code, looking back at Caitlins example... as near as I can tell
    would create both associations.. due to your blind faith in the vtag
    and the destination port... each INIT-ACK would find the sp that
    sent out the INIT and there is no cross validation.. you would
    end up with two associations .. as Caitlin surmised.. in violation of
    the RFC...

3) It is always possible to generate two random numbers that are the
    same.. this is what random numbers are.. truely random.. so you
   always have the chance of generating two tags into INIT-ACK's that
   are the same.. thus making one of the associations fail to come up.. I
   doubt the IESG likes blackholes in protocols left lying around...

In fact, it may well be the IESG would want us to strengthen the  SHOULD
to a MUST... to help prevent 1 and possibly 3... 

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 3 Mar 2003 23:32:03 -0700

Randall,

>     such mis-use of a feature in the protocol.

IP addresses are trivial to spoof.  There is no security afforded in addition
to the VT by adding spoofable IP addresses to the match.  If you need
security, I suggest you (re)read the security section of RFC 2960. ;)

>     end up with two associations .. as Caitlin surmised.. in violation of

Two associations will only be set up if the peer violates the RFC first and
allows both COOKIE-ECHO's to establish an association.  If you look at the
COOKIE-ECHO handling you will see that our implementation will not set up
both associations even if it could be persuaded to launch the two inits of
Caitlin's example.  This is because any second COOKIE-ECHO is discarded
per the default case in RFC 2960 5.2.4 (no tie tags, mismatch on both local
and peer tag).

Nowhere in the RFC does it say that it is illegal to launch two COOKIE-ECHOs
for two different associations for the same set of endpoints.  It is illegal
to _establish_ two associations between the set of end-points.  The receiver
of two COOKIE-ECHOs must only move one association to the ESTABLISHED state
or it is in violation of the MUST in the RFC.

Our current implementation launches two COOKE-ECHO's in Caitlin's example,
but it is not necessary to do so.  This is what I was trying to tell you in
the detailed example.  The source address of the packet (combined with
destination address and port pair) on the second INIT-ACK is sufficient to
find the first expanded TCB (again without looking in the source address
list).

For INIT-ACKs all we would have to do is call and fail an sctp_lookup_tcb
before calling sctp_lookup_vtag (1 line of code).  I think that would be
a waste for a corner case when the peer must refuse the second COOKIE-ECHO.
Long hard lookup with locks held on the hashes does not scale.  Particularly
when the more exhaustive search is almost never necessary.  We should put
it inside the CONFIG_SCTP_SLOW_VERIFICATION ifdef so those that want poor
performance can get what they ask for.

>    doubt the IESG likes blackholes in protocols left lying around...

The VTAG generation algorithm is pseudo random with a random seed and an
occassional random swirl.  Such series are far less likely to repeat than
total random functions.  There are other more likely events that will
interfere with association initialization (e.g. noise).

It I really thought it was important, I would check for duplicates in the
vtag hash while entering the TCB into the vtag hash and reselect the vtag
if a match was found.  This is rather simple to include because the
socket/stream is placed in the vtag hash before any message with the vtag
is launched.  3 or 4 lines of code would do it.  Thanks for the suggestion
for improvement.  I could put the little loop in sctp_get_vtag to check
the hash before returning the tag.  Then it will be guaranteed that there are
no duplicates in the hash.  As the lookup is just a normal hash lookup on
the vtag to see if it exists first, there should be no problem with scaling.
This one could go in the CONFIG_SCTP_SLOW_VERIFICATION ifndef.

> to a MUST... to help prevent 1 and possibly 3... 

This is much like telling someone how they SHOULD or MUST move bytes around
when calculating an CRC.  You didn't agree with me on that one either...
...but it changed.

Thanks for the inspection of the code.  We now have two relatively minor
improvements and still don't have to look in the INIT or INIT-ACK source
address lists.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 4 Mar 2003 12:55:18 -0700

Caitlin,

On Tue, 04 Mar 2003, Caitlin Bestler wrote:

> Brian,
> 
> You are correct on two fronts:
> 
> a) The two associations will merge by the time
> the extra COOKIE-ECHO is received.
> 
> b) It is possible to generate unique VTAGs. Simply
> using the TCB's address would be one method.

Unfortunately a VT must be generated in response to an INIT without creating a
TCB.  Also, addresses are not a secure way of creating a VT, because they are
too predictable for a given architecture.
> 
> What you haven't answered is why it should be acceptable
> to subject the network to the excess COOKIE-ECHO messages.
> There is at least one, and likely more if the eclipsed
> association continues to retransmit.

It is not necessary to send the second COOKIE-ECHO.  I have already provided
this for you in example.

> 
> It is clearly appropriate to tell implementers that they
> SHOULD NOT put spurious messages onto the net.

It is not necessary to look in the source address list to not send the second
COOKIE-ECHO.  Look at the detailed diagrams I sent: it is always sufficient to
use the address pair and port pair from the IP and SCTP header to find the
"expanded" TCB from the first INIT-ACK.  So don't tell implementors that they
SHOULD be doing something that they simply don't have to.

If you would like to say: Implementations SHOULD NOT generate excess packets,
go ahead.  But don't tell the implementation how it SHOULD go about doing that
unless it is important to interoperability and not just performance.

> 
> I'll concede that there are environments where this is
> sufficiently low probability that an argument can be made
> against telling them that they MUST NOT do so. Any system
> that is or uses a service for the Internet as a whole (such
> as an SCTP web server) is clearly not one of them. But a
> closed set of servers that already have their own methods
> of authentication at the ULP level probably could be allowed
> to skip the test (although I remain unconvinced that it
> really is much of a benefit).

The test recommended is not necessary to get rid of the COOKIE-ECHO.

Proper application of SO_REUSEADDR on a socket interface gets rid of your
example, but the way.  Unless the user forces SO_REUSEADDR on both sockets,
the bind of the second socket to A:1000 will fail with EADDRBUSY.  So the
sockets interface has to be forced to get it to do what you show in the first
place.  This is because it is almost never what the user wants: to bind two
sockets to the same static port and address (not listening).  Your example is
simply a further misconfiguration and would only result from misconfigured or
broken software.  (Broken and misconfigured application software can cause
more waste in the network than the occasional seemingly redundant
COOKIE-ECHO).

> 
> I also remain skeptical that deferring detection until
> COOKIE-ECHO processing will properly handle all of the
> "wrong state" COOKIE-ECHO scenarios. In particular, how
> does the passive side distinquish between repeat
> COOKIE-ECHOes from the eclipsed association and a peer
> restart?

It cannot tell, now can it?  This is why SO_REUSADDR defaults to don't reuse
and separate sockets cannot bind to the same statically assign port and
address (necessary to launch the inits in your example).  TCP cannot detect
the difference between a SYN on a half-open socket and a second SYN from a
different socket for the same address either.

What were you going to do?  Refuse to send the second COOKIE-ECHO and pass an
error to the user?

What if the peer application refuses (aborts) the first connection instead of
accepting it?  As follows:

 INIT  (A->B)                                            
 ------------------------------------------------------->
                                                         
 INIT  (A->C)                                            
 ------------------------------------------------------->
                                                         
                                       (B/C->A)  INIT-ACK
 <-------------------------------------------------------
 COOKIE-ECHO  (For first INIT)                           
 ------------------------------------------------------->
                                      (Indication to ULP)

                                       (B/C->A)  INIT-ACK
 <-------------------------------------------------------
 Abort to user.                                          

                                                    ABORT
 <-------------------------------------------------------
                           (User refuses connection A->B)

Not on sockets, but with the STREAMS interface it is possible to refuse
connection indications before they are accepted.  If the ULP is configured to
accept A->C initiated connections but refuse (ABORT before COOKIE-ACK) A->B
initiated connections, and the Host A is going to always attempt A->B before
A->C, then this will hang in a loop forever, generating many useless packets
in the network.

Just because you send a COOKIE-ECHO does not mean that the association will be
accepted and a COOKIE-ACK received.  This is what I meant by predicting the
future.  The peer (and the peer ULP) should be given the oppotunity to choose
which connection it wishes to accept and which it wishes to refuse.  The user
cannot be given an opportunity to decide on the INIT for obvious reasons.

Also, what if the local user aborts on the connection confirmation?

 INIT  (A->B)                                            
 ------------------------------------------------------->
                                                         
 INIT  (A->C)                                            
 ------------------------------------------------------->
                                                         
                                       (B/C->A)  INIT-ACK
 <-------------------------------------------------------
 (Confirmation to ULP)
                                       (B/C->A)  INIT-ACK
 <-------------------------------------------------------
 Abort to user.                                          
                                                         
 ------>                                                 
 ULP aborts first connection.

Above are two examples that result in no assocation (bad thing) when if both
COOKIE-ECHOs were sent would result in one association.

Remember that all sockets implementations of TCP strongly discourage the
equivalent from happening in TCP by forcing the user to use the SO_REUSEDADDR
flag on all binds to the port and warning that the use of SO_REUSEADDR has
potential negative effects on the network and robustness of the protocol.

I was told on TSVWG not long ago that there are _no_ useful applications that
statically assign both port numbers.  The Internet does not do this.  So,
regardless of Randall's claims about "general purpose" stacks, the Internet is
not "general purpose".  It is client/server where the client always
dynamically assigns its port number.  Your example will not happen on the
Internet, only in highly specialized applications that should know what they
are doing.  SO_REUSEADDR will keep casual users from stumbingling into this
scenario (second static port bind will fail).

Efficiencies including a tradeoff of performance is not a question of
interoperability, it is an implementation decision.  The keywoard SHOULD "MUST
only be used where it is actually required for interoperation or to limit
behavior which has potential for causing harm (e.g., limiting retransmissions)
For example, they must not be used to try to impose a particular method on
implementors where the method is not required for interoperability."

I can assure you that the SHOULD of IG section 2.18 will never make it into
an RFC.  It says how one SHOULD _search_for_something_.  It is IMO a clear and
obvious violation of the "MUST" in RFC 2119 regarding use of keywords.

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 06 Mar 2003 06:30:49 -0600

Users of OpenSS7..

I want you to pay special attention to this email and
understand the security issues involved in not defining the
variable:

SCTP_SLOW_VERIFICATION

See below

>security, I suggest you (re)read the security section of RFC 2960. ;)
Has Brian mentions above, anyone can spoof IP addresses.. So lets 
consider blind attackers
and there needs for a moment (TCP, SCTP-with-slow-verify (address 
matching), SCTP-vtag/port matching).

Protocol           |           Needed to guess by the hacker
-------------------+---------------------------------------------------------------
   TCP              |       Dest IP addr, Dest Port, Src IP addr, Src Port
    SCTP-addr  |       Dest IP addr, Dest Port, Src IP addr, Src Port, V-tag
   SCTP-vtag   |       Dest port, Vtag

Now For all cases, we can discard the Dest IP address and port.. this is
a simple to guess.. i.e. I know your IP address and KNOW you are
running a XXX server at Port YYY.

So for TCP we need to guess a 32 bit source IP address of an existing
peer and a 16 bit port number of an existing peer... This yeilds at most
48 bits of protection. I say at most due to the fact that the port space is
probably smaller since it is a pretty good bet the src is a dynamic port
which may have a more limited range... i.e. figure out what TCP port
range, dynamically,  windows uses and this narrows the bits some..

Conclusion - TCP provides 48 bits of protection, at most, against
                       blind attacks.

Now for SCTP-addr we need to guess the same 48 bits again but
we add to this a 32 bit V-tag. And in this 32 bit V-tag you must
guess the single one (no matter how many associations are up
on the machine) that goes with the pariticular source address and
port of the victim's peer. This means you get the same 48 bits PLUS
a full additional 32 bits of protection so:

Conclusion SCTP-addr provides 80 bits of protection (at most for
the same discussion of the port issue I made in TCP) against blind
attacks.

Now for SCTP-vtag - Here we blindly take any valid V-tag that
is in the system on any active association.. we don't care what the
addresses are.. all we look at is the V-tag and destination port. The
destination port is, as we discussed, easily guessable.. so we can
dis-qualify that. Instead we have a N in 32bit chance of getting
a packet accepted.. where N is the number of active associations
up on the machine.

Conclusion SCTP-vtag provides less than 32 bits of protection
against blind attack's being substantially weaker than even
plain old TCP.

Another interesting side note is that SCTP depends on the V-tag
to also filter out mis-routed packets as well.. (TCP uses a pseudo
header in the checksum for this purpose)  A mis-routed packet
has less than a  1 in 4billion chance of being accepted by SCTP-addr
since the mis-routed packet must also have a source/dest port that matches
an existing association and the complete V-Tag space is available
you have a 1 in the full 32 bits of getting the mis-routed packet through..
i.e. the same 80bit protection is afforded..

SCTP-vtag on the other hand, only has to have the destination port
match any existing destination port and then you get a N in 32 bit
chance of getting the mis-routed packet through..

So: What can you do to protect yourself if you are using this 
implementation?

Make sure SCTP_SLOW_VERIFICATION is defined in your build. This will change
the code to do:

#define sctp_match_vtag(__sp, __saddr, __daddr, __v_tag, __sport, __dport) \
    ( ((__v_tag) == (__sp)->v_tag) && \
      ((__sport) == (__sp)->sport) && \
      ((__dport) == (__sp)->dport) && \
      (sctp_find_saddr((__sp),(__daddr))) && \
      (sctp_find_daddr((__sp),(__saddr))) )

instead of the much weaker:

#define sctp_match_vtag(__sp, __saddr, __daddr, __v_tag, __sport, __dport) \
    ( ((__v_tag) == (__sp)->v_tag) && \
      ((__sport) == (__sp)->sport) )

In finding associations.

One dis-advantage to this approach however, is you will have to make 
sure that ALL addresses
of the peers are known when you open a listening endpoint.. otherwise 
some of the scenarios
discussed in the matching discussion will occcur and associations could 
fail to
start up..

Regards

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Mar 2003 06:24:44 -0700

Randall,

Your warning is about 2 years behind mine:

  Slow Verification
  CONFIG_SCTP_SLOW_VERIFICATION
     When a message comes from an SCTP endpoint with the correct
     verification tag, it is not necessary to check whether it is from
     a correct source address to identify the SCTP association to
     which it belongs.  When you say N here, source addresses are not
     checked and it is up to firewall implementations to thwart
     attackers of the verification tag.  When you say Y here, you get
     RFC 2960 compliant operation, but at a great cost to SCTP
     performance.

Also, see below...

> Protocol           |           Needed to guess by the hacker

Source port is a simple guess too.

> discussed in the matching discussion will occcur and associations could 

Associations will not fail to start up, even with the static port examples
given by Caitlin, Ivan and yourself.

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 06 Mar 2003 07:55:11 -0600

>     RFC 2960 compliant operation, but at a great cost to SCTP

So, you admit that using V-Tags weakens security .. which was the
entire purpose of the V-Tag...

>Source port is a simple guess too.
Yes, as I say below... you have a limited range that dynamic ports
are assigned from... but of course you don't have to use a dynamic
port to start an association either...

>given by Caitlin, Ivan and yourself.
Yes, there is a scenario that Ivan illustrated with colliding INIT's 
where unless
you pre-know all the addresses on each side, the association will not 
startup..

Ivan painted this quite well.. as well as his most recent 
illustration... which
for some reason you refuse to acknowledge...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 6 Mar 2003 09:14:04 -0700

Randall,

> entire purpose of the V-Tag...

Looking up TCBs on V-Tag does not weaken security.  Once the TCB
is found, the source address of the packet can then be verified
before processing a packet.  We do it anyway for every message
to find the source address structure for reply chunks, but only
after the TCB has been looked up.  So I suppose the situation
regarding association security is not as bad as it sounds above.

Perhaps I should change the name of the define to

  CONFIG_SCTP_RIDICULOUSLY_SLOW_LOOKUPS

For those that want unnecessarily slow lookups as the source address
can be checked after the lookup anyway.

In sctp_recv_msg all one needs to do is change:

	/* set address for reply chunks */
	if (sp->daddr) {
		sp->caddr = sctp_find_daddr(sk, skb->nh.iph->saddr);
		normal(sp->caddr);
	}

 to:

	/* set address for reply chunks */
	if (sp->daddr) {
		if (!(sp->caddr = sctp_find_daddr(sk, skb->nh.iph->saddr)))
			return (-EPROTO);
	}

and all messages from the wrong source address will be discarded.  The
source port is already checked in sctp_lookup_vtag as you faithfully
reproduce below.

It is certainly never necessary to consider the source address _list_
in the INIT or INIT-ACK "[w]hen searching for a TCB" as IG section 2.18
foolishly states.

If you (or anyone) are that worried about it you can patch your copy with
the lines above and just say 'N' to CONFIG_SCTP_SLOW_VERIFICATION, err..
CONFIG_SCTP_RIDICULOUSLY_SLOW_LOOKUPS.

--brian