Wednesday 11 October 2017

The site name will be changed from imraan-prrec.blogspot.com to 
imraan-cs.blogspot.com

Any kind of study material please check the Material Tab and Click Contact Us

SPM Material PPTS

Click to download
UNIT I
Conventional Software Management : The waterfall model, conventional software Management performance.
Evolution of Software Economics : Software Economics, pragmatic software cost estimation.
UNIT II
Improving Software Economics : Reducing Software product size, improving software processes, improving team effectiveness, improving automation, Achieving required quality, peer inspections.
The old way and the new : The principles of conventional software engineering, principles of modern software management, transitioning to an iterative process.
UNIT III
Life cycle phases : Engineering and production stages, inception, Elaboration, construction, transition phases.
Artifacts of the process : The artifact sets, Management artifacts, Engineering artifacts, programmatic artifacts. Model based software architectures : A Management perspective and technical perspective.
UNIT IV
Work Flows of the process : Software process workflows, Inter trans workflows.Checkpoints of the Process : Major Mile Stones, Minor Milestones, Periodic status assessments. Iterative Process Planning : Work breakdown structures, planning guidelines, cost and schedule estimating, Interaction planning process, Pragmatic planning.
Project Organizations and Responsibilities : Line-of-Business Organizations, Project Organizations, evolution of Organizations.Process Automation : Automation Building Blocks, The Project Environment.
UNIT V
Project Control and Process instrumentation : The server care Metrics, Management indicators, quality indicators, life cycle expectations pragmatic Software Metrics, Metrics automation. Tailoring the Process : Process dicriminants, Example.
Future Software Project Management : Modern Project Profiles Next generation Software economics, modern Process transitions. Case Study : The Command Center Processing and Display System-Replacement(CCPDS-R)
Reference – Software Project Management – SPM notes pdf – SPM pdf notes – SPM Pdf – SPM Notes
1. Software Project Management, Walker Royce, Pearson Education, 1998
2. Software Project Management, Bob Hughes & Mike Cotterell, fourth edition,Tata Mc- Graw Hill,2006
Text books – Software Project Management – SPM notes pdf – SPM pdf notes – SPM Pdf – SPM Notes
1. Applied Software Project Management, Andrew Stellman & Jennifer Greene,O’Reilly, 2006
2. Head First PMP, Jennifer Greene & Andrew Stellman, O’Reilly,2007
3. Software Engineering Project Managent, Richard H. Thayer & Edward Yourdon, second edition, Wiley India, 2004.
4. Agile Project Management, Jim Highsmith, Pearson education, 2004
5. The art of Project management, Scott Berkun, O’Reilly, 2005.
6. Software Project Management in Practice, Pankaj Jalote, Pearson Education,2002.

Networks AODV

Rushing attack

 Rushing attack is a zero delay attack and more effective when the attacker nearby source or destination node.On-demand routing protocols like AODV and DSR are more vulnerable to this attack, because whenever source node floods the route request packet in the network, an adversary node receives the route request packet and sends without any hop_count update and delay into the network. Whenever the legitimate nodes receive the original source request packets, they are dropped because legitimate nodes,would have already received packet from the attacker and treat the currently received packets as duplicate packets. Thus, adversary is included in active route & disturbs the data forwarding phase. Rushing attack can be taken place at source side or destination side or at the middle.

** The following conditions the rushing attacker is not included in active route
1. When source and destination nodes have direct communication link
2. When source and destination nodes have better route than rushing attackers route
** Rushing attack is more effective when attacker near to source or destination node

Rushing attacks:

 Rushing attacks mainly classified into two types:
1.    Rushing attack followed by jellyfish attack
2.    Rushing attack followed by byzantine attack
Rushing attacker disturbs the data forwarding phase by either jellyfish or byzantine attack.


Rushing attacks implementation in aodv routing protocol

The following scenario consists of 25 nodes. In which 7, 8 and 10 nodes are rushing attacks other nodes are non-malicious.










To create multiple rushing attackers in aodv protocol

·         In aodv.h, the following blue colour lines needs to be added to define rushing attackers

/*
      * History management
      */
    
double               PerHopTime(aodv_rt_entry *rt);

nsaddr_t malicious;




·         In aodv.cc the following blue colour lines needs to be added to initialize the attackers

// To initialize the rushing attackers

int
AODV::command(intargc, const char*const* argv) {
if(argc == 2) {
Tcl&tcl = Tcl::instance();

if(strncasecmp(argv[1], "id", 2) == 0) {
tcl.resultf("%d", index);
return TCL_OK;
    }
                    if(strncasecmp(argv[1], "rushingattack", 13) == 0) {
     malicious= 1000;
        return TCL_OK;
    }
                 

AODV::AODV(nsaddr_t id) : Agent(PT_AODV),
btimer(this), htimer(this), ntimer(this),
rtimer(this), lrtimer(this), rqueue() {
index = id;
seqno = 2;
bid = 1;
  LIST_INIT(&nbhead);
  LIST_INIT(&bihead);
malicious=999;

·         Malicious nodes 7, 8 and 10 generate malicious route requests using following blue colour code


Each rushing attacker do not increase the hop_count and simply broadcast without delay. Other than rushing attackers, they will follow the AODV protocol to broadcast route request

//add blue colour lines in send route request packet

/*
  * Can't reply. So forward the  Route Request
  */

else {
ih->saddr() = index;
ih->daddr() = IP_BROADCAST;
if (malicious==1000)
rq->rq_hop_count += 1;
   // Maximum sequence number seen en route
if (rt) rq->rq_dst_seqno = max(rt->rt_seqno, rq->rq_dst_seqno);
if (malicious==1000)
forward((aodv_rt_entry*) 0, p, 0);
else
forward((aodv_rt_entry*) 0, p, DELAY);
 }


// add the blue colour lines code in forward packet

if (ih->daddr() == (nsaddr_t) IP_BROADCAST) {
 // If it is a broadcast packet
assert(rt == 0);
if ((ch->ptype()==PT_AODV) && (malicious!=1000)) {
     /*
*  Jitter the sending of AODV broadcast packets by 10ms
      */
     Scheduler::instance().schedule(target_, p, 0.01 * Random::uniform());
   } else {

     Scheduler::instance().schedule(target_, p, 0.);  // No jitter
   }
 }

  
·         Rushing Attackers can do two attacks: Byzantine and Jellyfish attacks

/*
  * If the route is up, forward the packet
  */
                                                  
if(rt->rt_flags == RTF_UP) {
assert(rt->rt_hops != INFINITY2);

//Byzantine attack can be done : drop all /selective packets
//                       Modify [or]injectflase packets
//Here,  only dropping packets are considered


if((ch->ptype()!=PT_AODV) && (malicious==1000))
                                                   {
                           if(t < CURRENT_TIME)
                                                   {
                                               t=t+2;
                             drop(p, DROP_RTR_NO_ROUTE);
       }
//Jellyfish attack can be done two ways: delaying packets [or] re-ordering //packets.
//Here, only delaying packets and 0.8 can be varied till the good put is zero

else                                            
forward(rt, p, 0.8); 
 }
else
forward(rt, p, NO_DELAY);
 }

·         Since, all attackers drop the packets due to no route to destination, attackers have to disable the send[error]

The following blue colour lines code disables the send (error)


 // add in route resolve function (AODV::rt_resolve(Packet *p) )
else {
 Packet *rerr = Packet::alloc();
structhdr_aodv_error *re = HDR_AODV_ERROR(rerr);
 /*
  * For now, drop the packet and send error upstream.
  * Now the route errors are broadcast to upstream
  * neighbors - Mahesh 09/11/99
  */    

assert (rt->rt_flags == RTF_DOWN);
re->DestCount = 0;
re->unreachable_dst[re->DestCount] = rt->rt_dst;
re->unreachable_dst_seqno[re->DestCount] = rt->rt_seqno;
re->DestCount += 1;
#ifdef DEBUG
fprintf(stderr, "%s: sending RERR...\n", __FUNCTION__);
#endif
if(malicious==1000) drop(p, DROP_RTR_NO_ROUTE);
else
sendError(rerr, false);

drop(p, DROP_RTR_NO_ROUTE);



To define the rushing attackers in tcl add these lines after node initializations

$ns at 0.0 "[$n5 set ragent_] rushingattack"
$ns at 0.0 "[$n7 set ragent_] rushingattack"
$ns at 0.0 "[$n8 set ragent_] rushingattack"

Above scenario example tcl  file : rushing attacks
Rushing attack aodv.cc file : aodv.cc
                         aodv.h file : aodv.h