Subject: RE: Matching addresses in INIT and INIT ACK

From: <[email-masked]>
Date: Sat, 8 Mar 2003 16:24:29 +0200

Hi Brian,

> Ivan,
> 
> On Fri, 07 Mar 2003, [email-masked] wrote:
> 
> > 
> > 	I still don't follow you at all... What you can know is 
> that the INIT
> > 	is sent to the same endpoint, not that it comes from the same
> > 	endpoint...
> > 
> > 	You know it goes there, so what? You don't know where 
> it comes from...
> > 	D might or might not be part of the same endpoint that 
> also uses C
> > 	(you don't know unless you take a look to the address 
> parameter)...
> > 	What if another completely different peer sends an INIT
> > 	E:1000->B:1000? will you populate the Tie Tags as well? Will you
> > 	"recognize" it as being part of the association you are 
> about the
> > 	create?
> 
> Consider that if a completely different peer sends E:1000->B:1000 and
> places C or D in the address list that you will offer the potential
> attacker the unprotected vtag of the existing TCB in the cookie.

	I don't think so...

	We realized about this quite many bake offs ago, and that's the reason why section 2.6 is there. Since you recognize that the peer apparently tries to add a new address, you don't send back the INIT ACK.

	I personally think that it is better to send the INIT ACK to any of the "old addresses" (C or D in this case) instead of sending the ABORT. But in any case, the INIT ACK will not be sent to E.

	Brian, the other mail conversation with topic "Address List Change on Restart" is just about this case... :-/

> Also, the INIT from D:1000->B:1000 with (C) in its list is not
> necessarily the peer at C:1000.

	You mean that the INIT received from D could have been sent by an attacker that for some reason new that Host A/B was establishing an association with C? Interesting, however, we though about exactly this scenario when writing section 2.6, and if you read the new text for section 5.2.1 of RFC 2960, while in the COOKIE WAIT state, you would send the INIT ACK back to C, not to D. I personally think that this same approach could be taken to address the case where the INIT receiver is in the ESTABLISHED state, i.e., sending back the INIT ACK to an "old address" instead of the ABORT...

	This is precisely to avoid giving the VT (since you use the same one) to an attacker...

> This is the very reason why I do not check the source address 
> list, just
> the source address in the packet: because none of the addresses in the
> list are reliable.  Any attacker can put any source address 
> in the list.

	But those cases are already covered by section 2.6. 

> This is similar to the hijack situation that 2.6 attempted to solve.

	It is not similar, it is exactly that situation...

> 2.6 only addresses the situation where the attacker tries to 
> add its own
> address to an existing address list when an established association
> exists.  However, the same principle applies to hijacking 
> hosts sending
> INITs that foolishly follow 2.18.  Following your HOST A/B 
> and HOST C/D
> example, I will add a malicious Host E.
> 
> The sequence is as follows (note that Host E TCB's are from HOST A/B's
> view as the attacker can mimic whatever they like):
> 
>Host A/B                                                            Host E
>                                                                    
>TCB     \   INIT VT:0 IT:W                      INIT VT:0 IT:X   /  TCB
>A,B:1000 \  A:1000->C:1000                      E:1000->B:1000  /   E,C:1000
>C:1000    \                                     (C in list)    /    B:1000
>VTloc:W    \                                                  /     VTloc:X
>VTpeer:0    \                                                /      VTpeer:0
>C-WAIT       \                                              /       C-WAIT
>              \--------------------\  /--------------------/
>                                    \/
>                                    /\
>                                   /  \                             Host C/D
>   (1)  <-------------------------/    \------------------------->
>
>        \   INIT ACK VT:X IT:Y                                    
>         \  B:1000->E:1000                                      
>          \ VTloc:Y VTpeer:X                                   
>           \TTloc:W TTpeer:0                                  

	This is the step where you are wrong... Go read section 2.6 (new text for section 5.2.1 of RFC 2960, at the end of the first paragraph) and you will see that this INIT ACK would go to C, not to E...

	We realized about this, and that's why we changed it...

	But in any case this discussion is interesting, we might even find some new problem we have to fix...

>            \                                                 
>             \                                               
>              \--------------------\                        
>                                    \ 
>                                     \
>                                      \
>                                       \------------------------->  Host E
>                                              COOKIE ECHO VT:Y   /  TCB
>                                                D:1000->B:1000  /   C,D:1000
>                                              VTloc:Y VTpeer:X /    A,B:1000
>                                              TTloc:W TTpeer:0/     VTloc:X
>                                                             /      VTpeer:Y
>                                                            /       C-ECHOED
>                                      /--------------------/
>                                     /
>                                    / 
>                                   /   
>   (2)  <-------------------------/                                

>TCB                                                                    
>A,B:1000                                                                    
>E,C:1000                                                                    
>VTloc:W                                                                     
>VTpeer:X                                                                    
>ESTABLISHED
> 
> At (1) by checking the source address list, Host A/B gives up 
> the VT of
> the TCB to the attacker.

	Read above.

> At (2), if attacking Host E can return a COOKIE-ECHO before valid Host
> C/D returns an INIT-ACK, E will be installed in the TCB and will have
> hijacked the association by spoofing C in the address list.

	We will never reach this point, see above.

> Certainly after (1), the attacker has the VT of the existing 
> TCB and can
> easily wreak havoc with that (ABORT, HEARTBEAT-ACK, SHUTDOWN, etc.).

	That was a problem with current RFC 2960 and that's why it was changed by the IG, see above...

> If the attacker can turn around the COOKIE-ECHO fast enough 
> (because it
> is "closer" than C/D or just because C/D is already heavily loaded,
> perhaps with bogus INITs from Host E or another attacking 
> host), then it
> can easily hijack the association.

	Nope...

> After hijacking the association, either Host A/B does not 
> support ADD-IP
> on the association, in which case the hijacker could have up to 30
> seconds before C gets a HEARTBEAT, or, if Host A/B supports ADD-IP and
> the first action from E is to delete IP C.  Another technique would be
> to get a new cookie and keep restarting the association 
> before C gets a
> HEARTBEAT.  At any rate, Host E has from 60 seconds to forever to
> pretend to be Host A/B.  30 seconds is a long time.

	It is funny to read that you are basically explaining the situation in the same way we did when we decided to change section 5.2.1... :-)

> For some period, the ULP at Host A/B believes that it is communicating
> with Host C/D but is in fact communicating with Host E.  This is very
> bad.

	But this won't happen, as explained above...

> So how does Host A/B distinguish between this:
> 
>Host A/B                                                            Host E
>                                                                    
>TCB     \   INIT VT:0 IT:W                      INIT VT:0 IT:X   /  TCB
>A,B:1000 \  A:1000->C:1000                      E:1000->B:1000  /   E,C:1000
>C:1000    \                                     (C in list)    /    B:1000
>VTloc:W    \                                                  /     VTloc:X
>VTpeer:0    \                                                /      VTpeer:0
>C-WAIT       \                                              /       C-WAIT
>              \--------------------\  /--------------------/
>                                    \/
>                                    /\
>                                   /  \                             Host C/D
>   (1)  <-------------------------/    \------------------------->
> 
> And this:
> 
>Host A/B                                                            Host C/D
>                                                                    
>TCB     \   INIT VT:0 IT:W                      INIT VT:0 IT:X   /  TCB
>A,B:1000 \  A:1000->C:1000                      D:1000->B:1000  /   C,D:1000
>C:1000    \                                     (C in list)    /    B:1000
>VTloc:W    \                                                  /     VTloc:X
>VTpeer:0    \                                                /      VTpeer:0
>C-WAIT       \                                              /       C-WAIT
>              \--------------------\  /--------------------/
>                                    \/
>                                    /\
>                                   /  \
>   (1)  <-------------------------/    \------------------------->
> 
> Without prior knowledge of address D it cannot distinguish between the
> two.

	In any case the INIT ACK from Host A/B will go to C. So, if we have an attacker here, the INIT ACK will be lost... It is not possible that Host E makes Host A/B think that he is Host C/D (at least, not in the way you are trying)...

> Note that although forming a proper association here requires static
> port assignment on both sides, that is not true for the 
> attack.  Knowing
> the well-known server port on one side an the normal client 
> dynamic port
> assignment range on the other, it is quite easy to attack a 
> large number
> of clients simultaneously.  The IP address I would spoof in my source
> address list would be the IP address and port of your on-line banking
> server, and I would send INITs repeatedly to the low end of 
> your dynamic
> port range, and wait for you to give me your cookie in the 
> INIT-ACK with
> tie-tags populated.  Then, presto!, for 30 seconds I'm your bank.

	I was also quite happy when we fixed this... The idea above looks like genial, doesn't it? But due to the changes included in section 2.6 of the IG, this is not possible anymore :-)

> The current STREAMS OpenSS7 implementation does not consider 
> the source
> address list and only uses packet header information (direct 
> opposite of
> 2.18) and will not surrender the VT of the current association to D or
> E, but will populate tie tags with zero as you originally 
> showed, if the
> connect() at Host A/B was only provided with C.

	But then, could you explain me how would you solve the "original" INIT collision between Host A/B and Host C/D? You argued that you would be able to recognize the peer, but I'm still wondering why, and you didn't answer... I copy here again the diagram:

Host A/B                                                            Host C/D
                                                                    
TCB     \   INIT VT:0 IT:W                      INIT VT:0 IT:X   /  TCB
A,B:1000 \  A:1000->C:1000                      D:1000->B:1000  /   C,D:1000
C:1000    \                                                    /    B:1000
VTloc:W    \                                                  /     VTloc:X
VTpeer:0    \                                                /      VTpeer:0
C-WAIT       \                                              /       C-WAIT
              \--------------------\  /--------------------/
                                    \/
                                    /\
                                   /  \
        <-------------------------/    \------------------------->

        \   INIT ACK VT:X IT:Y              INIT ACK VT:W IT:Z   /
         \  B:1000->D:1000                      C:1000->A:1000  /
          \ VTloc:Y VTpeer:X                  VTloc:Z VTpeer:W /
           \TTloc:0 TTpeer:0                  TTloc:0 TTpeer:0/
            \                                                /
             \                                              /
              \--------------------\  /--------------------/
                                    \/
                                    /\
                                   /  \
        <-------------------------/    \------------------------->

TCB     \   COOKIE ECHO VT:Z                  COOKIE ECHO VT:Y   /  TCB
A,B:1000 \  A:1000->C:1000                      D:1000->B:1000  /   C,D:1000
C,D:1000  \ VTloc:Z VTpeer:W                  VTloc:Y VTpeer:X /    A,B:1000
VTloc:W    \TTloc:0 TTpeer:0                  TTloc:0 TTpeer:0/     VTloc:X
VTpeer:Z    \                                                /      VTpeer:Y
C-ECHOED     \                                              /       C-ECHOED
              \--------------------\  /--------------------/
                                    \/
                                    /\
                                   /  \
       X<-------------------------/    \------------------------->X

	I don't think you are able to manage this case, Brian... So far I didn't follow any of your explanations... :-/

> If the connect() at Host A/B was provided with (C,D), the valid
> association will form and the attacker E cannot form an 
> association (the
> INIT-ACK to E will have zero tie-tags).

	But you cannot know beforehand all the addresses of all the possible hosts (basically all of them if you have, let's say, an HTTP server)... This is a special feature, a special situation, you are able to do so only if you are in a "restricted world" in which you already know everybody... but this is not the common case...

> Note that in your previous example, populating tie tags just because B
> is in the address list opens the same vulnerability.  The OpenSS7
> implementation sends an INIT-ACK with zero tie tags and the 
> association
> still forms.

	I think that at this point it is quite clear that it is not an issue since the INIT ACK is sent back to the "old address"

> Also, in the 2.6 scenario, the OpenSS7 implementation 
> populates the tie
> tag with zero because the attacker's IP address does not 
> match the TCB,
> and again the attacker is thwarted while in more circumstances than
> 2.6's prescription the legitimate restarting node can add IP addresses
> (as long as it is not the primary which is added, or the 
> restarting node
> tries INITs to other addresses as well).

	Following 2.6 you can address all those cases, and you are still protected against attackers...

	However, I would like to know what the other authors think about modifying 2.6 to manage the other case (association not in the COOKIE WAIT state) in the same way (i.e., not sending the ABORT but sending the INIT ACK to any of the "old addresses"). From my point of view this solution is neater and would make life easier to a true restarted peer that adds addresses...

	Randall, the others, what do you think?

> Caitlin's examples involved the INIT-ACK, which can always be 
> looked up
> on VT if the sender of the INIT constrains its VT assignment to be
> unique.
> 
> I don't see that I'm doing the wrong thing here in refusing to form
> associations with INITs sent from an unknown source address 
> claiming to
> have the correct source address list.

	If you do so, it might be that a peer that has restarted and added an address (which is the source of the INIT) is unable to re-establish the association...

> Am I not justified in the conclusion here is that one should not
> consider the source address list when searching for a matching TCB for
> received INIT messages?  Not considering them closes these two
> vulnerabilities and yet even your last example can form an association

	Well, as you see, they are not vulnerabilities... they are already covered by section 2.6...

> if the ULP provides the addresses of the peer (C/D) to the 
> connect() or

	But you cannot do that... Brian, come on... How are you going to do that if you are an HTTP server using SCTP and running on the Internet?

	It is impossible... Brian, in your "environment" you can do so, because it is very restricted. However, when you speak about the whole world, you simply cannot.

> t_connect() or the simple arrangement is made to INIT to the primary.

	You don't know which is the address that a host (to which you are sending an INIT) is going to use as a primary an which it is not, simply because you only know one of those.

	No, Brian, this is not a valid solution...

> IMO the right thing to do is to close the vulnerability for all
> associations at very minor expense of this one unnecessary 
> corner case.

	Well, the corner case is managed in the right way, and so you do with the "vulnerabilities", which are not such...

> (I say unnecessary because it is simple to configure Host A/B 
> to INIT to
> A->C and Host C/D to INIT to C->A, or provide C/D to connect().)

	Simple?

	How is it going to be simple? How are you going to know in advance all the hosts that could eventually establish an association with you when we are speaking about billions of them?

> Following 2.18 opens up the vulnerability above and the vulnerability
> yet to be properly addressed by 2.6.  Not following 2.18 closes both
> vulnerabilities.

	Actually I think that it is basically the opposite. Following those sections makes you perfectly manage those "special" situations... and closes the vulnerabilities that comes due the fact that you use VT (plus destination address and source/destination ports) as the way to identify an association. As Randall has already stated, this could make an attack eventually easier to perform...

> As this is the last example to be addressed, could you tell 
> me again why
> I should consider the source address list when searching for 
> a matching
> TCB on INIT and INIT-ACK?

	I have already told you. You should do that mainly because:

	a) That way you cover the problems with peers that restarted and added addresses.

	b) You also manage in the right way the INIT collisions.

	c) You don't compromise the security, losing part of the protection to attacks that the conjunction of source/destination address/port + VT gives you.

	We have never said that the VT is not a good choice to use to find an established association. Especially when transferring data, the randomness of the VT makes it very likely to use it as a hash key. However, once you find the association, you should also verify that both the source and destination address/port are right. And the opposite, if you don't find the association and the datagram contained an INIT/INIT ACK, you should look for the association using the address parameters...

	And now that I have answered, could you tell me how do you do it to manage the INIT collision case?

	(Though, your sentence "at very minor expense of this one unnecessary corner case" makes me think that there is not such solution).

	BR Iván Arias Rodríguez

> --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: Sat, 8 Mar 2003 13:30:44 -0700

Ivan,

> A,B:1000 \  A:1000->C:1000                      D:1000->B:1000  /   C,D:1000

Populating tie-tags with zero is correct? (IG 2.6)

Sending the INIT-ACK to C or D is moot (because it is sent to D
if the INIT arrived just before sending the INIT from A.)

>            \TTloc:0 TTpeer:0                  TTloc:0 TTpeer:0/

The host just copies the INIT-ACK info and echoes the cookie.
> VTloc:W    \TTloc:0 TTpeer:0                  TTloc:0 TTpeer:0/     VTloc:X

What have I done wrong to this point?

(Note that I have not looked at the source address list in the INIT.)

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sat, 08 Mar 2003 19:00:09 -0600

>Populating tie-tags with zero is correct? (IG 2.6)
What tie-tags? so far I see a INIT being sent above..
<AAA>

>if the INIT arrived just before sending the INIT from A.)
What does your statement have to do with anything.. you
send a INIT to C (from A) and all of a sudden you get a
INIT from D... you have NO idea that C and D are the same
endpoint... so you MUST send back a INIT-ACK to D...

>What have I done wrong to this point?

He was illustrating what you are advocating, not looking in the INIT
and INIT-ACK.. if you do look in the INIT, then at <AAA> you will
have populated the tie-tags since you would have recognized the
associations as being related (you would have found C in the the
INIT's  list of addresses .. the one from D.. and then you would
have found the TCB that sent the INIT to C...)

>(Note that I have not looked at the source address list in the INIT.)

Yep and that is why your association will not come up when it should..

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: Sat, 8 Mar 2003 20:13:48 -0700

Randall,

> What tie-tags? so far I see a INIT being sent above..

In the INIT-ACK being formulated at this point...

> endpoint... so you MUST send back a INIT-ACK to D...

Huh?  Is the new text in section 2.6 for section 5.2.1 in error?
It tells me that in COOKIE-WAIT state I must send the INIT-ACK back
to the same address that the original INIT (sent by this endpoint)
was sent to.

Yet you tell me I MUST send it to D?  I'm glad you don't have a
problem with me sending it to D (per RFC 2960) instead of to C
(per IG 08 2.6).

> have found the TCB that sent the INIT to C...)

But the tie-tags are not to be populated in COOKIE-WAIT states (according
to RFC 2960 section 5.2.2) and in COOKIE-WAIT, COOKIE-ECHOED or
SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New text for Section
5.2.2)

Now you are telling me they should be populated?  If they are populated
and D is X (the attacker) then you will have surrendered the VT of the
existing TCB to the attacker.

So are you saying that I have done the wrong thing by putting zero in the
tie-tags?  Then is RFC 2960 section 5.2.2 and IG 08 section 2.6 new text
for 5.2.2 in error?

I would seriously like to know what I've done wrong up to this point.

Your statements of what I have done wrong are not consistent with either
the RFC or the IG....  Please take a closer look at it and tell me where
I have gone astray.

--brian

> Yep and that is why your association will not come up when it should..

But I have following the RFC and Section 2.6 to the letter (except for
the C/D thing which doesn't change the result here.)

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sun, 09 Mar 2003 07:16:37 -0600

>problem with me sending it to D (per RFC 2960) instead of to C

I had forgotten about that addition... and actually it is the right thing
to do as well... This way if you did get a evil attacker sending in
from 'E' as you painted in one of the other emails would not
get the INIT-ACK back... and the peer at C/D would discard
it...

I will have to go check our implementation and see if we did this...
if not we will get a patch out right away :>

>SHUTDOWN-ACK-SENT according to IG 08 section 2.6 (see New text for Section
Hmm.. maybe they should be populated especially if you sent the
INIT-ACK back to the same place that you sent the INIT... I need
to think about this case...

>existing TCB to the attacker.
No, you send the INIT-ACK back to the original place you sent
the INIT (as you just corrected me up above).. in such a case
if D were X you would be sending the INIT-ACK back to
C and you would not be giving anything away..

>tie-tags?  Then is RFC 2960 section 5.2.2 and IG 08 section 2.6 new text
No, but I begin to wonder if maybe we should not do it this way... aka
you send back the INIT-ACK to where you sent the orginal INIT
AND you populate the tie-tags when you are in COOKIE-WAIT state.
Since you would not be revealing anything to anyone else but who
you sent the INIT to anyway...  let me think on this one for a while
but I am pretty sure that is why we did not send tie-tags in COOKIE-WAIT
and if thats the case... with the new provisions of 2.6 IG it might be
ok...

We might want to think about this for COOKIE_ECHOED as well...
Need to mull on this one for a bit..

>the RFC or the IG....  Please take a closer look at it and tell me where
No, I was not paying attention and was thinking of the INIT-ACK case...

R

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sun, 09 Mar 2003 07:31:51 -0600

>the RFC or the IG....  Please take a closer look at it and tell me where

After thinking on this a bit more and re-reading the IG and the original 
RFC...
I think the following changes are in order:

1) For the IG 2.6, as I said earlier, we need to change the wording in the
    IG to not send the "adding new address" error cause in the ABORT 
sent. This
    way, as Brian points out, we will not be revealing info to the 
attacker.. <OR>
    we may want to take Ivan's approach where we send the INIT-ACK back
    to one of the existing addresses... the down side of this is as 
Brian pointed
    out, by not getting information back, if it is an attacker, the 
attacker can
   deduce that an association exists.. (I will ask Steve on this point 
as well)...

2) For the same section in the IG we need to populate the tie-tags in the
    COOKIE-WAIT state as well, not just the COOKIE-ECHOED state as
    is currently in RFC2960. With the current changes in the IG (as Brian
    pointed out... you send back to the place you sent the INIT to) there
    is no danger of revealing your VT to a mallicious hacker in this case...

3) We may need a requirement that you MUST validate addresses and not
    solely depend on the uniquness of the V-Tags... otherwise you weaken
    security... I will discuss this one with Steve Bellovin in S.F. and see
   what he has to say...

R

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sun, 9 Mar 2003 14:08:18 -0700

Randall,

Here's what I doing differently (but I still think that you owe
me and the OpenSS7 implementation an apology):

When sending the INIT-ACK the implementation is choosing a new
verification tag instead of using the verification tag of the
existing TCB.  But the implementation also follows the RFC in
that the INIT-ACK is sent back to the source of the INIT.  If
the VT from the TCB was sent, it would be handed to the attacker
(in the initiate tag rather than tie-tags).  The OpenSS7
implementation sacrifices the collision case (rare) to protect
all other association initializations.

The IG is not normative.  This is why I asked on tsvwg why it
had not been advanced.  There are many clauses in the IG that
are clarifications and interpretations of RFC 2960 and can be
implemented without the IG being normative, but 2.6 is not one
of them.  RFC 2960 tells me that I MUST send the INIT-ACK back
to the source of the INIT.

To follow 2.6 I need to find the existing TCB to use the VT from
the TCB in the initiate tag of the INIT-ACK and send the
INIT-ACK to C instead of D.  But this still does not justify the
statement in 2.18, because it is only necessary to consider the
source address list in the INIT iff there exists one or more
TCBs for the port pair and local address, and iff one ore more
of those TCBs is in the COOKIE-WAIT state, (i.e. only if a
collision indeed can exist).  It is certainly not necessary to
consider and arbitrarily long and suspect source address list on
all INITs, or even on INITs where there is no TCB for the port
pair and destination address, or even on INITs where there is no
TCB for the port pair and destination address in the COOKIE-WAIT
state.  To consider an arbitrarily long and suspect source
address list on all INITs would open an implementation up to
DoS attacks with long source address lists.

So I still think that the new paragraph D) in IG 2.18 is
unwarranted.  It is OK to let implementations search how they
will as long as they meet the other requirements.

I will illustrate the need for the "extra" COOKIE-ECHO to limit
a DoS attack for the INIT-ACK case to address Caitlin's example
in a separate mail.

I will also address in a separate mail the new text for section
5.2.1 in section 2.6.  There, I believe that it is unnecessary
for the receiver of an INIT to reject it just because it includes
new addresses when the packet source address of the INIT is one
of the existing addresses of the TCB.  Also, that to not send an
INIT-ACK again opens a DoS attack (where the existing TCB in the
COOKIE-ECHOED state is for an association to a malicous endpoint).

Please consider that--just maybe--I know what I'm talking about
(yes, I can right sometimes ;), and please skip the attacks and
innuendos on both myself and the OpenSS7 implementations.

--brian

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Sun, 09 Mar 2003 18:46:34 -0600

>me and the OpenSS7 implementation an apology):
I fail to see why I would owe any implementation a apology..
the spec is the spec.. we are discussing issues with it and I hope
in the end it is stronger security wise as well as a document.

Our discussions have, for example, highlighted where the BSD
implementation did not send back to the INIT-ACK to where
the original INIT was sent.. this is a security weakness and it
is good that this discussion uncovered my error :-)

>(in the initiate tag rather than tie-tags).  
>

Not if one sends it back per the IG 2.6 to the original place one
sent the INIT.. this is the whole reason for the wording in the
IG (and a subtle point I had missed in the BSD stack.. it will
be fixed in a patch by tommorrow)...

>The OpenSS7
This is not as rare of case as you think. I know at least one implementation
that is always attempting to bring up an association with a peer... when
the two of these are put together I actually saw DATA on the COOKIE-ACK,
which I really did not think likely.. of course this 
implementations/application
almost ALWAYS went through this very collision scenario you depict.. since
when one machine is down the other is sending INIT's on a regular 
basis.. the
other one comes up and the first thing it does is send a INIT.. presto you
have this scenario.. it is not uncommon.. the wording lack, as I 
remember it, was
found in a bakeoff and we were NOT testing this condition.. it is far
more common then you think...

>to the source of the INIT.
And that MUST was not written thinking of  the collision cases. The IG 
2.6 is
correct and normative. It clearify's that when you are setting up an 
association
and then receive a INIT (the collision case) you then send the INIT-ACK back
to where you sent the INIT.. this is correct and we should have caught it
when we wrote RFC2960.. but like many things we missed issues.. this
was one.. I think if you follow the advise of the IG there is no 
problem.. and
there is nothing non-normative about this section...

>INIT-ACK to C instead of D. 
>
Thats correct.. which means you have to look in the INIT for
the addresses so you can do the proper matching of the
association.. this was ALWAYS the intention when we
wrote RFC2960..

> But this still does not justify the
How could you ever tell what state you were in unless you check
all the addresses? You would NEVER have any way to know. There
are other "corner cases" (as you call them, not I) that checking the
INIT/INIT-ACK covers.. at least three of them have been presented
to you.

>DoS attacks with long source address lists.

It is easy and cheap to check the source address list to see if
you have a TCB.. As Caitlin as pointed out, one can do
this with a properly written data structure without locking.
Once this is in place it takes far more cycles to do the SHA-1
signing..

Besides you can't look only some of the time.. you have to do
it all of the time .. since an implementation cannot possibly
know if it has a TCB unless it checks the addresses...

>will as long as they meet the other requirements.
You have to check the INIT period for those addresses... there is
no other way to find the association that is forming and there
is no way to know if one is forming unless you check...

>a DoS attack for the INIT-ACK case to address Caitlin's example
If an implementation feels it is under a DOS attack it can stop responding
to cookies, limit cookie responses (just like one does with ICMP) and
several other scenarios...

>of the existing addresses of the TCB. 
>
That procedure has been in the IG for a long time.. and it does make 
sense...
except the issue of sending back the abort with cause.. a regular abort
should do fine.. or I see possibly using Ivan's idea.. but like I said
I wish to talk to a security expert about this... aka Steve Bellovin.
It is good that you pointed this out...

> Also, that to not send an
Not necessarily.. one can send a ABORT for any number of reasons when
an INIT arrives.. no listner is one of the most likely scenarios... 
leave out
the error cause and you would not have any way of knowing if there
is even a listner on a port or not..

>innuendos on both myself and the OpenSS7 implementations.

I have never attacked either you or your implementation.. you do seem to
be good at attacking me and every one else as well that disagrees
with you. If I was not willing to listen to you I would not have responded
to your emails. Only when you seem to have topics worth exploring
do I respond.

If you refer to my pasting code in.. you are also welcome to paste
in code from my implementation.. there will definetly be bugs.. all
implementations have them... I have one to fix right now to make
the BSD implemention conformant to the IG section 2.6. :-0

R