Subject: Re: Secure BGP -- Internet Drafts
From: Curtis Villamizar <[email-masked]>
To: "Benjamin Black" <[email-masked]>
Cc: "Vijay Gill" <[email-masked]>, [email-masked], [email-masked]
Date: Fri, 28 Jan 2000 19:07:59 -0500

In message <[email-masked]>, "Benjamin Black" writes
:
> >
> > The algorithm cost is based on prefixes, if the cost of the computation
> > based on prefix growth is less than Moore's law, there isn't a problem.
> >
> 
> It is actually proportional to the number of prefixes multiplied by the
> average AS path length as the computations are carried out for each AS in
> the path.
> 
> Ben

Minor point - Its the number of unique prefix and advertising AS
advertised to the router via EBGP times the average AS path length.
If the number of peer AS grows and/or the average AS path length
grows, then the amount of computation grows even if the number of
prefixes remains constant.

Processors are getting faster but if BGP convergence time is already
noticably slowed when simply checking prefixes against a list (where
search is roder log(N) unless the implementation is severely broken),
then there is some question as to whether the additional cryptographic
processing would be a welcome change.

When a BGP update arrives it can have about 500 prefixes.  A list of
all prefixes that you might consider taking from a given peer is
generally on the order of 10,000 entries or less.  Looking at a linked
list you'd do do 500*10,000 or 5,000,000 operations per BGP update.
This would kill routers so no one does this anymore (I hope).  With a
patricia trie search, expected are 500*14 comparisons (14 is expected
depth of a perfectly balanced trie of 16,384).  For each peer
providing full routes, that would be 700,000 comparisons.  For 50 peer
AS, that would be 35,000,000.  This is a few seconds of processing.

With SBGP you have to find the entry for a prefix to get the public
key for that prefix (essentially verifying that the origin AS was
expected for that prefix), then apply the public key for each AS along
the AS path.  The AS path is the same for the whole BGP update, but
prefixes must be signed individually.  The cryptographic operation is
likely to be computationally more expensive than the 14 comparisons
needed to find an entry.

My only point in bringing this up (again) is that if looking up a
prefix in a tree has a noticable effect on convergence time, then the
cryptographic computation will have a greater effect on convergence
time.  This may still be acceptable, particularly as processors get
faster and/or additional processors assist in cryptographic
computation, but it might be worth noting.

Aggregation is problematic since signatures cannot be aggregated.
They have to be tossed or also kept in deaggregated form.  If they are
kept in deaggregated form, this begs the question as to whether the
router needs to verify the signatures chains within the aggregate and
what it does if some are valid but some are not.  I'm assuming that
the deaggregated signatures can be tossed and verification of
aggregates is the only requirement.

There is still another issue of current practice.  If we accept that
verification of aggregates is sufficient and further propose that in
some (most) uses verification of the advertising AS is sufficient, we
need to seriously consider whether incremental change to current
practice (maybe not widely enough used practice) is a better approach.
X.509 may be no better than the IRR as a means of distribution in this
application and there is at least limited use of the IRR.
Verification of peer through BGP MD5 and verification of the prefix,
advertising AS, and optionally AS path verification is a step in the
direction of SBPG and requires only a MD5 digest across the entire
BGP4 packet and check against the IRR (through configured policy lists
or the near real time mirror if a router vendor decided to do that).

[Aside: Of course, I'd rather see the use of the authentication and
authorization model in RFC2725 "Routing Policy System Security" in the
IRR and use of the distribution (out of band distribution as far as
the routers are concerned) using draft-ietf-rps-dist-06.txt "Routing
Policy System Replication" for distribution of policy and the prefix
lists to the routers using the light weight mirror capability
described in rps-dist (see Appendix A.4 "Transaction Redistribution").
But I might be biased about this.]

I don't see these things as barriers to publications as experimental.
The document does acknowledge that it is proposing a computaionally
intensive solution.  A bit of analysis in an appendix might be helpful
but not necessarily a requirement.

Minor question to the authors: In configuration what does "Per peer,
no not send attestations" mean?  btw- The policy section is a bit thin. :)

speaking on behalf of myself,

Curtis

From: Alexey Zinin <[email-masked]>
Subject: Re: BGP:tie-breaking algorithm enhancement proposal
To: [email-masked] (Alvaro Retana)
Date: Fri, 28 Jan 100 13:26:15 +0300 (MSK)
Cc: [email-masked]
Sender: [email-masked]

Alvaro:

I know of at least one IX which has suffered and still
is suffering from this change in the path selection
process (I was handling this case).

I think what you propose may be a useful enhancement, but any
changes to the route selection algo must be implemented
with a configuration option, allowing to revert to standard
behavior, since people may (and actually do) rely on the Router-ID
as the determinating factor.

Alex.

> 
> 
> The current BGP4 draft (draft-ietf-idr-bgp4-09) reads:
> 
> -------------------------------------------------------------------
> 9.1.2.1 Breaking Ties (Phase 2)
> .....
>    The tie-breaking algorithm begins by considering all equally
>    preferable routes and then selects routes to be removed from
>    consideration.  The algorithm terminates as soon as only one route
>    remains in consideration.  The criteria must be applied in the order
>    specified.
> 
> .....
>       c) If at least one of the candidate routes was received from an
>       external peer in a neighboring autonomous system, remove from
>       consideration all routes which were received from internal peers.
> 
>       d) Remove from consideration all routes other than the route that
>       was advertised by the BGP speaker whose BGP Identifier has the
>       lowest value.
> -------------------------------------------------------------------
> 
> I would like to propose the following enhancement (to be put in place of
> the last step listed above):
> 
>       d) If the remaining routes are all external, remove from consideration 
>       all routes except the one that was received first and any others with 
>       the same BGP Identifier as it (the one received first).
> 
>       e) Remove from consideration all routes other than the ones advertised 
>       by the BGP speaker whose BGP Identifier has the lowest value.
> 
> 
> 
> In summary, the change will allow a BGP speaker to keep the oldest
> external route as the best path, if all the other conditions are the same.  
> Except for the case where more than one route is received from the same
> eBGP peer.
> 
> In keeping the oldest external, the number of unnecesary routing updates
> can be lowered.  Note that by advertising a new bestpath (if all the
> attributes, except the BGP Identifier, are the same), the exit point will
> not change.
> 
> In the case where the BGP Identifier is the same, then the "normal"
> procedure is used.
> 
> Any/all comment are welcome. :-)
> 
> Alvaro.
> 
> 
> 

Date: Fri, 28 Jan 2000 03:08:53 -0500 (EST)
From: Vijay Gill <[email-masked]>
To: Bruce Cole <[email-masked]>
Cc: [email-masked]
Subject: Re: Secure BGP -- Internet Drafts
Sender: [email-masked]

On Thu, 27 Jan 2000, Bruce Cole wrote:

> > There isn't any real reason why the current CPU trends cannot be imported
> > into the routers.  As someone at a promising local startup said, we can
> > walk down to Fry's and pick up 2x the cpu every year or so.
> 
> Last I remember from the IDR working group meeting in Orlando, these
> proposed protocol extensions impacted BGP convergence time severely.
> I believe it was admitted that it would take ~24 hours for BGP to
> be able to receive full routing information.
> 
> We use off the shelf CPUs in our systems, but I doubt that we could
> yet provide such a feature without significant impact to convergence
> time.  If that is no longer true, I'd like to see someone report the
> numbers.

Given intrumentation of some BGP implementations that I am working on at
UUNET, I'd have to agree. The key result (which was fairly unexpected by
most people) was that the _computation_ was not the bottleneck, but
rather, the dissemination and convergence as a whole.  Given you are under
NDA with us, I could probably send you a copy of the scaling analysis.

> In the mean time, Juniper Networks does not want to consider this draft,
> and doesn't want to see it an IDR working group draft.

I concurr.

/vijay

Reply-To: "Benjamin Black" <[email-masked]>
From: "Benjamin Black" <[email-masked]>
To: "Susan Hares" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Secure BGP -- Internet Drafts
Date: Thu, 27 Jan 2000 19:50:38 -0800
Sender: [email-masked]

Could anyone comment on how SBGP is superior to generating prefix and AS
path lists based on registries and using SSL between BGP peers?  It appears
to me that SBGP offers no significant benefit, but incurs significant costs
in changes to BGP implementations and increased demands on routers.

Ben

>
> Here are a few drafts on BBN's work on Secure BGP.
> Should these drafts become IDR working group drafts?
> Please send comments to the list.
>
>
> Sue Hares
>
> --------------
>
> Message-Id: <v04011719b43ec7b6bf7f@[171.78.30.20]>
> Date: Fri, 29 Oct 1999 00:14:15 -0400
> To: [email-masked]
> From: Karen Seo <[email-masked]>
> Subject: Secure BGP -- Internet Drafts
> Cc: [email-masked]
>
> Hello,
>
> Over the past year, we (Charlie Lynn and Luis Sanchez) have made
> presentations on our Secure BGP (S-BGP) work at several IDR WG sessions.
We
> would now like to submit two internet drafts on Secure BGP (see below) to
> the IDR working group for review/feedback and consideration for adoption
> as IDR working group documents. We have sent both to the IETF secretariat
> and also put copies at our web site:
>         http://www.ir.bbn.com/projects/sbgp/
>
> It should be noted that we have prepared these (individual submission)
> I-Ds, based on our experience with a prototype implementation and initial
> testing, including some performance measurements.  Thus, we feel that the
> design is now sufficiently mature to warrant requesting that the IDR WG
> formally consider adopting it as the basis for a work item, oriented
> towards providing high quality security for BGP.
>
> Please let us know if you have questions/comments.  Thank you,
> Karen
>
> 1. Secure BGP (S-BGP) -- Charles Lynn, Joanne Mikkelson, Karen Seo,
>    draft-clynn-s-bgp-protocol-00.txt, October 1999.
>
>    Abstract
>
>    The Border Gateway Protocol (BGP), which is used to distribute routing
>    information between autonomous systems (ASes), is a critical component
>    of the Internet's routing infrastructure. It is highly vulnerable to a
>    variety of malicious attacks both in theory and in practice, due to
>    the lack of a scalable means of verifying the authenticity and
>    legitimacy of BGP control traffic. This document is a protocol
>    specification for Secure BGP (S-BGP), an extension to BGP-4. S-BGP
>    adheres to the principle of least privilege and uses countermeasures
>    that create an authentication and authorization system that addresses
>    most of the security problems associated with BGP. To facilitate
>    adoption and deployment, S-BGP is designed to minimize the overhead
>    (processing, bandwidth, storage) added by its
>
> 2. X.509 Extensions for Authorization of IP Addresses, AS Numbers, and
>    Routers within an AS -- Charles Lynn, draft-clynn-bgp-x509-auth-01.txt,
>    October 1999.
>
>    Abstract
>
>    This document defines three X.509 v3 Certificate Extensions. The
>    first binds a list of IP Address blocks to the public key of the
>    subject of a certificate. The second binds a list of Autonomous
>    System Numbers to the public key of the subject of a certificate.
>    The third binds a BGP Router Identifier and an Autonomous System
>    Number to the public key of the subject of a certificate. Third
>    parties, e.g., BGP routers, may use these certificates to verify
>    that the holder of the private key corresponding to the public
>    key in the certificate has been properly authorized to use
>    resources specified in the certificate extension.
>
>
>
>

To: Vivek Menezes <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Problems with Rfc 2439 
Date: Thu, 27 Jan 2000 22:54:33 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Vivek 
Menezes writes:
> Hi,
> I have found a few problems in the calculations in rfc 2439 "BGP route flap
> damping". Could the authors please make the changes.
> 
> 1. page 18. calculation of the value of ceiling should be
> 
> ceiling = reuse * (exp (( T-hold/decay-half-life) * log(2) ))
> 
> 2. page 20 calculation of reuse-index-array[j] should be
> 
> reuse-index-array[j] = integer ((decay-half-life / reuse-time-granularity) *
> log( 1 / (1 + (j/scale-factor))) / log(1/2))
> 
> The value of reuse is not required in the above equation.
> 
> 3. The lines in the rfc following the above equation on page 20 should read
> 
> "Divide the current figure of merit by the reuse". and not "Divide the
> current figure of merit by the cutoff".
> 
> Thanks
> 
> Vivek Menezes. 

Thanks.  I'll take a look at these.

Curtis

Reply-To: "Benjamin Black" <[email-masked]>
From: "Benjamin Black" <[email-masked]>
To: "Vijay Gill" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Secure BGP -- Internet Drafts 
Date: Thu, 27 Jan 2000 19:48:22 -0800
Sender: [email-masked]

>
> The algorithm cost is based on prefixes, if the cost of the computation
> based on prefix growth is less than Moore's law, there isn't a problem.
>

It is actually proportional to the number of prefixes multiplied by the
average AS path length as the computations are carried out for each AS in
the path.

Ben

To: Vijay Gill <[email-masked]>
Cc: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Secure BGP -- Internet Drafts 
Date: Thu, 27 Jan 2000 16:06:51 -0700
Sender: [email-masked]

> There isn't any real reason why the current CPU trends cannot be imported
> into the routers.  As someone at a promising local startup said, we can
> walk down to Fry's and pick up 2x the cpu every year or so.
> 
> cost is based on prefixes, if the cost of the computation
> based on prefix growth is less than Moore's law, there isn't a problem.

Again, I'm not disagreeing with anything.  I'd love to see data detailing 
performance of an actual implementation, one which completely accounts for a 
typical deployment in an ISP network.  I'll gladly provide anyone interested 
in performing these simulations with a perspective of typical number of 
iBGP/eBGP peers and routes your simulations.

-danny

Date: Thu, 27 Jan 2000 17:54:57 -0500 (EST)
From: Vijay Gill <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Secure BGP -- Internet Drafts 
Sender: [email-masked]

On Thu, 27 Jan 2000, Danny McPherson wrote:

> 
> I seem to recall Curtis, coincidentally now with Avici, voicing some concerns 
> at an IDR WG meeting well over a year ago [somewhere] when the BBN folks 
> presented the previously referenced drafts.  His concerns, regarding CPU 
> resources required for update processing, as well the model proposed 
> offsetting the benefits of aggregation, were shared among many providers, and 
> still stand today.  I think Ben's hit on the larger part of the issues that 
> folks who would actually deploy this would/should be concerned with.

There isn't any real reason why the current CPU trends cannot be imported
into the routers.  As someone at a promising local startup said, we can
walk down to Fry's and pick up 2x the cpu every year or so.

> While I'm in complete agreement that something absolutely has to be done in 
> this area, I'm not sure if this is the right approach.  Though, because I 
> currently don't have a better answer for this "psuedo in-band" UPDATE 
> authentication, I guess I can't complain much.  Then again, modeling an 
> implementation with this approach and providing some projections as to what 
> resources would be required will probably tip the scales in one direction or 
> the other.

The algorithm cost is based on prefixes, if the cost of the computation
based on prefix growth is less than Moore's law, there isn't a problem.

/vijay

From: Vivek Menezes <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Problems with Rfc 2439
Date: Thu, 27 Jan 2000 14:51:34 -0800
Sender: [email-masked]

Hi,
I have found a few problems in the calculations in rfc 2439 "BGP route flap
damping". Could the authors please make the changes.

1. page 18. calculation of the value of ceiling should be

ceiling = reuse * (exp (( T-hold/decay-half-life) * log(2) ))

2. page 20 calculation of reuse-index-array[j] should be

reuse-index-array[j] = integer ((decay-half-life / reuse-time-granularity) *
log( 1 / (1 + (j/scale-factor))) / log(1/2))

The value of reuse is not required in the above equation.

3. The lines in the rfc following the above equation on page 20 should read

"Divide the current figure of merit by the reuse". and not "Divide the
current figure of merit by the cutoff".

Thanks

Vivek Menezes. 

Subject: Re: Secure BGP -- Internet Drafts
Date: Thu, 27 Jan 2000 14:49:15 -0500
From: Hank Zannini <[email-masked]>
To: "Avi Freedman" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

>
>That's true, but Randy is still correct.   Think of it as the groundwork -
>Randy is pointing out one of the rules that enhances the ability of the
>individuals involved in working groups to function more smoothly.
>
>Avi

I apologized to Randy and to the list for making a protocol 
error. It was a draft and not a standard yet [Grin].

Date: Thu, 27 Jan 2000 11:28:48 -0800
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Secure BGP -- Internet Drafts
Sender: [email-masked]

Companies are not welcome at the IETF.

Tony

Subject: Re: Secure BGP -- Internet Drafts
Date: Thu, 27 Jan 2000 14:26:30 -0500
From: Hank Zannini <[email-masked]>
To: "Randy Bush" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

>> I [We - Avici] certainly support
>
>the ietf is made up of individual experts, not companies.
>
>randy
>

No but it's companies that ultimately implement something
and demonstrate interoperability for a standard. 

Cheers,

Hank
                   A sharp tongue 
           sometimes cuts its own throat.

***********************************************************
*  Hank Zannini - FOUNDER        E-mail   [email-masked]  *
*  Vice President Business Dev.  MAIN    +1-978-964-2000  *
*  Avici Systems, Inc.           VOICE   +1-978-964-2222  *
*  101 Billerica Ave    Hank's Follow Me +1-603-890-5539  *
*  Building # 6                                           *
*  N. Billerica, MA 01862        Fax     +1-978-964-2100  *
*                                                         *
*  http://www.Avici.com                                   *
***********************************************************

Date: Thu, 27 Jan 2000 10:04:52 -0800 (PST)
From: Alvaro Retana <[email-masked]>
To: [email-masked]
Subject: BGP:tie-breaking algorithm enhancement proposal
Sender: [email-masked]

The current BGP4 draft (draft-ietf-idr-bgp4-09) reads:

-------------------------------------------------------------------
9.1.2.1 Breaking Ties (Phase 2)
.....
   The tie-breaking algorithm begins by considering all equally
   preferable routes and then selects routes to be removed from
   consideration.  The algorithm terminates as soon as only one route
   remains in consideration.  The criteria must be applied in the order
   specified.

.....
      c) If at least one of the candidate routes was received from an
      external peer in a neighboring autonomous system, remove from
      consideration all routes which were received from internal peers.

      d) Remove from consideration all routes other than the route that
      was advertised by the BGP speaker whose BGP Identifier has the
      lowest value.
-------------------------------------------------------------------

I would like to propose the following enhancement (to be put in place of
the last step listed above):

      d) If the remaining routes are all external, remove from consideration 
      all routes except the one that was received first and any others with 
      the same BGP Identifier as it (the one received first).

      e) Remove from consideration all routes other than the ones advertised 
      by the BGP speaker whose BGP Identifier has the lowest value.

In summary, the change will allow a BGP speaker to keep the oldest
external route as the best path, if all the other conditions are the same.  
Except for the case where more than one route is received from the same
eBGP peer.

In keeping the oldest external, the number of unnecesary routing updates
can be lowered.  Note that by advertising a new bestpath (if all the
attributes, except the BGP Identifier, are the same), the exit point will
not change.

In the case where the BGP Identifier is the same, then the "normal"
procedure is used.

Any/all comment are welcome. :-)

Alvaro.

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Secure BGP -- Internet Drafts 
Date: Thu, 27 Jan 2000 10:26:23 -0700
Sender: [email-masked]

I seem to recall Curtis, coincidentally now with Avici, voicing some concerns 
at an IDR WG meeting well over a year ago [somewhere] when the BBN folks 
presented the previously referenced drafts.  His concerns, regarding CPU 
resources required for update processing, as well the model proposed 
offsetting the benefits of aggregation, were shared among many providers, and 
still stand today.  I think Ben's hit on the larger part of the issues that 
folks who would actually deploy this would/should be concerned with.
    
While I'm in complete agreement that something absolutely has to be done in 
this area, I'm not sure if this is the right approach.  Though, because I 
currently don't have a better answer for this "psuedo in-band" UPDATE 
authentication, I guess I can't complain much.  Then again, modeling an 
implementation with this approach and providing some projections as to what 
resources would be required will probably tip the scales in one direction or 
the other.

In response to Hank's comments, sure, SS7ish functionality would be great, 
especially since the database tables are populated somewhat statically on the 
back-end of the SCPs and it doesn't require an STP/SSP (BGP speaker in our 
lingo) to perform any authentication stuff.  Then again, it's certainly got 
it's share of scalability and resiliency issues as well.

Of course, simply having the ability to statically define 100K+ prefix-based 
policies without my routers blowing chunks would be a really good place to 
start.

-danny

> We see a strong interest from both Public and Private carriers
> building Next Generation IP networks - who want to have the
> same kind of secure networks they have today with their SS7 
> Circuit Switch Networks. 
> 
> We will actively participate in any IETF work in this area 
> and will support Interoperability with other Router vendors
> to help move from a draft status to a standard. 

Reply-To: "Benjamin Black" <[email-masked]>
From: "Benjamin Black" <[email-masked]>
To: "Susan Hares" <[email-masked]>, <[email-masked]>
Subject: Re: Secure BGP -- Internet Drafts
Date: Thu, 27 Jan 2000 09:17:57 -0800
Sender: [email-masked]

My initial impression is that these drafts provide definite benefits, but I
am concerned by their potential computational demands and difficulty in
deploying the supporting infrastructure (specifically certificate servers).
You reference a paper to be published next month which specifically
addresses the performance issue.  Can this be provided to the group?

Ben

>
> Here are a few drafts on BBN's work on Secure BGP.
> Should these drafts become IDR working group drafts?
> Please send comments to the list.
>
>
> Sue Hares
>
> --------------
>
> Message-Id: <v04011719b43ec7b6bf7f@[171.78.30.20]>
> Date: Fri, 29 Oct 1999 00:14:15 -0400
> To: [email-masked]
> From: Karen Seo <[email-masked]>
> Subject: Secure BGP -- Internet Drafts
> Cc: [email-masked]
>
> Hello,
>
> Over the past year, we (Charlie Lynn and Luis Sanchez) have made
> presentations on our Secure BGP (S-BGP) work at several IDR WG sessions.
We
> would now like to submit two internet drafts on Secure BGP (see below) to
> the IDR working group for review/feedback and consideration for adoption
> as IDR working group documents. We have sent both to the IETF secretariat
> and also put copies at our web site:
>         http://www.ir.bbn.com/projects/sbgp/
>
> It should be noted that we have prepared these (individual submission)
> I-Ds, based on our experience with a prototype implementation and initial
> testing, including some performance measurements.  Thus, we feel that the
> design is now sufficiently mature to warrant requesting that the IDR WG
> formally consider adopting it as the basis for a work item, oriented
> towards providing high quality security for BGP.
>
> Please let us know if you have questions/comments.  Thank you,
> Karen
>
> 1. Secure BGP (S-BGP) -- Charles Lynn, Joanne Mikkelson, Karen Seo,
>    draft-clynn-s-bgp-protocol-00.txt, October 1999.
>
>    Abstract
>
>    The Border Gateway Protocol (BGP), which is used to distribute routing
>    information between autonomous systems (ASes), is a critical component
>    of the Internet's routing infrastructure. It is highly vulnerable to a
>    variety of malicious attacks both in theory and in practice, due to
>    the lack of a scalable means of verifying the authenticity and
>    legitimacy of BGP control traffic. This document is a protocol
>    specification for Secure BGP (S-BGP), an extension to BGP-4. S-BGP
>    adheres to the principle of least privilege and uses countermeasures
>    that create an authentication and authorization system that addresses
>    most of the security problems associated with BGP. To facilitate
>    adoption and deployment, S-BGP is designed to minimize the overhead
>    (processing, bandwidth, storage) added by its
>
> 2. X.509 Extensions for Authorization of IP Addresses, AS Numbers, and
>    Routers within an AS -- Charles Lynn, draft-clynn-bgp-x509-auth-01.txt,
>    October 1999.
>
>    Abstract
>
>    This document defines three X.509 v3 Certificate Extensions. The
>    first binds a list of IP Address blocks to the public key of the
>    subject of a certificate. The second binds a list of Autonomous
>    System Numbers to the public key of the subject of a certificate.
>    The third binds a BGP Router Identifier and an Autonomous System
>    Number to the public key of the subject of a certificate. Third
>    parties, e.g., BGP routers, may use these certificates to verify
>    that the holder of the private key corresponding to the public
>    key in the certificate has been properly authorized to use
>    resources specified in the certificate extension.
>
>
>
>

From: Randy Bush <[email-masked]>
To: Hank Zannini <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Secure BGP -- Internet Drafts
Date: Thu, 27 Jan 2000 08:02:03 -0800
Sender: [email-masked]

> I [We - Avici] certainly support

the ietf is made up of individual experts, not companies.

randy

From: Lewis Adam-CAL022 <[email-masked]>
To: BGP mailing list <[email-masked]>
Subject: Looking for Convergence
Date: Thu, 27 Jan 2000 09:45:24 -0600
Sender: [email-masked]

Can anybody recommend a paper that deals with Convergence and BGP?
I'm trying to determine the convergence time for a particual network
architecture.
Thanks!

------                                                                
Adam Lewis

Avanced Technology & Strategy
Global Technologies Developement Group

1301 East Algonquin Road, Schuamburg, Illinois 60196
Telephone: (847) 576-8489 Fax: (847) 576-9018
Email: [email-masked]

Subject: Re: Secure BGP -- Internet Drafts
Date: Thu, 27 Jan 2000 08:24:39 -0500
From: Hank Zannini <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

>
>Here are a few drafts on BBN's work on Secure BGP.
>Should these drafts become IDR working group drafts?
>Please send comments to the list.
>
>
>Sue Hares
>

Hi Sue:

I [We - Avici] certainly support adding the drafts submitted
by BBN for a Secure BGP. 

We see a strong interest from both Public and Private carriers
building Next Generation IP networks - who want to have the
same kind of secure networks they have today with their SS7 
Circuit Switch Networks. 

We will actively participate in any IETF work in this area 
and will support Interoperability with other Router vendors
to help move from a draft status to a standard. 

Cheers,

Hank
              Experience is that marvelous thing 
           that enables you to recognize a mistake
                     when you make it again 
***********************************************************
*  Hank Zannini - FOUNDER        E-mail   [email-masked]  *
*  Vice President Business Dev.  MAIN    +1-978-964-2000  *
*  Avici Systems, Inc.           VOICE   +1-978-964-2222  *
*  101 Billerica Ave    Hank's Follow Me +1-603-890-5539  *
*  Building # 6                                           *
*  N. Billerica, MA 01862        Fax     +1-978-964-2100  *
*                                                         *
*  http://www.Avici.com                                   *
***********************************************************

Date: Wed, 26 Jan 2000 11:59:25 -0500 (EST)
From: Susan Hares <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Secure BGP -- Internet Drafts
Sender: [email-masked]

Here are a few drafts on BBN's work on Secure BGP.
Should these drafts become IDR working group drafts?
Please send comments to the list.

Sue Hares

--------------

Message-Id: <v04011719b43ec7b6bf7f@[171.78.30.20]>
Date: Fri, 29 Oct 1999 00:14:15 -0400
To: [email-masked]
From: Karen Seo <[email-masked]>
Subject: Secure BGP -- Internet Drafts
Cc: [email-masked]

Hello,

Over the past year, we (Charlie Lynn and Luis Sanchez) have made
presentations on our Secure BGP (S-BGP) work at several IDR WG sessions. We
would now like to submit two internet drafts on Secure BGP (see below) to
the IDR working group for review/feedback and consideration for adoption
as IDR working group documents. We have sent both to the IETF secretariat
and also put copies at our web site:
        http://www.ir.bbn.com/projects/sbgp/

It should be noted that we have prepared these (individual submission)
I-Ds, based on our experience with a prototype implementation and initial
testing, including some performance measurements.  Thus, we feel that the
design is now sufficiently mature to warrant requesting that the IDR WG
formally consider adopting it as the basis for a work item, oriented
towards providing high quality security for BGP.

Please let us know if you have questions/comments.  Thank you,
Karen

1. Secure BGP (S-BGP) -- Charles Lynn, Joanne Mikkelson, Karen Seo,
   draft-clynn-s-bgp-protocol-00.txt, October 1999.

   Abstract

   The Border Gateway Protocol (BGP), which is used to distribute routing
   information between autonomous systems (ASes), is a critical component
   of the Internet's routing infrastructure. It is highly vulnerable to a
   variety of malicious attacks both in theory and in practice, due to
   the lack of a scalable means of verifying the authenticity and
   legitimacy of BGP control traffic. This document is a protocol
   specification for Secure BGP (S-BGP), an extension to BGP-4. S-BGP
   adheres to the principle of least privilege and uses countermeasures
   that create an authentication and authorization system that addresses
   most of the security problems associated with BGP. To facilitate
   adoption and deployment, S-BGP is designed to minimize the overhead
   (processing, bandwidth, storage) added by its

2. X.509 Extensions for Authorization of IP Addresses, AS Numbers, and
   Routers within an AS -- Charles Lynn, draft-clynn-bgp-x509-auth-01.txt,
   October 1999.

   Abstract

   This document defines three X.509 v3 Certificate Extensions. The
   first binds a list of IP Address blocks to the public key of the
   subject of a certificate. The second binds a list of Autonomous
   System Numbers to the public key of the subject of a certificate.
   The third binds a BGP Router Identifier and an Autonomous System
   Number to the public key of the subject of a certificate. Third
   parties, e.g., BGP routers, may use these certificates to verify
   that the holder of the private key corresponding to the public
   key in the certificate has been properly authorized to use
   resources specified in the certificate extension.

Reply-To: "Benjamin Black" <[email-masked]>
From: "Benjamin Black" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>, <[email-masked]>
Subject: Re: draft-murphy-bgp-secr-03.txt
Date: Mon, 24 Jan 2000 11:58:34 -0800
Sender: [email-masked]

Responses in-line, but overall the point to take away is: cover current best
practice for mitigating the vulnerabilities you describe or restrict your
discussion to a listing of the vulnerabilities without proposed solutions.
Ignoring current practice while presenting a partial specification of a
system with no deployment is just not useful to those trying to implement
policy to better secure their networks.

> >I am a bit confused as to why no mention is made of
> >several security mechanisms already in use by most ISPs: AS_PATH
filtering,
> >prefix filtering, NEXT_HOP filtering, etc.  Current BGP implementation
offer
> >a wealth of options for constraining information exchanged between BGP
> >peers.
>
> The mechanisms you suggest are operational configurations of BGP or of
> routers.  This draft is an analysis of the protoctol, as specified in
> the spec.  It cannot address operational aspects of the use of BGP,
> because those vary widely from vendor to vendor and ISP to ISP.
>

The common practice for implementing policies to mitigate the risks you
describe can certainly be covered.  There are just not that many variants in
widespread use, and presenting them would certainly be of more use to
network operators than changes to the protocol which no vendor has adopted.

> If you think that the implementation configuration options you mention
> avoid the vulnerabilities of the prototcol, then you should speak up
> to have these mechanisms standardized and mandated as part of the
> protocol.

The mechanisms I describe do not belong in the protocol.  They are simply
common practice and common practice is often documented in an RFC other than
the one describing the original protocol.  This is why the TCP protocol is
described in one RFC, but all sorts of implementation mistakes and
suggestions are described in another set of RFCs.

> No, I'm not being facetious.  I've not seen specs of these
> mechanisms so I can't say for sure whether they do or do not eliminate
> the vulnerability.  But it's unlikely that they can eliminate the
> potential for widespread disruptions if they are vendor specific and
> not everywhere employed.
>

It is, however, likely that the vast majority (greater than 95%) of the
deployed implementations *do* support the mechanisms to which I refer.

I'm suggesting that instead of focusing on issues such as forging the AS
path (a problem for which you propose a solution), you might present current
common practice for solving the bulk of the problems you describe.
Filtering based on next-hop is common at exchange points, for example.  My
point is that you should either explain security vulnerabilities and nothing
else, or you present vulnerabilities along with current or proposed
solutions for each (assuming one exists).

> >The term "non-BGP peer" is extremely ambiguous.
>
> OK, I see your point.  I meant "something other than a BGP peer".  Could
> you make a suggestion of a non-ambiguous term?
>
> >The proposed AS signing scheme would benefit greatly from an estimate of
the
> >computational resources required to verify the signatures of 65000 paths,
> >each consisting of perhaps 4 or 5 ASes.
>
> The only answer possible is that the time it would take to verify the
> signatures is 65000*(4or5)*TimeForOneSignatureVerification.  To give a
> better answer requires knowledge of the signature algorithm, the
> implementation, the platform, and the key size.  At least.
>
> The SBGP project has actually done a real-life implementation of an
> AS_PATH signing scheme.  You could look at
draft-clynn-s-bgp-protocol-00.txt
> if you wanted more information about their approach.  I think they've
> published some papers describing their experience, but I'm not sure where.
>
> >Section 3.5.1 outlines exactly how the proposed signature scheme fails
for
> >aggregation, yet offers no solution to the problem which provides any
> >measure of security.  As is clearly stated, either a significant increase
in
> >space for routing information is required to handle key and plaintext
> >information for every component of an aggregate (meaning a router is
> >carrying as much information as without aggregation) or aggregators are
> >permitted to reset the signing process, completely invalidating any
security
> >benefits.
>
> The purpose of this draft is to list various possible protections and
> describe the assurance derived from each.

Agreed.  This is why I pointed out the numerous *deployed* solutions for the
problems presented and took a dim view regarding a proposed AS path
signature scheme with no deployment.

> I do not know of any
> protection that I or anyone else have proposed that treat aggregation
> points with any better results.  Since an aggregated AS_PATH does not
> make a definite statement ("the route to this NLRI transits some or
> none of the AS's in this AS_PATH in no particular order"), it is
> hard for me to see what sort of assurance it is possible to give
> about that statement.
>
> Again, the SBGP folk have implemented an AS_PATH signing scheme and
> they have taken the approach of including all the signature
> information for the AS_PATHS that feed into the aggregate into the
> aggregated UPDATE.  Essentially, they are providing enough information
> to remove the vagueness in the aggregated statement.  If you wish to
> know more details of the space aspects of their approach, you should
> discuss that with them directly.
>

Perhaps, but they are not the ones presenting a draft to the idr working
group.  You should either provide a complete specification of the signature
scheme or remove it.

> >An EBGP neighbor must prepend its own AS onto the path.  There is no
> >legitimate reason for not performing this action as it is fundamental to
> >loop avoidance.
>
> That is how I read the spec, but conversations in the group and in the
> list seemed to suggest otherwise.  I've brought this question up in
> working group meetings with interesting results - lots of people at
> the microphone claiming that the AS must be prepended, lots of people
> at the microphone claiming that they frequently do not prepend.
>

They may not prepend *additional* copies of their AS, but they are
*definitely* prepending at least one copy of their AS onto the path.

> Note that if there are many people who do not prepend their AS, then

There are none.

> current implementations must not be viewing an AS_PATH that does not
> start with the AS of the neighbor as an error.  So arbitrary AS's are
> accepted.  That's a vulnerability.  One might claim that those
non-prepending
> people are living in sin and should mend their ways and the best way
> to make sure they do is to make it part of protocol compliance that
> the initial AS must be checked.  But given the number of people who
> claim they do not prepend for their own reasons, mandating that check
> of the first AS should be discussed on the mailing list.
>

There is no need for a mandate.  The protocol is quite clear on the subject:

      b) When a given BGP speaker advertises the route to a BGP speaker
      located in a neighboring autonomous system, then the advertising
      speaker shall update the AS_PATH attribute as follows:

         1) if the first path segment of the AS_PATH is of type
         AS_SEQUENCE, the local system shall prepend its own AS number
         as the last element of the sequence (put it in the leftmost
         position).

         2) if the first path segment of the AS_PATH is of type AS_SET,
         the local system shall prepend a new path segment of type
         AS_SEQUENCE to the AS_PATH, including its own AS number in that
         segment.

There is simply no ambiguity here.  If there is concern that malicious peers
may manipulate the AS path, AS path filtering is simple enough and extremely
common in practice.  This is the sort of thing that *should* be discussed in
a draft regarding security.

> As for your comments about an origin of INCOMPLETE and the NEXT_HOP AS
> discussion, I'm not sure if you are saying that the vulnerability is
> more or less than I've stated, so in those cases I'm going to have to
> go read the section and your response with more care.
>

My comment regarding the ORIGIN attribute was that the vulnerability is more
(however slightly) than what you believed.  My comments regarding the
NEXT_HOP attribute were explaining how such risks are mitigated in practice.

Ben

Date: Mon, 24 Jan 2000 12:15:28 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: draft-murphy-bgp-secr-03.txt
Cc: [email-masked]
Sender: [email-masked]

>I have numerous concerns regarding the information in this draft, some of
>which are below.

Well, I'll try to address the ones you have included.  Will you be
posting the others to the list any time soon?

Some of these I can answer off the top of my head.  Others I'll have to
go back and re-read the section mentioned - the context provided isn't
enough for me to see the point - but that will be later this week
and I wanted to answer those I could immediately.

>I am a bit confused as to why no mention is made of
>several security mechanisms already in use by most ISPs: AS_PATH filtering,
>prefix filtering, NEXT_HOP filtering, etc.  Current BGP implementation offer
>a wealth of options for constraining information exchanged between BGP
>peers.

The mechanisms you suggest are operational configurations of BGP or of
routers.  This draft is an analysis of the protoctol, as specified in
the spec.  It cannot address operational aspects of the use of BGP,
because those vary widely from vendor to vendor and ISP to ISP.

If you think that the implementation configuration options you mention
avoid the vulnerabilities of the prototcol, then you should speak up
to have these mechanisms standardized and mandated as part of the
protocol.  No, I'm not being facetious.  I've not seen specs of these
mechanisms so I can't say for sure whether they do or do not eliminate
the vulnerability.  But it's unlikely that they can eliminate the
potential for widespread disruptions if they are vendor specific and
not everywhere employed.

>The term "non-BGP peer" is extremely ambiguous.

OK, I see your point.  I meant "something other than a BGP peer".  Could
you make a suggestion of a non-ambiguous term?

>The proposed AS signing scheme would benefit greatly from an estimate of the
>computational resources required to verify the signatures of 65000 paths,
>each consisting of perhaps 4 or 5 ASes.

The only answer possible is that the time it would take to verify the
signatures is 65000*(4or5)*TimeForOneSignatureVerification.  To give a 
better answer requires knowledge of the signature algorithm, the
implementation, the platform, and the key size.  At least.

The SBGP project has actually done a real-life implementation of an
AS_PATH signing scheme.  You could look at draft-clynn-s-bgp-protocol-00.txt
if you wanted more information about their approach.  I think they've
published some papers describing their experience, but I'm not sure where.

>Section 3.5.1 outlines exactly how the proposed signature scheme fails for
>aggregation, yet offers no solution to the problem which provides any
>measure of security.  As is clearly stated, either a significant increase in
>space for routing information is required to handle key and plaintext
>information for every component of an aggregate (meaning a router is
>carrying as much information as without aggregation) or aggregators are
>permitted to reset the signing process, completely invalidating any security
>benefits.

The purpose of this draft is to list various possible protections and
describe the assurance derived from each.  I do not know of any
protection that I or anyone else have proposed that treat aggregation
points with any better results.  Since an aggregated AS_PATH does not
make a definite statement ("the route to this NLRI transits some or
none of the AS's in this AS_PATH in no particular order"), it is
hard for me to see what sort of assurance it is possible to give
about that statement.

Again, the SBGP folk have implemented an AS_PATH signing scheme and
they have taken the approach of including all the signature
information for the AS_PATHS that feed into the aggregate into the
aggregated UPDATE.  Essentially, they are providing enough information
to remove the vagueness in the aggregated statement.  If you wish to
know more details of the space aspects of their approach, you should
discuss that with them directly.

>An EBGP neighbor must prepend its own AS onto the path.  There is no
>legitimate reason for not performing this action as it is fundamental to
>loop avoidance.

That is how I read the spec, but conversations in the group and in the
list seemed to suggest otherwise.  I've brought this question up in
working group meetings with interesting results - lots of people at
the microphone claiming that the AS must be prepended, lots of people
at the microphone claiming that they frequently do not prepend.

Note that if there are many people who do not prepend their AS, then
current implementations must not be viewing an AS_PATH that does not
start with the AS of the neighbor as an error.  So arbitrary AS's are
accepted.  That's a vulnerability.  One might claim that those non-prepending
people are living in sin and should mend their ways and the best way
to make sure they do is to make it part of protocol compliance that
the initial AS must be checked.  But given the number of people who
claim they do not prepend for their own reasons, mandating that check
of the first AS should be discussed on the mailing list.

As for your comments about an origin of INCOMPLETE and the NEXT_HOP AS
discussion, I'm not sure if you are saying that the vulnerability is
more or less than I've stated, so in those cases I'm going to have to
go read the section and your response with more care.

--Sandy Murphy

Reply-To: "Benjamin Black" <[email-masked]>
From: "Benjamin Black" <[email-masked]>
To: <[email-masked]>, "Yakov Rekhter" <[email-masked]>
Subject: Re: draft-murphy-bgp-secr-03.txt
Date: Fri, 21 Jan 2000 23:39:50 -0800
Sender: [email-masked]

I have numerous concerns regarding the information in this draft, some of
which are below.  I am a bit confused as to why no mention is made of
several security mechanisms already in use by most ISPs: AS_PATH filtering,
prefix filtering, NEXT_HOP filtering, etc.  Current BGP implementation offer
a wealth of options for constraining information exchanged between BGP
peers.  The draft proposes solutions which would require significant changes
to BGP implementations as well as significant computational resources, while
completely ignoring common practice and existing policy mechanisms.

The term "non-BGP peer" is extremely ambiguous.  Does it refer to a peer
which is not speaking BGP or an entity which is not a peer at all?  A clear
definition, if not a terminology change, would greatly improve this
confusion.

The proposed AS signing scheme would benefit greatly from an estimate of the
computational resources required to verify the signatures of 65000 paths,
each consisting of perhaps 4 or 5 ASes.   What about a router which must
sign 65000 routes for each of its peers?  This seems rather far outside the
realm of possibility for a typical backbone router within a reasonable
amount of time.

Section 3.5.1 outlines exactly how the proposed signature scheme fails for
aggregation, yet offers no solution to the problem which provides any
measure of security.  As is clearly stated, either a significant increase in
space for routing information is required to handle key and plaintext
information for every component of an aggregate (meaning a router is
carrying as much information as without aggregation) or aggregators are
permitted to reset the signing process, completely invalidating any security
benefits.  This is a fairly substantial shortcoming, even if the
computational demands were met.

>From section A4.3:

In regards to ORIGIN (these sections should really have subsection numbers):

  This field indicates whether the information was learned from IGP or EGP
  information.  If the route is used in inter-AS multicast routing, a
  values of INCOMPLETE may be used.  This field is not used in making
  routing decisions, so there are no vulnerabilities arising from this
  field, either from BGP peers or non-BGP peers.

An origin of INCOMPLETE is perfectly valid for unicast routes.  In addition,
although not specified in RFC1771, origin information is certainly used for
tie-breaking in the vast majority of deployed BGP speakers.

In regards to AS_PATH:

  If there are legitimate situations in which a BGP speaker could pass an
AS_PATH to a neighbor without
  putting its own AS at the head of the AS_PATH, then there is no way for
implementations to detect totally
  bogus AS_PATHs.

An EBGP neighbor must prepend its own AS onto the path.  There is no
legitimate reason for not performing this action as it is fundamental to
loop avoidance.

In regards to NEXT_HOP:

  It is unclear whether this would also require the advertising BGP speaker
to construct an AS_PATH
  mentioning the NEXT_HOP inter-AS peer's AS.

What is unclear?  There is no requirement that a next hop IP be part of the
AS of the peer announcing routes with that next hop.  A peer is just as free
to set next hop to whatever they like as their peer is to drop routes
without the expected next hop.

----- Original Message -----
From: Yakov Rekhter <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 21, 2000 8:07 AM
Subject: draft-murphy-bgp-secr-03.txt

> Folks,
>
> I'd like to get your opinion on accepting draft-murphy-bgp-secr-03.txt
> as an IDR WG document with the ultimate goal of publishing it as
> an Informational RFC. Please comment on this within the next 2 weeks.
>
> Yakov.
>
>

To: [email-masked]
Subject: draft-murphy-bgp-secr-03.txt
Date: Fri, 21 Jan 2000 08:07:57 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

I'd like to get your opinion on accepting draft-murphy-bgp-secr-03.txt
as an IDR WG document with the ultimate goal of publishing it as
an Informational RFC. Please comment on this within the next 2 weeks.

Yakov.

From: Randy Bush <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-murphy-bgp-secr-03.txt
Date: Fri, 21 Jan 2000 08:18:33 -0800
Sender: [email-masked]

> I'd like to get your opinion on accepting draft-murphy-bgp-secr-03.txt
> as an IDR WG document with the ultimate goal of publishing it as
> an Informational RFC. Please comment on this within the next 2 weeks.

please

randy

From: "Peter Lewis" <[email-masked]>
To: <Undisclosed-Recipient:@smtp2.cluster.oleane.net;>
Subject: MPLS Forum 
Date: Thu, 13 Jan 2000 13:45:31 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01BF5DCC.758AB780
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The MPLS Forum will stand in Paris next 7-10 March. Reports from real
deployments, standard progress issues, technical propositions, debate:
building the next IP architecture.
Get details at:
www.upperside.fr/mplsforum.htm

------=_NextPart_000_000D_01BF5DCC.758AB780
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>The MPLS =
Forum will stand=20
in Paris next 7-10 March. Reports from real<BR>deployments, standard =
progress=20
issues, technical propositions, debate:<BR>building the next IP=20
architecture.<BR>Get details at:<BR><A=20
href=3D"http://www.upperside.fr/mplsforum.htm">www.upperside.fr/mplsforum=
.htm</A></FONT></FONT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_000D_01BF5DCC.758AB780--

From: "Peter Lewis" <[email-masked]>
To: <Undisclosed-Recipient:@smtp1.cluster.oleane.net;>
Subject: Cellular Internet Call for Paper
Date: Tue, 11 Jan 2000 13:11:18 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01BF5C35.58C52380
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Cellular Internet: The Micro-Mobility Approach

The micro-mobility concept is the most recent and promising approach =
proposed to add mobility to the Internet and packet data services to =
third generation cellular systems.
=20
A CFP is available at:=20
http://www.upperside.fr/baipcn.htm

------=_NextPart_000_000F_01BF5C35.58C52380
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#800080 face=3DArial size=3D2>
<DIV><FONT color=3D#000000>
<DIV><FONT color=3D#000000 size=3D2><B>Cellular Internet: The =
Micro-Mobility=20
Approach</B><BR><BR>The micro-mobility concept is the most recent and =
promising=20
approach proposed to add mobility to the Internet and packet data =
services to=20
third generation cellular systems.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>A CFP is available at:=20
</FONT></DIV></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/baipcn.htm">http://www.upperside.fr/baipc=
n.htm</A></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_000F_01BF5C35.58C52380--