Subject: (ION) draft-armitage-ion-sec-arp-00.txt

From: [email-masked]
Date: Wed, 4 Feb 1998 15:05:40 +0100 (MET)

-----BEGIN PGP SIGNED MESSAGE-----

Hello,

<draft-armitage-ion-sec-arp-00.txt>, Page 4, Section 3, last
paragraph (continues on page 5) goes:

> Weak access controls to a host's UNI signaling stack may allow a
> local user application to establish VCs using Calling Party numbers
> with arbitrary SEL values (the choice of the other 19 octets of a
> Calling Party AESA is limited by the ESIs initially registered by the
> client with the local switch using ILMI). Sufficiently weak access
> controls might even allow an application to choose Calling Party
> numbers that clash with other local ATM-based applications. Weak
> access controls to the host's ATM NIC itself could allow user
> deployment of a complete ILMI/UNI signaling stack of their own,
> customized for whatever task is required.

I have the following comments:

A user can choose an arbitrary Calling Party Number. He is not limited
to the SEL values. The Calling Party Number is an OPTIONAL IE in
SETUP-messages, which may be supplied by the user or network. As it
is not used for routing and there is no (default) access control on
the switch, this IE can be faked.

A user does not need to register an ATM address with ILMI at the
switch. He can use ANY calling party number he likes. ILMI is used to
register ATM addresses to allow the switch (network) for routing
INCOMING SETUP-messages to the host (which has registered the ATM
address).

A user can register additional ATM addresses at the switch. (... ESIs
initially registered...)

So the problem is NOT weak access control on the user side. It is the
weak (default) access control on the network side (switch).

I'd like to suggest the following (instead of the cited paragraph):

  Weak access control at the network side of the UNI may allow a 
  local user application to establish VCs using arbitrary Calling
  Party numbers. 

Regards,

        Carsten Benecke

- -- 
Carsten Benecke,  [email-masked],  Tel.:+49-40-5494-2262, Fax: -2241
DFN-FWL, University of Hamburg,  Vogt-Koelln-Strasse 30, D-22527 Hamburg
PGP-key available via  http://www.fwl.dfn.de/~cb/pgp.html  or  Keyserver

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Grenville Armitage <[email-masked]>
Date: Mon, 16 Feb 1998 04:15:59 -0500

Carsten,

I'm afraid you misunderstood the term 'user' in the text
you quoted. I'm refering to a "local user application" running
on a host. That's a process, on a host whose OS is mediating
access to the NIC, which in turn mediates access to the physical
link to the switch. Thus, the 'user' has exactly the limited
types of access to the switch that I wrote.

Your suggested alternative paragraph is true only where
the physical link to the switch has been compromised (hijacked)
and an entire ATM endpoint is being emulated. But that is a
very specific subcase, and does not warrant wholesale removal
of the paragraph you quoted.

cheers,
gja
	[..]
>   local user application to establish VCs using arbitrary Calling
	[..]
________________________________________________________________________
Grenville Armitage                          High Speed Networks Research
http://nj5.injersey.com/~gja              Bell Labs, Lucent Technologies
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: [email-masked]
Date: Mon, 16 Feb 1998 11:11:02 +0100 (MET)

Grenville Armitage writes:
Grenville,

 > types of access to the switch that I wrote.

Well, I was not thinking about a human who is connected to the
switch...

 > of the paragraph you quoted.

So you think that network security should rely on host security ?? In
my opinion we should not presume that there are only well maintained
computers with "security aware" operating systems connected to an ATM
network. Instead we should look at the interface between computer an
ATM network (switch) and try to figure out what kind of manipulation
and misuse is possible in order to give good advises for counter
measures in the draft (RFC).

Or do I missuderstand the purpose of the draft?

Regards,

        Carsten Benecke

--

---

From: [email-masked]
Date: Sat, 21 Feb 1998 15:05:40 +0100 (MET)

Hi,

one more try...

Grenville Armitage writes:
 > [email-masked] wrote:
 > 	[..]
 > > So you think that network security should rely on host security ??
 > 
 > I have no idea why you are twisting my words around. The I-D
 > is quite clear, and the paragraph you are complaining about is
 > also quite clear. It describes what can go wrong when we
 > trust endpoint security. What are you disagreeing with?

Sorry, it is not at all my intention to twist your words aroud. But in my
opinion there can go even more wrong when we trust endpoint
security. To resume the most important statemant of my original
comment (http://netlab.ucs.indiana.edu/hypermail/ion/9802/0005.html),
I will try it one more time:

 If we trust endpoint security, ATM address spoofing is not limited to
 the SEL value. The whole ATM address can be spoofed during signaling
 and there is no need to register the spoofed address with ILMI. 

I also think that this is more dangerous than spoofing just the SEL
part of the address. If changes to the ATM address were limited to the
SEL part, ATM based attacks could easily be traced. But this is not the
case unless you enforce it on the switches!

So instead of discussing what can go wrong with arbitrary week access
control to signalling stacks, it is sufficent to say, that the Calling
Party IE can be spoofed by end systems and that the ILMI protocol can
also be used for attacks to the switch. You do so in the last sentence
(..."customized for whatever task is reqired."), but you don't point
out the security risks which are implied.

 > > In
 > > network.
 > Fine. Pretty much what is already written in the I-D. So what
 > are you objecting to, exactly?

See above, "It describes what can go wrong when we trust endpoint
security". As I said, even more can go wrong, e.g. an end system could
use ILMI to register itself as a network device in order to use PNNI
for routing attacks. 

 > > Instead we should look at the interface between computer an
 > You can do that too.
 
Ok, what about suggesting people to use signaling filters on their
switches? If someone tries to spoof a Calling Party IE the switch will
deny the signalling. 

You can also recommend administrators to configure the switch ports
for either UNI or NNI. So there will be no way for an end system,
connected to an UNI port, to use ILMI in order to change to NNI (for
routing attacks).

 > Perhaps you misunderstand that the I-D tries to cover a
 > _variety_ of security risks. Telling me to remove a description
 > of endstation security risks, just to add some obvious statement
 > about what happens if someone gets physical access to a
 > switch port, is hard for me to accept.
 > 
 > What's even harder for me to understand is that your entire
 > complaint seems to be already satisfied by the rest of the
 > text in section 3, where physical compromise of a link to
 > a switch is already alluded to as a security threat.

Sorry Grenville. Don't get me wrong, but showing the security threats
can only be the first step. I also expect a discussion of counter
measures. And that is exactly what you do for the ATMARP server. The
suggestions in section 5.1 are verry good.

On the other hand, we seem to agree that there are hosts which you
cannot trust. So counter measures for ATM address spoofing have to be
switch based (or more generally network based).

	Regards,
        Carsten Benecke