ORTIZ, RAMON AURUS B.

BSIT 4A

PROF. OMNES

MODULE 4
I. Describe a scenario in which a client could receive a reply from an earlier call.

If user request for one-time password and times out and then again if user request
for onetime password, and wait for one replay. The server which is working under
heavy load, receive both the request, and send two OTP. At this time user, will get OTP
for the first request and then user will get OTP for the second request.

II. Explain the design choices that are relevant to minimizing the amount of reply data held
at a server. Compare the storage requirements when the RR and RRA protocols are
used.

To enable reply messages to be re-transmitted without re-executing operations, a server

must retain the last reply to each client. When RR is used, it is assumed that a request
message is an acknowledgement of the last reply message. Therefore, a reply message
must be held until a subsequent request message arrives from the same client. The use of
storage can be reduced by applying a timeout to the period during which a reply is stored.
The storage requirement for RR = average message size x number of clients that have
made requests since timeout period. When RRA is used, a reply message is held only until
an acknowledgement arrives. When an acknowledgment is lost, the reply message will be
held as for the RR protocol.
 MODULE 5

I. Explain how the container-based philosophy could be adopted to provide migration

transparency for distributed components.

As a reminder, migration (or mobility) transparency is concerned with hiding the

movement of distributed system entities from users or programmers. Containers
operate by intercepting incoming invocations and making a series of calls to
implement the desired level of transparency before optionally passing on the
invocation to the component. To implement migration transparency, a container
can use a location service to map objects (or in this case components) on to
physical locations. (and keep track of them if they move).

II. To what extent may CORBA objects be migrated from one server to another?

CORBA persistent IORs contain the address of the IR used by a group of servers.
That IR can locate and activate CORBA objects within any one of those servers.
Therefore, it will still be able deal with CORBA objects that migrate from one server
in the group to another. But the object adapter name is the key for the
implementation in the IR. Therefore, all of the objects in one server must move
together to another server. This could be modified by allowing groups of objects
within each server to have separate object adapters and to be listed under
different object adapter names in the IR.

Also, CORBA objects cannot move to a server that uses a different IR. It would be
possible for servers to move and to register with a new IR, but then there are issues
related to finding it from the old location domain, which would need to have
forwarding information.
 MODULE 6

I. Describe some of the ways in which conventional email is vulnerable to eavesdropping,

masquerading, tampering, replay and denial of service attacks. Suggest methods by which
email could be protected against each of these forms of attack.

Possible weaknesses for a typical mail system with SMTP delivery and client pickup from
POP or IMAP mail host on a local network:

Weakness Types of attack Remedy

Sender is unauthenticated. Masquerading, denial of service. End-to-end authentication with
digital signatures
Message contents not Tampering, masquerading. End-to-end authentication with
authenticated. digital signatures
Message contents in the clear. Eavesdropping. End-to-end encryption
Delivery and deletion from Masquerading. Kerberos or SSL authentication
POP/IMAP server is of clients.
authenticated only by a login
with password.
Sender’s clock is not guranteed. False dating of messages. Include time certificates from a
trusted time service.

II. Initial exchanges of public keys are vulnerable to man-in-the-middle attacks. Describe as
many defences against it as you can.

✓ Don’t allow employees to use public networks for any confidential work, or
✓ Implement virtual private networks (VPNs) to secure connections from your
business to online applications and enable employees to securely connect to
your internal private network from remote locations.
✓ Ensure sensitive online transactions/logins are secure with HTTPS using
browser plugins like HTTPS Everywhere or Force TLS.
✓ Use the latest version of high-security web browsers such as Chrome,
Internet Explorer, Firefox, or Safari.
✓ Create separate wifi networks for guests, internal use, and business
application data transfers.
✓ Utilize authentication credentials such as tokens and other forms of two-
factor authentication for sensitive accounts.
✓ Secure your email using SSL/TLS to protect messages in transit, and consider
using PGP/GPG encryption to protect them at rest as well.
✓ Install an intrusion detection system (IDS) to monitor your network and alert
you to unusual events like attempts to hijack traffic flow.
✓ Regularly audit and monitor your networks to maintain awareness of normal
and unusual activities.
✓ Educate your employees about common IT security threats and attack
vectors such as those outlined above.