Subject: [rrg] Fwd: comments on draft-templin-iron-12.txt

From: Tony Li <[email-masked]>
Date: Thu, 7 Oct 2010 13:38:57 -0700

FYI:

These are the comments from the IRSG review of IRON.

Regards,
Tony

Begin forwarded message:

> From: "Buford, John F (John)" <[email-masked]>
> Date: October 6, 2010 1:21:56 PM PDT
> To: <[email-masked]>, <[email-masked]>, <[email-masked]>
> Cc: "Buford, John F (John)" <[email-masked]>, "John Buford" <[email-masked]>
> Subject: comments on draft-templin-iron-12.txt
> 
> The following are recommended suggestions for improving the ID before it is sent forward.
>  
>  
> * Section 2 Terminology
>  
> Organize the terminology alphabetically and add entries for:
> FIB, IR[CE], IR[VC], IR[VE], IR[VP], IR (IRON Router), VET, and SEAL
>  
> The definition for VPC seems incomplete in that it focuses on
> the management of VPs, and doesn’t include the aspect of
> running an IRON overlay and the various IRs.
>  
> * Section 3 IRON
>  
> “The IRON is manifested through a business model…”
> Suggest re-wording this to:
> “The IRON is manifested through a business model in which each
> Virtual Prefix Company (VPC) owns and manages one or more virtual overlay
> networks comprising … “.  This makes it clearer that a VPC individually
> runs/owns the overlay and not collectively.
>  
> I am not sure why “ … is manifested through a business model …” is relevant.
> Their could be a myriad of business models by which an IRON overlay is
> operated.  Would it be more precise to say here that IRON consists
> of an arbitrary number of IRON overlays each of which may be separately
> operated by different VPCs?
>  
> “customer must have two business relationsships …”  _must_ doesn’t
> seem correct here.  for example, the customer could buy all its
> network services through a broker.
>  
> Somewhere between Fig. 4 and  Fig. 5 it would help to have one
> figure which shows all the IRON elements (IR[CE], IR[VC], IR[VE], IR[VP])
> in a single topology.  In addition, a version of the complete figure for
> a single VPC and at least 2 VPCs would be helpful.
> Currently the first integrated diagram is not until p. 19 of the document.
>  
> p. 9 “Each IR[VE] serves as a customer-facing tunnel endpoint router
> that IR[CE]s form bidirectional tunnels with over the IRON”.  The readability
> of this sentence could be improved, for example,
> Each IR[VE] is customer facing and acts as both a tunnel-endpoint and a router
> for each IR[CE] that is associated with it.
>  
> * Section 4 IRON Organizational Principles
>  
> “The IRON consists of the union all VPC overlay networks worldwide”.
> This seems to preclude the possibility of multiple autonomous IRONs
> that don’t interoperate for various reasons (isolated topology, security).
>  
> Is there a minimial VPC configuration?
> Is there a specific portion of IPv4/v6 address space prefixes that would be
> available to an IRON?
>  
> * Section 5 IRON Initialization
>  
> “Upon startup, the IR[VC] engages in BGP routing exchanges with its
> peers in the IPv4 and IPv6 Internets the same as for any BGP router”.
>  
> Would the existence of many VPCs greatly increase the size of
> BGP routing tables?  Is this a concern in terms of scalability of IRON?
>  
> sec. 5.3 “key infrastructure” => “public key infrastructure”
>  
> It is not clear in sec 5.3 whether there are any customer roaming scenarios
> in which the customer needs to connect to IRON through a foreign but
> closer IR[CE] which would require authentication between two VPCs.  
> The mobility section later seems to focus on IR[CE] mobility versus customer mobility.
>  
> * Section 7 Additional Considerations
>  
> Suggest cross-reference to Appendix B Scaling Considerations could go here.
>  
> * Section 10 Security Considerations
>  
> This section should be expanded to elaborate on IRON-specific vulnerabilities,
> which seem to include:
> 1) VPC impersonation to EUN and to other VPCs
> 2) corrupted advertisement of IPv4/6 prefixes into BGP routers of peers
> 3) impersonation of IR[CE], IR[VC], IR[VE] by rogue attacker
> 4) pollution of a VPCs internal BGP routing tables
> 5) DOS attacks
>  
>  
> Minor editorial
> p. 4 deaggregation => disaggregation
>  
>  
>  
>  
>  
>  
>  
>  
> John F. Buford, Ph.D.
> Research Scientist, Avaya Labs Research
> 233 Mount Airy Rd  Room 2A11
> Basking Ridge, NJ 07920-2311
>  
> Office: 908-848-5675 or 908-696-5296
> Mobile: 908-432-1595
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Oct 2010 14:03:16 -0700

Hi John,

Thank you for your helpful comments. Please see below for my
responses to your recommendations:

Regards - Fred
[email-masked]<mailto:[email-masked]>

* Section 2 Terminology
- I will organize the terminology per your suggestion. Also, I would
  like to take this opportunity to replace the cryptic "IR[*]" terms
  with well know terms that correspond to other works. In particular,
  I would like to rename "IR[CE]" to "IRON Client Router", "IR[VE]"
  to "IRON Serving Router" and "IR[VC]" to "IRON Relay Router".

* Section 3 IRON
- I will reword the sentence beginning "The IRON is manifested through
  a business model..." per your suggestion.
- I agree that it would be more precise to say that "IRON consists of an
  arbitrary number of IRON overlays each of which may be separately
  operated by different VPCs". I will make this change.
- I will mention that the customer could buy all its network services
  through a broker.
- I will add a new figure between figures 4 and 5 showing all IRON
  elements. I wasn't exactly sure what you meant by "a version of the
  complete figure for a single VPC and at least 2 VPCs", however. Can
  you say mor about this?
- I will fix the P. 9 wording regarding IR[VE] as a customer-facing router.

* Section 4 IRON Organizational Principles
- I will add supporting text to address your questions on "Is there a minimial
  VPC configuration?" and "Is there a specific portion of IPv4/v6 address space
  prefixes that would be available to an IRON?"

* Section 5 IRON initialization
- to your questions on: "Would the existence of many VPCs greatly increase
  the size of  BGP routing tables?" and "Is this a concern in terms of scalability
  of IRON?" - I would answer "No" to both of those. From the perspective of
  BGP, a VPC is analogous to a major enterprise network which advertises
  only a small number of (PI) prefixes into the BGP. The number of VPs
  advertised by each VPC will therefore be very small - perhaps only one or
  a few IPv6 ::/20's or so. Please let me know if you think you may be seeing
  a scaling limitation that I may be missing.

* Section 5.3
- I will change "key infrastructure" to "public key infrastructure"
- In terms of roaming scenarios, the cutomer EUN travels together
  with the (mobile) IR[CE] router. So, the IR[CE] is the aggregation point
  for the EUN, and the EUN is therefore dependent on its IR[CE]. Note
  that it is also possible for an EUN to have multiple IR[CE]s that attach
  it to the IRON, but those IR[CE]s must coordinate with one another to
  avoid network partitions. Does this answer your question and/or do you
  think more text needs to be added?

* Section 7 Additional Considerations
- I will add a cross-reference to appendix B

* Section 10 Security Considerations
- I will elaborate on the items you listed under IRON-specific vulnerabilities.

* Minor editorial
- I will change deaggregation => disaggregation

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Li
Sent: Thursday, October 07, 2010 1:39 PM
To: [email-masked]
Subject: [rrg] Fwd: comments on draft-templin-iron-12.txt

FYI:

Regards,
Tony

Begin forwarded message:

From: "Buford, John F (John)" <[email-masked]<mailto:[email-masked]>>
Date: October 6, 2010 1:21:56 PM PDT
To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Cc: "Buford, John F (John)" <[email-masked]<mailto:[email-masked]>>, "John Buford" <[email-masked]<mailto:[email-masked]>>
Subject: comments on draft-templin-iron-12.txt

The following are recommended suggestions for improving the ID before it is sent forward.
* Section 2 Terminology
Organize the terminology alphabetically and add entries for:
FIB, IR[CE], IR[VC], IR[VE], IR[VP], IR (IRON Router), VET, and SEAL
The definition for VPC seems incomplete in that it focuses on
the management of VPs, and doesn't include the aspect of
running an IRON overlay and the various IRs.
* Section 3 IRON
"The IRON is manifested through a business model..."
Suggest re-wording this to:
"The IRON is manifested through a business model in which each
Virtual Prefix Company (VPC) owns and manages one or more virtual overlay
networks comprising ... ".  This makes it clearer that a VPC individually
runs/owns the overlay and not collectively.
I am not sure why " ... is manifested through a business model ..." is relevant.
Their could be a myriad of business models by which an IRON overlay is
operated.  Would it be more precise to say here that IRON consists
of an arbitrary number of IRON overlays each of which may be separately
operated by different VPCs?
"customer must have two business relationsships ..."  _must_ doesn't
seem correct here.  for example, the customer could buy all its
network services through a broker.
Somewhere between Fig. 4 and  Fig. 5 it would help to have one
figure which shows all the IRON elements (IR[CE], IR[VC], IR[VE], IR[VP])
in a single topology.  In addition, a version of the complete figure for
a single VPC and at least 2 VPCs would be helpful.
Currently the first integrated diagram is not until p. 19 of the document.
p. 9 "Each IR[VE] serves as a customer-facing tunnel endpoint router
that IR[CE]s form bidirectional tunnels with over the IRON".  The readability
of this sentence could be improved, for example,
Each IR[VE] is customer facing and acts as both a tunnel-endpoint and a router
for each IR[CE] that is associated with it.
* Section 4 IRON Organizational Principles
"The IRON consists of the union all VPC overlay networks worldwide".
This seems to preclude the possibility of multiple autonomous IRONs
that don't interoperate for various reasons (isolated topology, security).
Is there a minimial VPC configuration?
Is there a specific portion of IPv4/v6 address space prefixes that would be
available to an IRON?
* Section 5 IRON Initialization
"Upon startup, the IR[VC] engages in BGP routing exchanges with its
peers in the IPv4 and IPv6 Internets the same as for any BGP router".
Would the existence of many VPCs greatly increase the size of
BGP routing tables?  Is this a concern in terms of scalability of IRON?
sec. 5.3 "key infrastructure" => "public key infrastructure"
It is not clear in sec 5.3 whether there are any customer roaming scenarios
in which the customer needs to connect to IRON through a foreign but
closer IR[CE] which would require authentication between two VPCs.
The mobility section later seems to focus on IR[CE] mobility versus customer mobility.
* Section 7 Additional Considerations
Suggest cross-reference to Appendix B Scaling Considerations could go here.
* Section 10 Security Considerations
This section should be expanded to elaborate on IRON-specific vulnerabilities,
which seem to include:
1) VPC impersonation to EUN and to other VPCs
2) corrupted advertisement of IPv4/6 prefixes into BGP routers of peers
3) impersonation of IR[CE], IR[VC], IR[VE] by rogue attacker
4) pollution of a VPCs internal BGP routing tables
5) DOS attacks
Minor editorial
p. 4 deaggregation => disaggregation
John F. Buford, Ph.D.
Research Scientist, Avaya Labs Research
233 Mount Airy Rd  Room 2A11
Basking Ridge, NJ 07920-2311
Office: 908-848-5675 or 908-696-5296
Mobile: 908-432-1595

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Oct 2010 08:28:01 -0700

Hi John,

To the points you raised:

> JB> My thought was that in the single VPC case,  the CEs, VEs, VC
> JB> belong to one VPC and multiple EUNs can route to each other without
> JB> sending packets over the Internet, whereas in the multi-VPC case, there is
> JB> potentially routing over the Internet between hosts that are connected to the CEs
> JB> of two different VPCs, e.g., Fig 6 could be construed as a 2-VPC case.

With IRON, packets from host A behind IR[CE](A) destined to host B behind
IR[CE](B) will always go through IR[VE](B) (i.e., IR[CE](B)'s Server) - they will
never go directly from IR[CE](A) to IR[CE](B). There are two reasons for this.
First, IR[CE](B) may be reachable over multiple diverse paths and IR[VE](B)
provides a control point for inbound traffic engineering. Second, if IR[CE](B)
moves to a new Server, it need not send updates to a potentially long list of
correspondents; it only needs to connect to the new Server and tell the old
server that it has departed.

About Figure 6, it works the same whether IR[CE](A) and IR[CE](B) are in
the same VPC overlay network or in different VPC overlay networks. In both
cases, initial packets need to be bounced off an IR[VC] before redirects
eliminate unnecessary hops. Does that clarify?

> JB> Suppose in Fig 6, host A moves from EUN A which is operated by VPC-1
> JB> and roams to EUN B which is operated by VPC-2.  This seems to be
> JB> a different case than when the IR[CE] moves.  Is this covered by host A
> JB> having separate credentials with EUN A and B?

This is a case of host mobility and not network mobility (which is what
IRON addresses). In the case of host mobility, host A can either deprecate
its EUN A address and configure an EUN B address, or it can retain its
EUN A address as a care-of address and use something like Mobile IP.
I left host mobility as out of scope for this work since it is already covered
under other standards. Maybe I could say somewhere in the intro that host
mobility is out of scope?

> JB> Also, it seems that the scope of IRON is unicast flows, since multicast isn't
> JB> mentioned in the ID.

Also out of scope for this work. I'll mention this in the intro as well.

Thanks - Fred

________________________________
From: John Buford [mailto:[email-masked]]
Sent: Thursday, October 07, 2010 6:42 PM
To: Templin, Fred L; 'Buford, John F (John)'
Cc: 'Tony Li'; [email-masked]; [email-masked]; 'John Buford'
Subject: RE: [rrg] Fwd: comments on draft-templin-iron-12.txt

Hi Fred,
Comments inline.
Regards,
John

________________________________
From: Templin, Fred L [mailto:[email-masked]]
Sent: Thursday, October 07, 2010 5:03 PM
To: Buford, John F (John)
Cc: Tony Li; [email-masked]; John Buford; [email-masked]
Subject: RE: [rrg] Fwd: comments on draft-templin-iron-12.txt

Hi John,

Regards - Fred

* Section 2 Terminology

JB> ok

* Section 3 IRON

JB> My thought was that in the single VPC case,  the CEs, VEs, VC
JB> belong to one VPC and multiple EUNs can route to each other without
JB> sending packets over the Internet, whereas in the multi-VPC case, there is
JB> potentially routing over the Internet between hosts that are connected to the CEs
JB> of two different VPCs, e.g., Fig 6 could be construed as a 2-VPC case.

* Section 5.3

JB> Suppose in Fig 6, host A moves from EUN A which is operated by VPC-1
JB> and roams to EUN B which is operated by VPC-2.  This seems to be
JB> a different case than when the IR[CE] moves.  Is this covered by host A
JB> having separate credentials with EUN A and B?
JB> Also, it seems that the scope of IRON is unicast flows, since multicast isn't
JB> mentioned in the ID.

* Minor editorial

FYI:

Regards,
Tony

Begin forwarded message:

---

From: "John Buford" <[email-masked]>
Date: Thu, 7 Oct 2010 21:42:00 -0400

Hi Fred,
Comments inline.
Regards,
John

  _____  

Hi John,

Regards - Fred
[email-masked]
 
* Section 2 Terminology
 
JB> ok 
 
* Section 3 IRON

  through a broker.

  you say mor about this?

JB> sending packets over the Internet, whereas in the multi-VPC case, there
is

JB> potentially routing over the Internet between hosts that are connected
to the CEs

- I will add supporting text to address your questions on "Is there a
minimial

  VPC configuration?" and "Is there a specific portion of IPv4/v6 address
space

  the size of  BGP routing tables?" and "Is this a concern in terms of
scalability

  a few IPv6 ::/20's or so. Please let me know if you think you may be
seeing

* Section 5.3

JB> Also, it seems that the scope of IRON is unicast flows, since multicast
isn't

JB> mentioned in the ID.

- I will elaborate on the items you listed under IRON-specific
vulnerabilities.

* Minor editorial

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony
Li
Sent: Thursday, October 07, 2010 1:39 PM
To: [email-masked]
Subject: [rrg] Fwd: comments on draft-templin-iron-12.txt

FYI: 

Regards,
Tony

Begin forwarded message:

Cc: "Buford, John F (John)" <[email-masked]>, "John Buford"
<[email-masked]>

The following are recommended suggestions for improving the ID before it is
sent forward.

* Section 2 Terminology

* Section 3 IRON

"The IRON is manifested through a business model."

networks comprising . ".  This makes it clearer that a VPC individually

I am not sure why " . is manifested through a business model ." is relevant.

"customer must have two business relationsships ."  _must_ doesn't

that IR[CE]s form bidirectional tunnels with over the IRON".  The
readability

Each IR[VE] is customer facing and acts as both a tunnel-endpoint and a
router

available to an IRON?

The mobility section later seems to focus on IR[CE] mobility versus customer
mobility.

This section should be expanded to elaborate on IRON-specific
vulnerabilities,

which seem to include:

5) DOS attacks

Minor editorial 

 

John F. Buford, Ph.D.

Mobile: 908-432-1595

---

From: "Buford, John F (John)" <[email-masked]>
Date: Fri, 8 Oct 2010 09:35:19 -0600

Hi Fred,

Regarding Fig 6, yes that is clear.

Regarding host mobility and multicast being out of scope,

a statement to that effect seems sufficient.

Thanks,

John

From: Templin, Fred L [mailto:[email-masked]] 
Sent: Friday, October 08, 2010 11:28 AM
To: John Buford; Buford, John F (John)
Cc: 'Tony Li'; [email-masked]; [email-masked]
Subject: RE: [rrg] Fwd: comments on draft-templin-iron-12.txt

Hi John,

> JB> of two different VPCs, e.g., Fig 6 could be construed as a 2-VPC
case.

With IRON, packets from host A behind IR[CE](A) destined to host B
behind

IR[CE](B) will always go through IR[VE](B) (i.e., IR[CE](B)'s Server) -
they will

never go directly from IR[CE](A) to IR[CE](B). There are two reasons for
this.

First, IR[CE](B) may be reachable over multiple diverse paths and
IR[VE](B)

provides a control point for inbound traffic engineering. Second, if
IR[CE](B)

moves to a new Server, it need not send updates to a potentially long
list of

correspondents; it only needs to connect to the new Server and tell the
old

the same VPC overlay network or in different VPC overlay networks. In
both

IRON addresses). In the case of host mobility, host A can either
deprecate

I left host mobility as out of scope for this work since it is already
covered

under other standards. Maybe I could say somewhere in the intro that
host

Thanks - Fred

	Hi Fred,

	Comments inline.

	Regards,

	John

	Hi John,

	Regards - Fred

	* Section 2 Terminology

	- I will organize the terminology per your suggestion. Also, I
would

	  like to take this opportunity to replace the cryptic "IR[*]"
terms

	  with well know terms that correspond to other works. In
particular,

	  I would like to rename "IR[CE]" to "IRON Client Router",
"IR[VE]"

	JB> ok 

	* Section 3 IRON

	- I will reword the sentence beginning "The IRON is manifested
through

	- I agree that it would be more precise to say that "IRON
consists of an 

	  arbitrary number of IRON overlays each of which may be
separately

	- I will mention that the customer could buy all its network
services

	  through a broker.

	- I will add a new figure between figures 4 and 5 showing all
IRON

	  elements. I wasn't exactly sure what you meant by "a version
of the

	  complete figure for a single VPC and at least 2 VPCs",
however. Can

	  you say mor about this?

	- I will fix the P. 9 wording regarding IR[VE] as a
customer-facing router. 

	JB> My thought was that in the single VPC case,  the CEs, VEs,
VC

	JB> belong to one VPC and multiple EUNs can route to each other
without

	JB> sending packets over the Internet, whereas in the multi-VPC
case, there is

	JB> potentially routing over the Internet between hosts that are
connected to the CEs

	JB> of two different VPCs, e.g., Fig 6 could be construed as a
2-VPC case. 

	- I will add supporting text to address your questions on "Is
there a minimial

	  VPC configuration?" and "Is there a specific portion of
IPv4/v6 address space

	- to your questions on: "Would the existence of many VPCs
greatly increase

	  the size of  BGP routing tables?" and "Is this a concern in
terms of scalability

	  of IRON?" - I would answer "No" to both of those. From the
perspective of

	  BGP, a VPC is analogous to a major enterprise network which
advertises

	  only a small number of (PI) prefixes into the BGP. The number
of VPs

	  advertised by each VPC will therefore be very small - perhaps
only one or

	  a few IPv6 ::/20's or so. Please let me know if you think you
may be seeing

	* Section 5.3

	- I will change "key infrastructure" to "public key
infrastructure"

	- In terms of roaming scenarios, the cutomer EUN travels
together

	  with the (mobile) IR[CE] router. So, the IR[CE] is the
aggregation point

	  for the EUN, and the EUN is therefore dependent on its IR[CE].
Note

	  that it is also possible for an EUN to have multiple IR[CE]s
that attach

	  it to the IRON, but those IR[CE]s must coordinate with one
another to

	  avoid network partitions. Does this answer your question
and/or do you

	JB> Suppose in Fig 6, host A moves from EUN A which is operated
by VPC-1

	JB> and roams to EUN B which is operated by VPC-2.  This seems
to be

	JB> a different case than when the IR[CE] moves.  Is this
covered by host A

	JB> Also, it seems that the scope of IRON is unicast flows,
since multicast isn't

	JB> mentioned in the ID.

	* Minor editorial

		

		From: [email-masked] [mailto:[email-masked]]
On Behalf Of Tony Li
		Sent: Thursday, October 07, 2010 1:39 PM
		To: [email-masked]
		Subject: [rrg] Fwd: comments on
draft-templin-iron-12.txt

		FYI: 

		Regards,

		Tony

		Begin forwarded message:

		To: <[email-masked]>, <[email-masked]>, <
[email-masked]>

		Cc: "Buford, John F (John)" <[email-masked]>, "John
Buford" <[email-masked]>

		

		The following are recommended suggestions for improving
the ID before it is sent forward.

		* Section 2 Terminology

		Organize the terminology alphabetically and add entries
for:

		FIB, IR[CE], IR[VC], IR[VE], IR[VP], IR (IRON Router),
VET, and SEAL

		The definition for VPC seems incomplete in that it
focuses on

		* Section 3 IRON

		"The IRON is manifested through a business model in
which each

		Virtual Prefix Company (VPC) owns and manages one or
more virtual overlay

		networks comprising ... ".  This makes it clearer that a
VPC individually

		I am not sure why " ... is manifested through a business
model ..." is relevant.

		Their could be a myriad of business models by which an
IRON overlay is

		operated.  Would it be more precise to say here that
IRON consists

		of an arbitrary number of IRON overlays each of which
may be separately

		"customer must have two business relationsships ..."
_must_ doesn't

		seem correct here.  for example, the customer could buy
all its

		Somewhere between Fig. 4 and  Fig. 5 it would help to
have one

		figure which shows all the IRON elements (IR[CE],
IR[VC], IR[VE], IR[VP])

		in a single topology.  In addition, a version of the
complete figure for

		Currently the first integrated diagram is not until p.
19 of the document.

		p. 9 "Each IR[VE] serves as a customer-facing tunnel
endpoint router

		that IR[CE]s form bidirectional tunnels with over the
IRON".  The readability

		Each IR[VE] is customer facing and acts as both a
tunnel-endpoint and a router

		"The IRON consists of the union all VPC overlay networks
worldwide".

		This seems to preclude the possibility of multiple
autonomous IRONs

		that don't interoperate for various reasons (isolated
topology, security).

		Is there a specific portion of IPv4/v6 address space
prefixes that would be

		available to an IRON?

		"Upon startup, the IR[VC] engages in BGP routing
exchanges with its

		peers in the IPv4 and IPv6 Internets the same as for any
BGP router".

		Would the existence of many VPCs greatly increase the
size of 

		BGP routing tables?  Is this a concern in terms of
scalability of IRON?

		sec. 5.3 "key infrastructure" => "public key
infrastructure"

		It is not clear in sec 5.3 whether there are any
customer roaming scenarios

		in which the customer needs to connect to IRON through a
foreign but

		closer IR[CE] which would require authentication between
two VPCs.  

		The mobility section later seems to focus on IR[CE]
mobility versus customer mobility.

		Suggest cross-reference to Appendix B Scaling
Considerations could go here.

		This section should be expanded to elaborate on
IRON-specific vulnerabilities,

		which seem to include:

		2) corrupted advertisement of IPv4/6 prefixes into BGP
routers of peers

		3) impersonation of IR[CE], IR[VC], IR[VE] by rogue
attacker

		5) DOS attacks

		Minor editorial 

		 

		 

		John F. Buford, Ph.D.

		Mobile: 908-432-1595