Subject: RE: [Tsvwg] RFC2960bis ... (SCTP in a dentist office)

From: [email-masked]
Date: Fri, 11 May 2001 12:45:29 +0300

Hi Randy,

> Considering how long IPv6 addresses are AND the fact that you can
> set them.. site local addresses will be prime candidates for ::0001
> and ::0002.. That being the case this "scenario" will be VERY VERY
> common.  I cannot see adding a case where one can create a "blackhole"
> that will knock down SCTP associtations. This is a very very bad design
> element to put in a transport protocol.

When you brought this up earlier, it got me to thinking that this could
open a very big hole.  I can imagine all sorts of nasty attacks 
when there are mixed global, site-local and link-local addresses.

My off-the-cuff rules would be:

1) Never include site-local addresses in INIT/INIT-ACK unless you are 
   on the same site.

2) Never include link-local addresses in INIT/INIT-ACK unless you are 
   on the same link.

Now, how to enforce these rules are another issue.  I think you &
Jim are converging on a solution. You both outstrip me interms of 
coding/deployment experience, so I'll defer to you both.

br,
John

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Fri, 11 May 2001 06:44:14 -0500

> 2) Never include link-local addresses in INIT/INIT-ACK unless you are

I hope to talk to Jim  a bit more today so maybe there is some
additional
way to tell 1 and 2 above... right now the only way I know to
tell 1 & 2 is if the source address is site local or link local... 

Jim may have another method.. . if not I think the rules I put out
are the only ones you can go with...

R

-- 
Randall R. Stewart
Systems & Solutions Engineering
Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 11 May 2001 16:25:14 -0500

....
> 2) Never include link-local addresses in INIT/INIT-ACK unless you are

I think these rules are very good.. concise, precise and not too
prohibitive. As to how an implementation can tell whether 1 or 2 is true
is in my opinion really an implementation issue, not a protocol design
issue. 

Moreover, these rules, if being followed by the implementation, are
adequate to avoid the "black-hole" scenarios Randy has been worried
about all along. 

-Qiaobing

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 11 May 2001 17:49:30 -0700 (PDT)

> 2) Never include link-local addresses in INIT/INIT-ACK unless you are 

The above rules are better than the rule set previously proposed.  At
least it does not prohibit SCTP stack to use link local or site local
addresses when they are perfectly legal.

							K. Poon.
							[email-masked]

---

From: Randall Stewart at work <[email-masked]>
Date: Fri, 11 May 2001 21:09:50 -0500

Q:

I see our hour long conversation did not really accomplish as
much as I thought..

> > 1) Never include site-local addresses in INIT/INIT-ACK unless you are

The above rule is only detectable (as I state below) by sending to a
SITE LOCAL or RECEIVING FROM a SITE LOCAL.. if you do anything less
then this in the spec you WILL HAVE A ROGE BLACK HOLE problem..

> > 2) Never include link-local addresses in INIT/INIT-ACK unless you are

The ONLY way you know that you are on the same link if you are
sending to a link local.. YOU JUST CAN"T PUT LINK LOCAL ADDRESSES IN
THE INIT ... PERIOD!!! IT DOES NOT WORK!!!

You can send to them, you can receive from them and use the other
address rules to get them in your association BUT YOU CANNOT LIST THEM.

The above rules DO NOT fix the problem... and you will doom SCTP to
be a broken protocol on V6 if you do not have the wording to properly
restrict and scope the addresses... these rules are NOT THOSE...

R