The IP over ATM Mailing List Archive by date

[Craig Partridge <craig@aland.bbn.com>]

    Now instead of InARPs if we used ARP requests then how can the server be
    sure that the clients IP address is what the client claims to be? Should
    this be of any concern? Maybe I am missing something here.

We can never be sure.  We cannot be sure that its response to an InARP is
correct either.  Anyone can open an ARP VC and then start fibbing.  One
can lie via ARP on Ethernets today (hijacking server IP addresses is a
known problem).

However, there are some security checks one could do:

    * one could confirm that the source ATM address of an ARP request
    matches the "Calling Party" fields of the Q.93B request of the VC.
    Unfortunately, since RFC 1577 says simply that these fields SHOULD
    match the actual address, the implication is one SHOULD NOT do this
    check or at least, that it can be turned off (the Internet "be liberal
    in what you receive" rule probably applies).

    * one should always check that there is only one ATM address for
    a given IP address and log it as an error if there is more than one
    (this is generally true for any ARP implementation).

Craig

PS: A technical question to the list.  I've read through RFC 1293 and RFC
1577 and still cannot tell whether ar$tha must be filled in an InARP request.
Am I correct that a valid InARP request is:

    ar$sha = arp$arp-req
    ar$spa = server IP address
    ar$tha = NULL or atm$ha  <- in particular, is NULL legal here?
    ar$tpa = NULL

and that the client replies with:

    ar$sha = atm$ha
    ar$spa = client IP address
    ar$tha = arp$arp-req
    ar$tpa = server IP address