🚀 go-pugleaf

In comp.protocols.ibm, rodrigo@athena.mit.edu (Rodrigo Figueiredo) writes:

    Could anyone tell me what is protocol spoofing in the IBM communications
    world. I suppose it applies to the LAN realm. I would like to know in
    detail how it works, so if you know of any document that describe the 
    technique in detail, please tell me.
    Please send any e-mail to rfigueir@sloan.mit.edu or to rodrigo@athena.mit.edu
    Thanks in advance.

    Rodrigo Figueiredo



> (1) Protocol Spoofing
 
  In the IBM communications world (SNA, BSC 3270, BSC 3780,etc), there is the
concept of Primary and Secondary stations or partners (depending on the level
you are perceiving a communication) or Master and Slave (for the older IBM
protocols). When a communication equipment implements protocol spoofing, it
pretends to be a secondary or primary session partner or station (different
level of spoofing). It fools the IBM host into thinking that it is communicating
directly with the intended user equipment. Consider a PU T2.0 protocol spoofing:- 


    IBM <----> [Protocol Spoofer]<--------->[Protocol Spoofer] <---> IBM
    HOST                                                            PU T2.0

The protocol spoofer at the host end will emulate as the intended IBM PUT2.0.
The protocol spoofer at the remote end will emulate as the IBM host.
In this case, both protocol spoofer only does protocol emulation (probably
with limited or no data stream emulation). So the the data stream from the
host will just passthrough the protocol spoofers and finally to the
IBM equipment. However the protocol implementations do not passthrough.

Protocol spoofing is considered proprietary. There are no standards (as of
yet) in protocol spoofing. Each vendor implements their own protocol spoofing.

Some vendors implement their own communication protocol stack as the reference
stack. i.e. They will use their own internal stack for communication with their
own protocol spoofers. So, all IBM data are stripped from their SNA headers
and then put on to the vendors own stack. This approach has many advantages.

It allows the SNA communication to be supported over various telecommunication
services. This is especially so if the host does not support or is not suitable
for the intended telecommunication service. Perhaps I should be general here.
Telecommunication service is intended to mean any transmission medium or mode.
So a LAN is also considered one.

For LAN realm, there are protocol spoofers around. The level of spoofing again
varies from vendor to vendor. For example, the HP router ER supports SNA
protocol spoofing. However the spoofing is only at SDLC level. It allows SNA
packets to be transported over the LAN to another HP router ER where out it
comes as a SNA/SDLC line.

For those vendors that does not use their communication stack as the reference,
they usually implement it over some standard protocols. Examples of this are
SNA/SDLC pads employing NPSI (IBM's SNA over X.25). There products can usually
communicate with other vendor's protocol spoofer using the above "standard"
protocol as the reference stack.

Protocol spoofing is used when it is costly, or any other reason (not supported
yet) to support a SNA transmission over a transmission facility (X.25, switched
X.21bis, LAN, SMDS, etc). You must be wary of the level of spoofing supported
and type of IBM equipment that will be supported. For example, most SNA protocol
spoofers only implement FID 2 (PUT.4 to PUT.2) traffic and not PUT.4 to PUT.4.
Check with the vendors first.


IBM has their own LAN products for support SNA communication over Token Ring.
CISCO also has routers that can perform SNA routing over LAN. Most vendors
perform a SNA/SDLC simulated passthrough.

Perhaps you would like to be more specific about your application of protocol
spoofing in your environment?


Regards, 

David LEE

dlee@hpsm8471.kl-mal.hp.com