The IP over ATM Mailing List Archive by date

[fong@fore.com (Fong-Ching Liaw)]

My 2cents.

and please read it considering that I am definitely not an expert 
in secured communication.

I am afraid that using ARP packet without authentication is not
going to give you much guarantee on knowning who you are
communicating with, it probably provides a false sense of security.  
The better way to ensure security while not having authentication
is prabably do what we do today, i.e. call backs. If the caller 
is not really what the calling number says he is, he would not get 
connected since the network does guarateen call be routed to the 
called party.  And this will be compatible with RFC 1755 in that
it will appear as if the one you are calling calls you as well.
The RFC said you should not reject the call simply because you
already initiate (or have) a connection to the party.

The calling address can not be trusted because the 
the network does not check the calling address.  The network
could do the checking, but the standard does not require it.

In addition, I am not sure that the Inverse ARP is the 
right place/protocol to query/enforce access list. I hope
people know more about security can speak up.

-Fong

> From atmpost@matmos.hpl.hp.com Tue Mar 28 20:30:07 1995
> Sender: atmpost@matmos.hpl.hp.com
> X-Info: Submissions to ip-atm@matmos.hpl.hp.com
> X-Info: [Un]Subscribe requests to majordomo@matmos.hpl.hp.com
> X-Info: Archives for ip-atm via ftp.hep.net:~ftp/lists-archive/atm 
> X-Loop: ATM CLP.bit ON
> Date: Tue, 28 Mar 1995 17:03:57 -0800
> From: zaumen@hsmpk12a-53.Eng.Sun.COM (Bill Zaumen)
> To: ip-atm@matmos.hpl.hp.com, zaumen@hsmpk12a-53.Eng.Sun.COM,
>         bryang@eng.adaptec.com
> Subject: Re:  An Extended Inverse Arp Protocol
> X-Sun-Charset: US-ASCII
> Content-Length: 3394
> 
> 
> After reading Bryan Gleeson's reply, I realized that I might have
> confused things a bit by a typo in the scenario I provided.  It was
> also my intention to propose only that a server respond to such extended
> ARP requests, not to require that a client must send them.
> 
> To clarify the scenario:
> 
> Suppose N1 sends a setup message to N2.  At this point, the only
> information N2 has is N1's ATM address.  N2 then has two choices:  send
> the extended inverse ARP request that I proposed to the server to
> authenticate N1, or accept the connection and (if needed) send node N1
> an inverse ARP request to obtain the corresponding IP address.  Node N2
> then must authenticate the IP address node N1 provides, possibly by
> sending an ARP request to the server.  This option requires that node
> N2 send two requests: an inverse ARP to node N1, and an ARP to the
> server, and also creates a short window during which node N1 can send node N2
> IP packets as if N1 were a valid member of the subnet.  Note also that
> if security is an issue, we can't trust node N1's IP address.  We can
> have much more confidence in node N1's ATM address because the setup
> message arrived and had to be forwarded by one or more switches.
> 
> With regard to Bryan's comments:
> 
> I've implemented an access-list mechanism too (possibly similar to what
> Bryan suggested in his message), but the concern for proposing it as a
> general mechanism is that when the access list changes because of
> administrative changes in the network, one then needs some mechanism to
> distribute these changes to all the clients.  The reason for the extended
> inverse ARP is to in effect use the server's access list to determine
> valid membership, allowing the list to be maintained in only one place.
> 
> I've also implemented the proposed extension (by default it is disabled
> because of the current standard), and the problem Bryan Gleeson mentioned
> with multiple outstanding requests never came up.  The reason is that
> we need a table indexed by ATM address anyway, so it is easy to
> track which incoming calls are waiting to be accepted.  When we
> obtain a valid response, we simply enter the corresponding addresses (at this
> point both the IP and ATM addresses are available) in the
> tables and accept the pending calls.
> 
> If there is a null address in an inverse ARP request, we assume that this
> is a request for a peer's IP address.  A server should never receive
> such requests, as RFC 1577 assumes that connections to a server will
> use SVCs.  In any case, for lookup purposes, one would assume a
> null target ATM address would be treated the same as one's own ATM address.
> 
> The question of how an ARP server can ensure that in an inverse lookup,
> the server found the right subnet, didn't come up.  For one thing, an
> inverse ARP message contains a source IP address, and this can be used
> by the server to determine the subnet.
> 
> Again, the proposal only requires that a server respond to these
> inverse ARP requests, and doesn't require any that a client do anything
> different than currently stated in RFC 1577.
> 
> On the other hand, I'm really not sure what to do about a common LLC
> entity.  In cases where security is a problem, there will quite likely
> need to be a standard on how to deal with that.  One will also have to
> address questions about whether the draft signaling standard (cf
> draft-ietf-ipatm-sig-01.txt) is compatible with any such standard.
> 
> Bill Zaumen
>