As per Relevance of the word security, we have this rfc below:
Network Working Group J.
Request for Comments: 2336 Bay
Category: Informational July 1998
Classical IP and ARP over ATM to NHRP
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document describes methods and procedures for the
transition from an ATMARP LIS[1] to an NHRP LIS[2] network model
ATM
1.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
document, are to be interpreted as described in [6].
ATMARP defines an initial application of classical IP and ARP in
ATM network environment configured as a LIS[1]. ATMARP
considers application of ATM as a direct replacement for the "wires
and local LAN segments connecting IP end-stations and
operating in the "classical" LAN-based paradigm
The NBMA Next Hop Resolution Protocol (NHRP) allows a source
(a host or router), wishing to communicate over a Non-Broadcast
Multi-Access (NBMA) subnetwork, to determine the
layer addresses and NBMA addresses of suitable "NBMA next hops
toward a destination station. If the destination is connected to
NBMA subnetwork and direct communication is administratively allowed
then the NBMA next hop is the destination station itself. Otherwise
the NBMA next hop is the egress router from the NBMA subnetwork
is "nearest" to the destination station. For the purposes of
document, the NBMA network is of type ATM
Luciani Informational [Page 1]
RFC 2336 Classical IP and ARP over ATM to NHRP July 1998
It is reasonable to expect that ATMARP Clients and NHRP Clients
initially coexist within a LIS. Thus, it is necessary to define
graceful transition, including a period of coexistance, from the
of ATMARP to the use of NHRP for address resolution in the
[1][2]. In short, NHSs will be required to respond to ATMARP
queries in a fashion which will permit continued use of the
Client within the LIS during the ATMARP to NHRP transition period
Note that this document places no protocol requirements
ATMARP[1] servers
For the following, it will be assumed that the reader is
with the terminology as described in [1][2][3].
2. Service
If NHRP is to be used in a LIS then only NHSs will be used in
LIS; that is, there will not be a mixture of NHSs and ATMARP
within the same LIS. Since ATMARP servers will not be able
understand NHCs and since, as described below, NHSs will respond
ATMARP Clients, this is a reasonable simplifying restriction
This document will only address SVC based environments and will
address PVC environments. This document will refer only to ATM AAL
as the NBMA and IP as the protocol layer since ATMARP only
these protocols
2.1 NHRP Server
If NHRP Servers (NHS) are to be deployed in a LIS which contains
ATMARP Clients and NHRP Clients then NHSs MUST respond
ATMARP_Requests sent by ATMARP Clients in the same fashion that
ATMARP Server would respond as described in [1]. To do this, the
MUST first recognize the LLC/SNAP ATMARP code point with LLC=0xAA
AA-03, OUI=0x00-00-00, and ethertype=0x08-06. Further, the NHS
recognize the packet formats described in Section 8.7 of [1].
However, since this document does not extend to PVC environments
NHSs MUST only receive/respond to values of ar$op of 1,2,10
(Decimal). If an NHS receives an ATMARP message with ar$op
other than those previously noted then the NHS MUST discard
packet and MUST NOT take any further action
When an NHS receives a valid (as defined in the previous paragraph
ATMARP_Request packet, the NHS MUST follow the rules described
Section 8.4 of [1] with the following additional processing
Luciani Informational [Page 2]
RFC 2336 Classical IP and ARP over ATM to NHRP July 1998
1) When an ATMARP_Request causes a new table entry in the NHS
an ATMARP Client, that table entry MUST be marked as being
type "ATMARP" so that it can be differentiated from an
sourced entry
2) An ATMARP_Request MUST NOT cause an ATMARP_Reply to be sent
that ATMARP_Request contains an off-LIS protocol address.
should never happen because the IP stack on the
machine should automatically send the packet to the
router. If this does occur then the ATMARP_Request MUST
an ATMARP_NAK to be sent to the originator
In [1], an ATMARP_Request packet also serves as
registraion/registration-update packet which would cause a server
add an entry to a server's cache or to update a previously
entry. When an NHS receives an ATMARP_Request which causes
creation of a new cache entry in the NHS or updates an existing
then that cache entry will have a holding time of 20 minutes (this
the default value in [1]).
An NHS receiving an NHRP Resolution Request MUST NOT send a
NHRP Resolution Reply for a station which registered via ATMARP
the station sending the NHRP Resolution Request is outside the LIS
the station which registered itself via ATMARP. This is because
station which registered via ATMARP is almost certainly not
to accept a cut-through. When this occurs, the replying NHS
send NHRP Resolution Reply which contains a CIE code of "4 -
Administratively Prohibited" as described in [2]. This type of
does not preclude the station sending the NHRP Resolution
from sending its data packets along the routed path but it
preclude that station from setting up a cut-through VC
2.2 Multi-server
Since NHRP servers may work in a multi-server environment on a
LIS basis during the transition, it is necessary to know how
synchronization occurs. These rules may be found in [5].
3. Security
Not all of the security issues relating to IP over ATM are
understood at this time, due to the fluid state of
specifications, newness of the technology, and other factors
Luciani Informational [Page 3]
RFC 2336 Classical IP and ARP over ATM to NHRP July 1998
It is believed that ATM and IP facilities for authenticated
management, authenticated end-to-end communications, and
encryption will be needed in globally connected ATM networks.
future security facilities and their use by IP networks are
the scope of this memo
There are known security issues relating to host impersonation
the address resolution protocols used in the Internet [4].
special security mechanisms have been added to ATMARP. While
supplies some mechanisms for authentication, ATMARP does not.
any security mechanism is only as good as its weakest link, it
be assumed that when NHRP and ATMARP exist with a given LIS,
security of a combination is only as good as that supplied by ATMARP
[1] Laubach, M. and J. Halpern, "Classical IP and ARP over ATM",
2225, April 1998.
[2] Luciani, J., Katz, D., Piscitello, D., Cole, B. and N. Doraswamy
"NBMA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998.
[3] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy, "
Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.
[4] Security Problems in the TCP/IP Protocol Suite, Bellovin,
Computer Communications Review, Vol. 19, Issue 2, pp. 32-48, 1989.
[5] Luciani, J., "A Distributed NHRP Service Using SCSP", RFC 2335,
April 1998.
[6] Bradner, S., "Key words for use in RFCs to Indicate
Levels", RFC 2119, March 1997.
Thanks to Andy Malis for his input on this draft
Author's
James V.
Bay
3 Federal
Mail Stop: BL3-03
Billerica, MA 01821
Phone: +1 978 916 4734
Email: luciani@baynetworks.
Luciani Informational [Page 4]
RFC 2336 Classical IP and ARP over ATM to NHRP July 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Luciani Informational [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
