Re: using the TCP MD5 protection for BGP - Proposed Standard???

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>, "Luis A. Sanchez" writes:
> > Are there any objections to the content of the draft (holes that need
> > to be plugged other than weakness in MD5?).
> 
> - I found eight instances (not counting the title) of the word
> "signature" in the document. This should be changed to "Integrity
> Check Value (ICV)" or "authenticator" I prefer the latter but both
> terms will be appropriate in this context.

This strikes me as a wording change but the term authenticator is more
accurate.

> - There are some residual vulnerabilities in the protocol that i think
> should be mentioned. For example, the fact that the keys are
> configured manually (since there is no automated key management
> facility) implies that these keys will exist for a reasonable amount
> of time, certainly longer than a single TCP connection since no-one
> will be reconfiguring the keys manually after every route flap, hard
> reset or TCP FIN for that matter. THis means that the opportunity
> exists for an attacker to replay old traffic that could cause
> interesting problems. Of particular interest, would be recorded
> traffic carrying hard resets. This traffic would succesfully pass the
> ICV validation. The trick is in mapping the sequence numbers, which
> could be done. Although it is harder than it used to be. This changes
> will affect section 4.1 and will probably require a new section too.

You'd also need to match the port pair.  Since one end is randomized
over the better part of 64k (or at least around 10k for TCP
implementations that restrict the range of port values) and the
initial sequence number is randomized, the chance of being able to
replay is quite small.

BTW- BGP sessions do last quite long.  Generally months or more.

> - One would want to specify key sizes and ranges to be used in
> conjuction with MD5. This will allow one to assess the level of
> security being offered by this mechanism. Security through obscurity
> (intentionally or not) has proven to be the wrong approach.  Hence,
> section 4.5 needs some more explanation and clarification.

OK.

> Now, the hard ones:
> 
> - The use of a hash algorithm in this keyed fashion (Keyed-MD5) has
> been disparaged in the literature for two years, prompting changes in
> the IPsec RFCs; it seems inappropriate to promote the use of this sort
> of authentication technology in a newly issued RFC.  Personally, i
> think we should provide an HMAC with either with the option of using
> it with either (MD5 or SHA-1). 
> 
> I think that minimum we should modify section 4.4 since it gives the
> impression that the collison problem of MD5 is the only problem with
> using this option and, that we add a new section comparing the
> keyed-MD5 transform used in this protocol versus using an HMAC with
> MD5. Vendors who choose to implement this option and customers who
> choose to use it will be able to assess the level of security provided
> by this feature.
> 
> Luis

These seem like reasonable changes.  We may need two more TCP option
numbers for HMAC with MD5 and HMAC with SHA-1 or one more option and a
algorithm type (two bytes is plenty).  The TCP option 19 is already in
widespread use so we'd need to get another number.

The security consideration section could then state that:

   This document defines a weak but currently practiced security
   mechanism for BGP using MD5 and a incremental improvement using an
   HMAC with MD5 or an HMAC with SHA-1.  It is anticipated that future
   work will provide different stronger mechanisms for dealing with
   these issues.

Perhaps the author of the draft should comment rather than me (or
someone that knows what they are talking about rather than me :).

Curtis

ps- for us near crypto illiterates could you point to some consise
references that explain HMAC with MD5 and HMAC with SHA-1.


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id WAA18768 for <[e-mail]>; Fri, 31 Jul 1998 22:45:28 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA17032 for idr-outgoing; Fri, 31 Jul 1998 22:40:00 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id WAA17028 for <[e-mail]>; Fri, 31 Jul 1998 22:39:57 -0400 (EDT)
From: [e-mail]
Received: from corponline.net (root@[209.150.128.91]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id WAA13988 for <[e-mail]>; Fri, 31 Jul 1998 22:39:56 -0400 (EDT)
Received: from globaltrade (PPP52M.NWC.Net [207.151.14.175]) by corponline.net (8.8.5/8.8.5) with SMTP id VAA23113 for [e-mail]; Fri, 31 Jul 1998 21:39:18 -0500
Date: Fri, 31 Jul 1998 21:39:18 -0500
To: [e-mail]
Message-Id: <[e-mail]>
Content-Type: TEXT/PLAIN charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Very Respected [e-mail]

We very cordially invite you to visit  http://hindustan.net
It is for you, dedicated to you - for your interest in Indian Sub-continent.

Hindustan + Search India -  pretends to be the most comprehensive &
robust  Search engine & directory of India and India related resources worldwide.
Its a non-lucrative, dynamic & free site.
Soon you will be able to search a wide variety of info on all India
related global resources on the net in the friendliest format and fast loading pages.

Promoting your Webpages and Site &  get enormous response

We invite you to add your website in any of the over 350 categories available 
by clicking  http://hindustan.net/add.cgi

Your Voice will reach Delhi
Expressing your Views on important Issues concerning India & the world
Come for intelligent debate and discussion.

Your Vote
Vote with a single click on  hot issues.

Announcing/Classified Ads Exchange
Place a free ad at http://hindustan.net/exchange for job, real-estate,
new business, matrimonial  or any of the 12 categories.

If you receive this message in error or in duplicate please ignore it as
you won't get any further message from us nor you are on any list.

Best of luck and kindest regards from
[e-mail]



Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id AAA08386 for <[e-mail]>; Fri, 31 Jul 1998 00:57:29 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA00286 for idr-outgoing; Fri, 31 Jul 1998 00:51:45 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA00282 for <[e-mail]>; Fri, 31 Jul 1998 00:51:41 -0400 (EDT)
Received: from hotmail.com (f81.hotmail.com [207.82.250.187]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id AAA26751 for <[e-mail]>; Fri, 31 Jul 1998 00:51:40 -0400 (EDT)
Received: (qmail 4347 invoked by uid 0); 31 Jul 1998 04:51:08 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Thu, 30 Jul 1998 21:51:08 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: RFC 1771 9.1.2 Route selection
Content-Type: text/plain
Date: Thu, 30 Jul 1998 21:51:08 PDT
Sender: [e-mail]
Precedence: bulk

Hi,
  Thanks,but my thought is that the nexthop's IGP reachability should be 
considered by locating the nexthop in the IGP table, not the LOC-RIB as 
specified in the RFC. Rajesh did answer the question :
"For pervasive BGP, no IGP synchronization is needed, so i guess the RFC 
did not intend to apply to specific case where IGP synch. is needed".

-Jaihari.
(of course this is not the case for pervasive BGP where all routers in 
the AS have reachability information to the IBGP learnt routes)

>From [e-mail] Thu Jul 30 21:11:02 1998
>Received: by teil.soft.net (940816.SGI.8.6.9/940406.SGI)
>	 id JAA19607; Fri, 31 Jul 1998 09:41:45 -0530
>Date: Fri, 31 Jul 1998 09:38:37 -0530 (IST)
>From: Ajay Agrawal <[e-mail]>
>Subject: Re: RFC 1771 9.1.2 Route selection
>To: jaihari loganathan <[e-mail]>
>cc: [e-mail]
>In-Reply-To: <[e-mail]>
>Message-ID: <[e-mail]>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>
>HI!
>
>On Thu, 30 Jul 1998, jaihari loganathan wrote:
>
>> Hi,
>>   section 9.1.2/RFC1771 : 
>>   "If the NEXT_HOP attribute of a BGP route depicts an address to 
which 
>> the local BGP speaker doesn't have a route in its LOC-RIB, the
>> BGP route should be excluded from the Phase 2 decision function"
>>
>The presence of Next_Hop in the LOC-RIB signifies that the route is 
>reachable and only reachable routes are considered for Phase 2 decision 
>process.
>
>>    I am interpreting this as an issue of IGP synchronization.
>>    And so have this question :
>>        instead of LOC-RIB, should it not be local IGP table?
>> 
>> Thanks,
>> -Jaihari.
>>
>
>regards
>Ajay 
>
>


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id AAA08070 for <[e-mail]>; Fri, 31 Jul 1998 00:19:32 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA29865 for idr-outgoing; Fri, 31 Jul 1998 00:11:25 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA29861 for <[e-mail]>; Fri, 31 Jul 1998 00:11:21 -0400 (EDT)
Received: from teil.soft.net (teil.soft.net [164.164.10.2]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id AAA25538 for <[e-mail]>; Fri, 31 Jul 1998 00:11:16 -0400 (EDT)
Received: by teil.soft.net (940816.SGI.8.6.9/940406.SGI) id JAA19607; Fri, 31 Jul 1998 09:41:45 -0530
Date: Fri, 31 Jul 1998 09:38:37 -0530 (IST)
From: Ajay Agrawal <[e-mail]>
Subject: Re: RFC 1771 9.1.2 Route selection
To: jaihari loganathan <[e-mail]>
cc: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

HI!

On Thu, 30 Jul 1998, jaihari loganathan wrote:

> Hi,
>   section 9.1.2/RFC1771 : 
>   "If the NEXT_HOP attribute of a BGP route depicts an address to which 
> the local BGP speaker doesn't have a route in its LOC-RIB, the
> BGP route should be excluded from the Phase 2 decision function"
>
The presence of Next_Hop in the LOC-RIB signifies that the route is 
reachable and only reachable routes are considered for Phase 2 decision 
process.

>    I am interpreting this as an issue of IGP synchronization.
>    And so have this question :
>        instead of LOC-RIB, should it not be local IGP table?
> 
> Thanks,
> -Jaihari.
>

regards
Ajay 



Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id QAA04467 for <[e-mail]>; Thu, 30 Jul 1998 16:15:03 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA24437 for idr-outgoing; Thu, 30 Jul 1998 16:11:52 -0400 (EDT)
Received: from mail.aap.ans.net (mail.aap.ans.net [147.225.37.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA24430; Thu, 30 Jul 1998 16:11:45 -0400 (EDT)
From: [e-mail]
Received: from hotmail.com (2Cust97.tnt8.lax3.da.uu.net [153.37.74.225]) by mail.aap.ans.net (8.8.7/8.8.7) with SMTP id QAA06767; Thu, 30 Jul 1998 16:11:38 -0400 (EDT)
Message-Id: <[e-mail]>
To: <[e-mail]>
Subject: battery of the future...
Date: Thu, 30 Jul 1998 09:35:31
Sender: [e-mail]
Precedence: bulk

 The time is now to reach out to all the people on the 
 Internet,with target e-mail.
 
 It's your business,how are you going to advertise your          
 product or service over the Internet?              

 Direct email puts you in front of millions of people who want  
to  know  about your product or service. The most cost  effective 
way to make your  business explode!

 Never before has it been possible to reach so many for so       
little.

  We are the leaders in direct email because we do what we       
 say.Our data banks have email buyers for every business.

 Don't worry we will help you with a subject and letter that will 
work  for you.
.                                                                
                            Guaranteed
  CALL 1-800-600-0343 ext,1669 leave message.
  
 
 
 
 
 
 
 
 
 
 


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id IAA29956 for <[e-mail]>; Thu, 30 Jul 1998 08:04:57 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA15633 for idr-outgoing; Thu, 30 Jul 1998 07:56:24 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id HAA15629 for <[e-mail]>; Thu, 30 Jul 1998 07:56:19 -0400 (EDT)
Received: from hotmail.com (f236.hotmail.com [207.82.251.127]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id HAA02737 for <[e-mail]>; Thu, 30 Jul 1998 07:56:19 -0400 (EDT)
Received: (qmail 15413 invoked by uid 0); 30 Jul 1998 11:55:47 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Thu, 30 Jul 1998 04:55:47 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Subject: RFC 1771 9.1.2 Route selection
Content-Type: text/plain
Date: Thu, 30 Jul 1998 04:55:47 PDT
Sender: [e-mail]
Precedence: bulk

Hi,
  section 9.1.2/RFC1771 : 
  "If the NEXT_HOP attribute of a BGP route depicts an address to which 
the local BGP speaker doesn't have a route in its LOC-RIB, the
BGP route should be excluded from the Phase 2 decision function"
   
   I am interpreting this as an issue of IGP synchronization.
   And so have this question :
       instead of LOC-RIB, should it not be local IGP table?

Thanks,
-Jaihari.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id UAA24177 for <[e-mail]>; Wed, 29 Jul 1998 20:05:32 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA10315 for idr-outgoing; Wed, 29 Jul 1998 20:02:12 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA10308 for <[e-mail]>; Wed, 29 Jul 1998 20:02:08 -0400 (EDT)
Received: from ha1.rdc1.nj.home.com ([e-mail] [24.3.128.66]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id UAA04136 for <[e-mail]>; Wed, 29 Jul 1998 20:02:07 -0400 (EDT)
Received: from home.com ([24.3.129.187]) by ha1.rdc1.nj.home.com (Netscape Mail Server v2.02) with ESMTP id AAA27267; Wed, 29 Jul 1998 17:02:06 -0700
Message-ID: <[e-mail]>
Date: Wed, 29 Jul 1998 19:58:19 -0400
From: Rajesh Saluja <[e-mail]>
Organization: @Home Network
X-Mailer: Mozilla 4.02 [en]C-AtHome0402  (Win95; U)
MIME-Version: 1.0
To: jaihari loganathan <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: RFC 1771 Section 9.1 clarification
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

jaihari loganathan wrote:
> 
> >> 2.
> >>    Suppose a prefix 'p'(nexthop is 'nh') is learnt from a IBGP peer
> >>    a) does BGP install the prefix 'p' into the forwarding table or an
> >> IGP has to do it?
> >>       Section 9.1.2 Phase 2: Route selection  says we should consider
> >> all routes from both internal and external peers.
> >
> >Here it means IBGP and EBGP peers. How is IGP coming into picture?
> 
>   IGP synchronization rule where a local BGP speaker cannot advertise a
> destination learnt through IBGP UNLESS that destination is also
> reachable through IGP. -RFC 1772 section A.2.2 rule 2
> 
>   My question is : In order to advertise a prefix 'p' (NEXT_HOP : nh )
> learnt through IBGP, does both 'nh' and 'p' should be IGP reachable?
>   ( also , does IGP reachability of 'nh' guarantee IGP reachability of
> 'p' ) ?
> 
IGP reachability to "nh" ensures that the router can reach "p" ( if the
intermediate  routers do not drop the packets )  and IGP reachability to
"p" ensures that all the intermediate routers ( IGP internal routers )
can also reach "p". Unless the intermediate routers have route to "p",
the packets from this router to "p" will be dropped by an intermediate
router. Hence in this case,  the BGP best route should be installed in
the forwarding table after this route has been learnt from IGP also and
only after this, the BGP speaker should advertise this route to its
neighboring peers.

Thanks,
Rajesh Saluja
Ficon Technology, NJ
[e-mail]


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id TAA23817 for <[e-mail]>; Wed, 29 Jul 1998 19:29:47 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA10009 for idr-outgoing; Wed, 29 Jul 1998 19:25:38 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA10005 for <[e-mail]>; Wed, 29 Jul 1998 19:25:33 -0400 (EDT)
Received: from hotmail.com (f20.hotmail.com [207.82.250.31]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id TAA02832 for <[e-mail]>; Wed, 29 Jul 1998 19:25:32 -0400 (EDT)
Received: (qmail 21658 invoked by uid 0); 29 Jul 1998 23:25:01 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Wed, 29 Jul 1998 16:25:01 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: Re: RFC 1771 Section 9.1 clarification
Content-Type: text/plain
Date: Wed, 29 Jul 1998 16:25:01 PDT
Sender: [e-mail]
Precedence: bulk

>> 2.
>>    Suppose a prefix 'p'(nexthop is 'nh') is learnt from a IBGP peer
>>    a) does BGP install the prefix 'p' into the forwarding table or an
>> IGP has to do it?
>>       Section 9.1.2 Phase 2: Route selection  says we should consider
>> all routes from both internal and external peers.
>
>Here it means IBGP and EBGP peers. How is IGP coming into picture?

  IGP synchronization rule where a local BGP speaker cannot advertise a 
destination learnt through IBGP UNLESS that destination is also 
reachable through IGP. -RFC 1772 section A.2.2 rule 2

  My question is : In order to advertise a prefix 'p' (NEXT_HOP : nh ) 
learnt through IBGP, does both 'nh' and 'p' should be IGP reachable?
  ( also , does IGP reachability of 'nh' guarantee IGP reachability of 
'p' ) ?

 


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id KAA19092 for <[e-mail]>; Wed, 29 Jul 1998 10:52:17 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA02368 for idr-outgoing; Wed, 29 Jul 1998 10:48:26 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA02360 for <[e-mail]>; Wed, 29 Jul 1998 10:48:21 -0400 (EDT)
Received: from phoenix.ficon-tech.com (phoenix.ficon-tech.com [209.125.90.2]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id KAA00203 for <[e-mail]>; Wed, 29 Jul 1998 10:48:11 -0400 (EDT)
Received: from ficon-tech.com (192.168.137.12) by phoenix.ficon-tech.com (Worldmail 1.3.167); 29 Jul 1998 10:50:25 -0400
Message-ID: <[e-mail]>
Date: Wed, 29 Jul 1998 10:52:09 -0400
From: Rajesh Saluja <[e-mail]>
Reply-To: [e-mail]
Organization: Ficon Technology, Inc.
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: jaihari loganathan <[e-mail]>
CC: [e-mail]
Subject: Re: RFC 1771 Section 9.1 clarification
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

jaihari loganathan wrote:

> 1. 9.1 ) Decision Process
>  a) Phase 1 is responsible for calculating the degree of preference
>     for each route received from an external peer, and for advertising
>     to the other internal peers.
>
>    9.1.1 ) Phase 1: Calculation of degree of preference
>        ...
>        ...
>         If the route is learnt from an internal peer, the value of the
>      LOCAL_PREF...
>
> There seems to be a contradiction. The definition a) states Phase 1
> is responsible for operating on routes from "external peer". The section
> 9.1.1 says "If the route is learnt from an internal peer"

Degree of preference will be calculated in both the cases ( if routes
received from EBGP or IBGP peers ). The internal updates ( as a part of
phase1 decision process ) will be sent only if the route is received from
EBGP peer ( assuming no route reflection ).

>
>
> 2.
>    Suppose a prefix 'p'(nexthop is 'nh') is learnt from a IBGP peer
>    a) does BGP install the prefix 'p' into the forwarding table or an
> IGP has to do it?
>       Section 9.1.2 Phase 2: Route selection  says we should consider
> all routes from both internal and external peers.

Here it means IBGP and EBGP peers. How is IGP coming into picture?

>       So i take it that answer to the question a) is that BGP has to
> install the prefix 'p' into the forwarding table. (In that case if the
> IGP learns about the same prefix, one of them must be given a
> preference?)

BGP route selection will consider all routes from internal and external
peers ( IBGP and EBGP peers ) to select the best BGP route. If the router is
learning the same route from IGP ( say OSPF or RIP ) also, then the route
selection will depend on the local policy. If the best route selected by the
BGP route selection is not put in the IP forwarding table, it should not be
advertised to the neighboring AS peers.

-Rajesh
--
----------------------------------------------------------------------
Rajesh Saluja
Ficon Technology                 Voice:  [phone] ext 322
1000 Route 9 North               Fax  :  [phone]
Woodbridge, NJ 07095             mailto:[e-mail]
---------------------------------------------------------------------




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id KAA18667 for <[e-mail]>; Wed, 29 Jul 1998 10:09:50 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA01380 for idr-outgoing; Wed, 29 Jul 1998 10:05:24 -0400 (EDT)
Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA01372 for <[e-mail]>; Wed, 29 Jul 1998 10:05:18 -0400 (EDT)
Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.8/8.8.8) with ESMTP id KAA22622; Wed, 29 Jul 1998 10:05:05 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Luis A. Sanchez" <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard??? 
In-reply-to: Your message of "Tue, 28 Jul 1998 16:14:50 -0000." <[e-mail]> 
Date: Wed, 29 Jul 1998 10:05:05 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, "Luis A. Sanchez" writes:
> > Are there any objections to the content of the draft (holes that need
> > to be plugged other than weakness in MD5?).
> 
> - I found eight instances (not counting the title) of the word
> "signature" in the document. This should be changed to "Integrity
> Check Value (ICV)" or "authenticator" I prefer the latter but both
> terms will be appropriate in this context.

This strikes me as a wording change but the term authenticator is more
accurate.

> - There are some residual vulnerabilities in the protocol that i think
> should be mentioned. For example, the fact that the keys are
> configured manually (since there is no automated key management
> facility) implies that these keys will exist for a reasonable amount
> of time, certainly longer than a single TCP connection since no-one
> will be reconfiguring the keys manually after every route flap, hard
> reset or TCP FIN for that matter. THis means that the opportunity
> exists for an attacker to replay old traffic that could cause
> interesting problems. Of particular interest, would be recorded
> traffic carrying hard resets. This traffic would succesfully pass the
> ICV validation. The trick is in mapping the sequence numbers, which
> could be done. Although it is harder than it used to be. This changes
> will affect section 4.1 and will probably require a new section too.

You'd also need to match the port pair.  Since one end is randomized
over the better part of 64k (or at least around 10k for TCP
implementations that restrict the range of port values) and the
initial sequence number is randomized, the chance of being able to
replay is quite small.

BTW- BGP sessions do last quite long.  Generally months or more.

> - One would want to specify key sizes and ranges to be used in
> conjuction with MD5. This will allow one to assess the level of
> security being offered by this mechanism. Security through obscurity
> (intentionally or not) has proven to be the wrong approach.  Hence,
> section 4.5 needs some more explanation and clarification.

OK.

> Now, the hard ones:
> 
> - The use of a hash algorithm in this keyed fashion (Keyed-MD5) has
> been disparaged in the literature for two years, prompting changes in
> the IPsec RFCs; it seems inappropriate to promote the use of this sort
> of authentication technology in a newly issued RFC.  Personally, i
> think we should provide an HMAC with either with the option of using
> it with either (MD5 or SHA-1). 
> 
> I think that minimum we should modify section 4.4 since it gives the
> impression that the collison problem of MD5 is the only problem with
> using this option and, that we add a new section comparing the
> keyed-MD5 transform used in this protocol versus using an HMAC with
> MD5. Vendors who choose to implement this option and customers who
> choose to use it will be able to assess the level of security provided
> by this feature.
> 
> Luis

These seem like reasonable changes.  We may need two more TCP option
numbers for HMAC with MD5 and HMAC with SHA-1 or one more option and a
algorithm type (two bytes is plenty).  The TCP option 19 is already in
widespread use so we'd need to get another number.

The security consideration section could then state that:

   This document defines a weak but currently practiced security
   mechanism for BGP using MD5 and a incremental improvement using an
   HMAC with MD5 or an HMAC with SHA-1.  It is anticipated that future
   work will provide different stronger mechanisms for dealing with
   these issues.

Perhaps the author of the draft should comment rather than me (or
someone that knows what they are talking about rather than me :).

Curtis

ps- for us near crypto illiterates could you point to some consise
references that explain HMAC with MD5 and HMAC with SHA-1.


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id GAA17054 for <[e-mail]>; Wed, 29 Jul 1998 06:01:09 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA28127 for idr-outgoing; Wed, 29 Jul 1998 05:52:11 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id FAA28123 for <[e-mail]>; Wed, 29 Jul 1998 05:52:08 -0400 (EDT)
Received: from hotmail.com (f132.hotmail.com [207.82.251.11]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id FAA15821 for <[e-mail]>; Wed, 29 Jul 1998 05:52:07 -0400 (EDT)
Received: (qmail 2801 invoked by uid 0); 29 Jul 1998 09:51:35 -0000
Message-ID: <[e-mail]>
Received: from 207.53.175.75 by www.hotmail.com with HTTP; Wed, 29 Jul 1998 02:51:35 PDT
X-Originating-IP: [207.53.175.75]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Subject: RFC 1771 Section 9.1 clarification
Content-Type: text/plain
Date: Wed, 29 Jul 1998 02:51:35 PDT
Sender: [e-mail]
Precedence: bulk

Folks, 
I have few more BGP questions

1. 9.1 ) Decision Process
 a) Phase 1 is responsible for calculating the degree of preference
    for each route received from an external peer, and for advertising
    to the other internal peers.

   9.1.1 ) Phase 1: Calculation of degree of preference
       ...
       ...
        If the route is learnt from an internal peer, the value of the
     LOCAL_PREF...

There seems to be a contradiction. The definition a) states Phase 1
is responsible for operating on routes from "external peer". The section 
9.1.1 says "If the route is learnt from an internal peer"

2.
   Suppose a prefix 'p'(nexthop is 'nh') is learnt from a IBGP peer 
   a) does BGP install the prefix 'p' into the forwarding table or an 
IGP has to do it?
      Section 9.1.2 Phase 2: Route selection  says we should consider 
all routes from both internal and external peers.
      So i take it that answer to the question a) is that BGP has to 
install the prefix 'p' into the forwarding table. (In that case if the 
IGP learns about the same prefix, one of them must be given a 
preference?)
    b)  And does IGP reachability to nexthop 'nh' guarantee IGP 
reachability for prefix 'p' for our immediate IGP nexthop?
       
    c) How can the IGP reachability of prefix 'p' be ascertained if BGP 
is to install the route for 'p' into the forwarding table according to 
a)

Thanks a lot for your time,
-Jaihari.

 

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id UAA05019 for <[e-mail]>; Tue, 28 Jul 1998 20:18:45 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA22490 for idr-outgoing; Tue, 28 Jul 1998 20:16:40 -0400 (EDT)
Received: from nutmeg.bbn.com (NUTMEG.bbn.com [128.89.1.112]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA22483 for <[e-mail]>; Tue, 28 Jul 1998 20:16:35 -0400 (EDT)
Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.7/8.8.7) id UAA00698; Tue, 28 Jul 1998 20:13:31 GMT (envelope-from lsanchez)
From: "Luis A. Sanchez" <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
In-Reply-To: <[e-mail]> from Sandy Murphy at "Jul 28, 98 05:55:40 pm"
To: [e-mail] (Sandy Murphy)
Date: Tue, 28 Jul 1998 20:13:31 +0000 (GMT)
Cc: [e-mail], [e-mail]
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Sandy,

	I should have read the archive first, my apologies once
again. I'm glad to hear these discussions took place in the list
although I'm surprised to see that the document didn't reflect the
technical outcome of these discussions. I understand implementation
concerns, time to market issues, etc. still, it would seem to me that
while we all await for the deployment of IPSec in our favorite routers
it *might* be prudent to make "minor" modifications to what we have
available. Just a thought...

Luis


> The security weaknesses of the MD5 approach were discussed in the mailing
> list last December and January.  You can see the archive at
>  ftp://ftp.merit.edu/mail.archives/idr.  The replay problem, the preference
> for HMAC rather than plain MD5, the need for rollover of keys, etc were
> mentioned there.  But others argured that this was good to implement until
> a better authentication mechanism was specified and easy to put into
> specification because it was already (widely) implemented.             




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id TAA03032 for <[e-mail]>; Tue, 28 Jul 1998 19:35:53 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA21741 for idr-outgoing; Tue, 28 Jul 1998 19:31:48 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA21728 for <[e-mail]>; Tue, 28 Jul 1998 19:31:39 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id QAA21966; Tue, 28 Jul 1998 16:31:07 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id QAA08121; Tue, 28 Jul 1998 16:31:02 -0700 (PDT)
To: [e-mail] (Sandy Murphy)
cc: [e-mail]
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
References: <[e-mail]>
From: Tony Li <[e-mail]>
Date: 28 Jul 1998 16:31:02 -0700
In-Reply-To: [e-mail]'s message of 28 Jul 98 21:55:40 GMT
Message-ID: <[e-mail]>
Lines: 12
X-Mailer: Gnus v5.3/Emacs 19.34
Sender: [e-mail]
Precedence: bulk

[e-mail] (Sandy Murphy) writes:

> I think everyone agrees that the best solution would be to run your TCP
> session over a suitably protected IPSEC link.  The problem is whether
> IPSEC is available soon enough and enough places.


Given that TCP MD5 has been deployed for quite a while, and IPSEC still
isn't, I think that IPSEC wasn't 'soon enough'.  ;-)


Tony


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id SAA01622 for <[e-mail]>; Tue, 28 Jul 1998 18:08:34 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA20235 for idr-outgoing; Tue, 28 Jul 1998 18:04:44 -0400 (EDT)
Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA20231 for <[e-mail]>; Tue, 28 Jul 1998 18:04:40 -0400 (EDT)
Received: by relay.hq.tis.com; id RAA06142; Tue, 28 Jul 1998 17:59:50 -0400 (EDT)
Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma006119; Tue, 28 Jul 98 17:58:57 -0400
Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id RAA08050; Tue, 28 Jul 1998 17:55:40 -0400 (EDT)
Date: Tue, 28 Jul 1998 17:55:40 -0400 (EDT)
From: Sandy Murphy <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

Luis, I'm sorry I opened my big mouth.           

The security weaknesses of the MD5 approach were discussed in the mailing
list last December and January.  You can see the archive at
 ftp://ftp.merit.edu/mail.archives/idr.  The replay problem, the preference
for HMAC rather than plain MD5, the need for rollover of keys, etc were
mentioned there.  But others argured that this was good to implement until
a better authentication mechanism was specified and easy to put into
specification because it was already (widely) implemented.             

Procedure-wise,                                         
- the notes of the working group meeting said that it was the consensus
  that the draft be moved forward as PS
- the routing area director questioned that decision
- a discussion took place on the mailing list, with (as stated above) some
  arguing against PS and suggesting BCP because of the vulnerabilities and
  others arguing for PS to motivate vendors to implement 
- the working group chair sent it to the IESG requesting PS
- two rounds of minor changes to the draft occured
- the IESG approved the draft as an RFC at PS 

and then of course, with an incomplete memory of the outcome of the discussion
of Dec/Jan, I brought the whole thing up again.                             

And as a final note, yes, the term "digital signature" is usually reserved
in crypto circles to describe a public key technique that exhibits the
attribute of "non-repudiation".  I have seen the keyed-MD5 technique called
"keyed cryptographic hash" and the term "Message Authentication Code" is
sometimes used for a symmetric integrity+authentication check.  But         
terminology is not the biggest problem here.

I think everyone agrees that the best solution would be to run your TCP
session over a suitably protected IPSEC link.  The problem is whether
IPSEC is available soon enough and enough places.

--Sandy


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id QAA00548 for <[e-mail]>; Tue, 28 Jul 1998 16:25:10 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA18684 for idr-outgoing; Tue, 28 Jul 1998 16:17:58 -0400 (EDT)
Received: from nutmeg.bbn.com (NUTMEG.bbn.com [128.89.1.112]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA18680 for <[e-mail]>; Tue, 28 Jul 1998 16:17:54 -0400 (EDT)
Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.7/8.8.7) id QAA00388; Tue, 28 Jul 1998 16:14:51 GMT (envelope-from lsanchez)
From: "Luis A. Sanchez" <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
In-Reply-To: <[e-mail]> from Curtis Villamizar at "Jul 28, 98 11:42:12 am"
To: [e-mail]
Date: Tue, 28 Jul 1998 16:14:50 +0000 (GMT)
Cc: [e-mail], [e-mail], [e-mail]
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> Are there any objections to the content of the draft (holes that need
> to be plugged other than weakness in MD5?).
> 
> Curtis
> 

Curtis,

	there are some problems with the draft "Protection of BGP
Sessions via the TCP MD5 Signature Option" aside from using MD5 as
_the_ hash function. I did not check the idr archive so maybe someone
already made these suggestions. If so, please accept my apologies for
wasting your bandwidth. Some of the suggestions listed below will only
affect the draft and others will affect the implementation. First, the
easy ones:

- I found eight instances (not counting the title) of the word
"signature" in the document. This should be changed to "Integrity
Check Value (ICV)" or "authenticator" I prefer the latter but both
terms will be appropriate in this context.

Explanation: The protocol carries a keyed-hash as a TCP option. The
keys are pre-established manually and are common (of course) to both
ends of the communication. In RSA, a signature consists of a hash
encrypted with the sender's private key. In DSA, a signature consists
of a hash that has been modified by a signature function that depends
on the sender's private key and some other public values known to both
principals. This TCP option is only hashing the TCP segment and
nothing else. No encryption or modification of the hash is performed
on the segment before it flows down the stack. Based on the argument
provided above I suggest we change the title of the I-D to TCP MD5
Integrity Check Value (ICV) Option and edit the rest of the document
accordingly.

- There are some residual vulnerabilities in the protocol that i think
should be mentioned. For example, the fact that the keys are
configured manually (since there is no automated key management
facility) implies that these keys will exist for a reasonable amount
of time, certainly longer than a single TCP connection since no-one
will be reconfiguring the keys manually after every route flap, hard
reset or TCP FIN for that matter. THis means that the opportunity
exists for an attacker to replay old traffic that could cause
interesting problems. Of particular interest, would be recorded
traffic carrying hard resets. This traffic would succesfully pass the
ICV validation. The trick is in mapping the sequence numbers, which
could be done. Although it is harder than it used to be. This changes
will affect section 4.1 and will probably require a new section too.

- One would want to specify key sizes and ranges to be used in
conjuction with MD5. This will allow one to assess the level of
security being offered by this mechanism. Security through obscurity
(intentionally or not) has proven to be the wrong approach.  Hence,
section 4.5 needs some more explanation and clarification.

Now, the hard ones:

- The use of a hash algorithm in this keyed fashion (Keyed-MD5) has
been disparaged in the literature for two years, prompting changes in
the IPsec RFCs; it seems inappropriate to promote the use of this sort
of authentication technology in a newly issued RFC.  Personally, i
think we should provide an HMAC with either with the option of using
it with either (MD5 or SHA-1). 

I think that minimum we should modify section 4.4 since it gives the
impression that the collison problem of MD5 is the only problem with
using this option and, that we add a new section comparing the
keyed-MD5 transform used in this protocol versus using an HMAC with
MD5. Vendors who choose to implement this option and customers who
choose to use it will be able to assess the level of security provided
by this feature.

Luis




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id LAA12046 for <[e-mail]>; Tue, 28 Jul 1998 11:50:39 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA14302 for idr-outgoing; Tue, 28 Jul 1998 11:42:34 -0400 (EDT)
Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA14298 for <[e-mail]>; Tue, 28 Jul 1998 11:42:29 -0400 (EDT)
Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.8/8.8.8) with ESMTP id LAA01328; Tue, 28 Jul 1998 11:42:12 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Sandy Murphy <[e-mail]>
cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard??? 
In-reply-to: Your message of "Mon, 27 Jul 1998 13:45:16 EDT." <[e-mail]> 
Date: Tue, 28 Jul 1998 11:42:12 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Sandy Murphy writes:
> 
> And I obviously missed the fact in the last call that it was being
> advanced as Proposed Standard, also.  Which troubles me, because I
> try to pay particular attention to security related standards.
> 
> --Sandy


We've been back and forth and at the last meeting it was agreed that
PS was fine since we can always obsolete it if something better comes
along (most likely IPSEC standards get implemented).

One argument in favor of PS was that to the extent that IETF has any
effect on what vendors do, a PS gives vendors more incentive to do
more than nothing while waiting for the ultimate solution.

Are there any objections to the content of the draft (holes that need
to be plugged other than weakness in MD5?).

Curtis


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id PAA02657 for <[e-mail]>; Mon, 27 Jul 1998 15:48:41 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA01330 for idr-outgoing; Mon, 27 Jul 1998 15:40:12 -0400 (EDT)
Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA01326 for <[e-mail]>; Mon, 27 Jul 1998 15:40:07 -0400 (EDT)
Received: by relay.hq.tis.com; id PAA04203; Mon, 27 Jul 1998 15:35:18 -0400 (EDT)
Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma004190; Mon, 27 Jul 98 15:35:01 -0400
Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id PAA02996; Mon, 27 Jul 1998 15:31:51 -0400 (EDT)
Date: Mon, 27 Jul 1998 15:31:51 -0400 (EDT)
From: Sandy Murphy <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

Thanks, Pedro.  Particularly for being kind.

I did what I should have done in the first place and checked the
archive.  Given that I've muddied the water here, I thought I'd better
review the history.

The discussion of PS vs BCP took place over a couple of weeks after
the Dec 97 IETF.  Joel Halpern opened the discussion with a question
as to "whether proposed standard is the correct status for this
document".  The two Tony's (Li and Przygienda) argued that PS was not
right, but BCP was reasonable.  Curtis argued that this was needed
right now and PS "sent a message" that might convince the vendors to
implement.  No final word was heard from Joel.

Yakov transferred the draft to the IESG, which announced a last call
in February.  In March a new draft was announced (extremely minor
changes from the draft discussed in Dec).  At the end of June another
minor revision was announced (this one our automatic retrieval missed).

I was remembering the discussion from early this year and subsequent
brief discussions with other folk at the March IETF when I asked about
BCP.

My apologies for asking instead of finding out for myself.

--Sandy Murphy


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id PAA02611 for <[e-mail]>; Mon, 27 Jul 1998 15:42:49 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA01119 for idr-outgoing; Mon, 27 Jul 1998 15:28:06 -0400 (EDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by merit.edu (8.8.7/8.8.5) with SMTP id PAA01111 for <[e-mail]>; Mon, 27 Jul 1998 15:28:01 -0400 (EDT)
Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Jul 27 15:26:24 EDT 1998
Received: from prz-laptop.dnrc.bell-labs.com (prz-laptop [135.180.130.120]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA08705; Mon, 27 Jul 1998 15:26:23 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 27 Jul 1998 15:22:36 -0400
From: Antoni Przygienda <[e-mail]>
Organization: Bell Labs, Lucent
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: Sandy Murphy <[e-mail]>
CC: [e-mail]
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
X-Priority: 3 (Normal)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Sandy Murphy wrote:

> I just saw an announcement that the Protection of BGP Sessions via the
>
> TCP MD5 Signature Option draft was being put forward as a Proposed
> Standard.
>
> I hope that I won't hear a chorus of "For God's sake - where have
> you been!".  But I thought that this was going to be proposed as a
> BCP, not a PS.  If the idr group is going to propose a standard for
> protecting BGP, then more work needs to be done with the TCP MD5
> option.
> The option documents an existing practice and deservedly so.  But the
> existing practice was put into practice before many of the advances
> in the use of MD5 for integrity and authentication protection were
> known.  It doesn't use some of the ideas that have developed in the
> ipsec
> group like using HMAC and replay protection.
>

As far I remember, the facts you're stating are correct, Sandy ... but I
guess one would have to check the minutes to be sure here.
        --- tony

> And this is somewhat my fault, because I have not revised the draft I
> presented before the group last December to include more discussion of
>
> the differences between doing IPSEC, the TCP MD5 proposal or the
> proposal that was made at the same time of doing MD5 at the BGP layer.
>
> Can someone set me straight here?
>
> And I obviously missed the fact in the last call that it was being
> advanced as Proposed Standard, also.  Which troubles me, because I
> try to pay particular attention to security related standards.





Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id OAA02054 for <[e-mail]>; Mon, 27 Jul 1998 14:35:55 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA29968 for idr-outgoing; Mon, 27 Jul 1998 14:33:12 -0400 (EDT)
Received: from quisp.cisco.com (quisp.cisco.com [171.69.95.82]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA29961 for <[e-mail]>; Mon, 27 Jul 1998 14:33:08 -0400 (EDT)
Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by quisp.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id LAA25876; Mon, 27 Jul 1998 11:32:37 -0700 (PDT)
Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA28916; Mon, 27 Jul 1998 11:32:37 -0700 (PDT)
Date: Mon, 27 Jul 1998 11:32:37 -0700 (PDT)
Message-Id: <[e-mail]>
From: Pedro Marques <[e-mail]>
To: Sandy Murphy <[e-mail]>
Cc: [e-mail]
Subject: using the TCP MD5 protection for BGP - Proposed Standard???
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>>>>> "Sandy" == Sandy Murphy <[e-mail]> writes:

    Sandy> I just saw an announcement that the Protection of BGP
    Sandy> Sessions via the TCP MD5 Signature Option draft was being
    Sandy> put forward as a Proposed Standard.

    Sandy> I hope that I won't hear a chorus of "For God's sake -
    Sandy> where have you been!".

Sandy,
My personal recollection is that the IDR wg has decided that the TCP MD5
document should be advanced as Proposed Standard in the December meeting
in D. C. This after considering the alternative of publishing the document
has BCP. I believe that the group agreed that publishing this document as
PS would not preclude the group to work on another method(s) for
authentication.

regards,
  Pedro.


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id OAA01844 for <[e-mail]>; Mon, 27 Jul 1998 14:02:22 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA29188 for idr-outgoing; Mon, 27 Jul 1998 13:54:06 -0400 (EDT)
Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA29177 for <[e-mail]>; Mon, 27 Jul 1998 13:54:01 -0400 (EDT)
Received: by relay.hq.tis.com; id NAA24633; Mon, 27 Jul 1998 13:49:13 -0400 (EDT)
Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma024567; Mon, 27 Jul 98 13:48:25 -0400
Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id NAA24316; Mon, 27 Jul 1998 13:45:16 -0400 (EDT)
Date: Mon, 27 Jul 1998 13:45:16 -0400 (EDT)
From: Sandy Murphy <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: using the TCP MD5 protection for BGP - Proposed Standard???
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

I just saw an announcement that the Protection of BGP Sessions via the 
TCP MD5 Signature Option draft was being put forward as a Proposed
Standard.

I hope that I won't hear a chorus of "For God's sake - where have
you been!".  But I thought that this was going to be proposed as a
BCP, not a PS.  If the idr group is going to propose a standard for
protecting BGP, then more work needs to be done with the TCP MD5 option.
The option documents an existing practice and deservedly so.  But the
existing practice was put into practice before many of the advances
in the use of MD5 for integrity and authentication protection were
known.  It doesn't use some of the ideas that have developed in the ipsec
group like using HMAC and replay protection.

And this is somewhat my fault, because I have not revised the draft I
presented before the group last December to include more discussion of
the differences between doing IPSEC, the TCP MD5 proposal or the
proposal that was made at the same time of doing MD5 at the BGP layer.

Can someone set me straight here?

And I obviously missed the fact in the last call that it was being
advanced as Proposed Standard, also.  Which troubles me, because I
try to pay particular attention to security related standards.

--Sandy


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id MAA00745 for <[e-mail]>; Mon, 27 Jul 1998 12:01:17 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA26376 for idr-outgoing; Mon, 27 Jul 1998 11:49:34 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA26371 for <[e-mail]>; Mon, 27 Jul 1998 11:49:29 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA17335; Mon, 27 Jul 1998 11:47:08 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>
Cc: [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: Protection of BGP Sessions via the TCP MD5 Signature Option to Proposed Standard
Date: Mon, 27 Jul 1998 11:47:08 -0400
Sender: [e-mail]
Precedence: bulk

The IESG has approved the Internet-Draft 'Protection of BGP Sessions
via the TCP MD5 Signature Option' <draft-idr-bgp-tcp-md5-01.txt>
as a Proposed Standard.  This document is the product of the
Inter-Domain Routing Working Group.  The IESG contact person is Rob Coltun. 
 
Technical Summary
 
 This protocol extension provide a way for BGP-4 peers to authenticate that
 the TCP messages they are receiving are actually from their peers.  This
 prevents or increases the difficulty of a number of attacks against the
 protocol machinery.

Working Group Summary

 The working group strongly supports this as the best current mechanism
 to address these important security threats.

Protocol Quality

 This specification was reviewed for the IESG by Joel M. Halpern, the
 Routing Area Director.  It is already widely implemented.



Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id BAA02713 for <[e-mail]>; Mon, 27 Jul 1998 01:37:26 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id BAA20190 for idr-outgoing; Mon, 27 Jul 1998 01:30:00 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id BAA20186 for <[e-mail]>; Mon, 27 Jul 1998 01:29:56 -0400 (EDT)
From: [e-mail]
Received: from UPIMSRGSMTP06 (upimsrgsmtp06.msn.com [207.68.152.50]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id BAA27879 for <[e-mail]>; Mon, 27 Jul 1998 01:29:55 -0400 (EDT)
Received: from galazka.ibm.net - 153.35.59.174 by msn.com with Microsoft SMTPSVC; Sun, 26 Jul 1998 22:29:05 -0700
To: web@marketing
Subject: Comprehensive manual reveals powerful Internet marketing techniques!
Message-ID: <[e-mail]>
Date: 26 Jul 1998 22:29:22 -0700
Sender: [e-mail]
Precedence: bulk

       NEED TO INCREASE THE TRAFFIC TO YOUR WEBSITE?

         NOT MAKING ENOUGH MONEY ON THE INTERNET?

   WANT REAL-WORLD STRATEGIES INCLUDING CASE STUDIES?


  The Web Marketing Bible will MAXIMIZE your success!


New websites are being built every day on the web.  Most
of them receive very little traffic, but there are some
that receive MIND-BLOWING numbers of visitors.


     Ever Wondered How the VERY SUCCESSFUL Websites
              Generate That Much Traffic?


  Now you too can have an EXTREMELY successful site!


The Web Marketing Bible is over 300 pages and outlines
ONLY the most powerful marketing techniques to get HUGE
amounts of traffic to your website.


It tells you EXACTLY what to do step-by step - even if
you know next to nothing about computers.  Many of the
top income earners on the web know very little about
computers - WHAT THEY DO KNOW IS MARKETING.  That's 
exactly what this comprehensive manual will make you
a master of.


The Web Marketing Bible is THE SINGLE BEST source of
completely up-to-date marketing strategies.  Nothing
else is written in such an easy to understand yet
comprehensive manner.  It's MUCH more powerful than all
of the other marketing information you see out there. 


Here's what you will learn:

()  A simplified system to conquer the search engines
    -  without spending gobs of time

()  How to REALLY use links with other site to explode
    your hit count

()  How to QUICKLY develop a "house list" of people to
    whom you continually market - it's much easier than
    constantly chasing after new visitors.  One of the
    authors is making over $100,000 per year with a
    house list he built in his first 5 months on-line!

()  How to use e-mail marketing successfully

()  Step-by-step info on how to use the newsgroups to
    drive brand-new visitors to your site in DROVES!

()  How to see if your page is built properly to rank
    high on the search engines

()  Case studies of several online marketing startegies
    -  You'll see exactly what works (and what doesn't). 

()  How to set up SIMPLE virtual stores that pull orders
    consistently month after month - with little or no
    ongoing marketing after the inital set-up.  You'll
    finally do the very thing we've all heard about -
    make money while you sleep!  What a great feeling! 


The Web Marketing Bible was written by people you don't
come across very often on the web - people that have
developed VERY successful websites.  These three authors
explain EXACTLY what they do to market their websites.
The manual is written in a style that clearly 
demonstrates their experience with on-line marketing.

You'll also get a subscription to the WEBSITE MARKETING
newsletter, which will keep you completely up-to-date with
the absolute latest marketing strategies. You'll also be 
able to "hook up" with other subscribers who also want to
make their sites more successful to exchange both links 
& ideas.

        You Won't Be By Yourself In Cyberspace

      You'll Be On A Team That's Pulling For You!


Here's what some previous buyers have said:

"Thanks again.  I was completely ignoring the search
engines in my online marketing efforts.  I never really
knew how important they could be.  I'm glad you "showed
me the light".  It has become the easiest marketing
method in my arsenal.  You put me in the top 5 on
Infoseek in less than one hour!  After the few times I
had tried to get on the search engines myself, I 
couldn't even find myself in the top 150!  All I do now
to keep my ranking as high as possible is to run the
two software programs you told me to.  You have paid for
yourselves many times over!"
--M.C., Maryland

"You guys are incredible.  I spent a lot of money
getting my site up and was so disappointed at my
traffic.  Then I got the [Web Marketing Bible] and sat
down with it over the weekend.  I started marketing on
newsgroups and building my house list.  I now get orders
EVERY SINGLE DAY!  I have literally made thousands of
dollars on the internet in less than two months!  And I
barely know how to get myself on-line!  Thanks a
million.  You've really shown me what's possible on the
Internet.  You guys are first-class!"
--D.W., MBA

"Your marketing strategies took my hits from 1-5 per
week to over 200!  I hope my competition doesn't find
out about you!"
--S.J., Pennsylvania


THIS IS THE BEST SHOT YOU'VE EVER HAD TO DEVELOP A 
SUPER SUCCESSFUL WEBSITE!

If after purchasing the Web Marketing Bible and imp-
lementing its strategies, you haven't experienced the 
success you've been looking for, GET OFF THE WEB OR
DEVELOP A TOTALLY DIFFERENT SITE.  At least you'll 
know that you have done everything humanly possible 
to make your website a success.


    This may be the last investment in your website 
             you'll EVER need to make!


For only $119 you can learn EVERY Single Secret to 
making your website an Internet success story!


       NEED ANSWERS FOR YOUR SPECIFIC SITUATION?

  GIVE US A CALL!  WE'D LOVE TO ANSWER YOUR QUESTIONS!

                      410-321-4508
                    or order by mail:


                         WSR
                      PO BOX 974
                  Baltimore MD 21022




***To be removed from our mailing list, 
please hit "REPLY"!





Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id UAA21839 for <[e-mail]>; Sat, 25 Jul 1998 20:39:51 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA08964 for idr-outgoing; Sat, 25 Jul 1998 20:33:25 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA08960 for <[e-mail]>; Sat, 25 Jul 1998 20:33:22 -0400 (EDT)
Received: from hotmail.com (f227.hotmail.com [207.82.251.118]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id UAA28279 for <[e-mail]>; Sat, 25 Jul 1998 20:33:20 -0400 (EDT)
Received: (qmail 28581 invoked by uid 0); 26 Jul 1998 00:32:49 -0000
Message-ID: <[e-mail]>
Received: from 208.227.187.166 by www.hotmail.com with HTTP; Sat, 25 Jul 1998 17:32:49 PDT
X-Originating-IP: [208.227.187.166]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Subject: Implementation question
Content-Type: text/plain
Date: Sat, 25 Jul 1998 17:32:49 PDT
Sender: [e-mail]
Precedence: bulk

Folks,
     I have an implementation question.
     From the RFC, it appears to me the only state information that
     need to be maintained about a route advertised to a peer is that
        whether the route was advertised to the peer or not.
     Is this a correct assumption, or are there other issues i am not
     seeing here.
Thank you,
-Jaihari.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id MAA19216 for <[e-mail]>; Thu, 23 Jul 1998 12:49:51 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA05166 for idr-outgoing; Thu, 23 Jul 1998 12:44:02 -0400 (EDT)
Received: from merit.edu ([e-mail] [198.108.60.89]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA05162; Thu, 23 Jul 1998 12:43:44 -0400 (EDT)
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: "jaihari loganathan" <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: RFC 1771 dynamic policy configuration 
In-reply-to: Your message of "Thu, 23 Jul 1998 02:34:45 PDT." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 23 Jul 1998 12:43:44 -0400
From: Susan Hares <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jaihari:

We did have something like this in the IDRP specification.
We had a "request" rib sequence.  We can raise this issue
again.  I think we could get an implementation of this
in Gated.

Sue



Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id LAA17310 for <[e-mail]>; Thu, 23 Jul 1998 11:23:44 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA03504 for idr-outgoing; Thu, 23 Jul 1998 11:18:16 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA03498 for <[e-mail]>; Thu, 23 Jul 1998 11:18:11 -0400 (EDT)
Received: from phoenix.ficon-tech.com (phoenix.ficon-tech.com [209.125.90.2]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id LAA15408 for <[e-mail]>; Thu, 23 Jul 1998 11:18:08 -0400 (EDT)
Received: from ficon-tech.com (192.168.137.12) by phoenix.ficon-tech.com (Worldmail 1.3.167) for [e-mail]; 23 Jul 1998 11:21:01 -0400
Message-ID: <[e-mail]>
Date: Thu, 23 Jul 1998 11:22:30 -0400
From: Rajesh Saluja <[e-mail]>
Reply-To: [e-mail]
Organization: Ficon Technology, Inc.
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
Subject: Corrections required in RFC 1771 Finite state machine
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I see some confusions in RFC 1771 in Connect and Active State of BGP
Finite State machine. IMHO RFC should be corrected to avoid these
confusions.

1. PNo 30, Connect State
RFC says - "Start event is ignored in the Active state"
Comments: It looks like a cut and paste problem. It should say: " Start
event is ignored in the Connect state".

2. PNo 30, Active State
RFC says- " In this state BGP is trying to acquire a peer by initiating
a transport protocol connection"
Comments: I think that in this state BGP is just listening for the
connection ( it is not initiating). It should say " In this state BGP is
trying to acquire a transport protocol connection initiated by the
peer".

Please comment on this.

Thanks,
Rajesh
--
----------------------------------------------------------------------
Rajesh Saluja
Ficon Technology                 Voice:  [phone] ext 322
1000 Route 9 North               Fax  :  [phone]
Woodbridge, NJ 07095             mailto:[e-mail]
---------------------------------------------------------------------




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id FAA14390 for <[e-mail]>; Thu, 23 Jul 1998 05:45:13 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA28711 for idr-outgoing; Thu, 23 Jul 1998 05:35:22 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id FAA28699 for <[e-mail]>; Thu, 23 Jul 1998 05:35:17 -0400 (EDT)
Received: from hotmail.com (f172.hotmail.com [207.82.251.58]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id FAA24347 for <[e-mail]>; Thu, 23 Jul 1998 05:35:16 -0400 (EDT)
Received: (qmail 12634 invoked by uid 0); 23 Jul 1998 09:34:45 -0000
Message-ID: <[e-mail]>
Received: from 208.227.187.166 by www.hotmail.com with HTTP; Thu, 23 Jul 1998 02:34:45 PDT
X-Originating-IP: [208.227.187.166]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Subject: RFC 1771  dynamic policy configuration
Content-Type: text/plain
Date: Thu, 23 Jul 1998 02:34:45 PDT
Sender: [e-mail]
Precedence: bulk

Folks,
     It seems to me to support dynamic policy configuration, it 
     would be very useful if BGP protocol has some  
     mechanism for TABLE REQUEST, TABLE RESPONSE  
     to obtain the entire routing table from a peer(EBGP) at any
     arbitrary time without having to reset the peer connection.
     Otherwise inbound policy change will require all inbound routes
     to be stored.

     Any thoughts on this?

Thank You,
-Jaihari.


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id WAA25287 for <[e-mail]>; Tue, 21 Jul 1998 22:47:38 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA29552 for idr-outgoing; Tue, 21 Jul 1998 22:44:33 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id WAA29548 for <[e-mail]>; Tue, 21 Jul 1998 22:44:29 -0400 (EDT)
Received: from docholliday.softaware.com ([e-mail] [206.83.160.64]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id WAA00818 for <[e-mail]>; Tue, 21 Jul 1998 22:44:28 -0400 (EDT)
Received: from docholliday.softaware.com ([e-mail] [206.83.160.64]) by docholliday.softaware.com (8.8.7/8.8.7) with SMTP id TAA02048; Tue, 21 Jul 1998 19:44:35 -0700
Date: Tue, 21 Jul 1998 19:44:35 -0700 (PDT)
From: "Jason L. Weisberger" <[e-mail]>
To: jaihari loganathan <[e-mail]>
cc: [e-mail]
Subject: Re: BGP policy question
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>      Is it possible to enforce a policy that mandates we only advertise 
> routes learnt from P3 to P2.

yes, but wouldn't you rather give them your best route and not your
alternate?

>     
>      Since the route to the prefix 'p' from P3 is only a second best
>       route, if this policy is enforced, we will be barred from
>       advertising to P2 the route from P1 (which the local speaker
>       itself uses), while we cannot advertise the route from P3 because 
> it violates BGP's policy of only advertising the local speaker
>       itself uses.
> 
> Thank You,
> -J
>     
> 
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
> 

--
Jason Weisberger
Chief Technology Officer
SoftAware, Inc. - 310/305-0275

...but the wicked shall do wickedly...
--Daniel 12:10




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id VAA24660 for <[e-mail]>; Tue, 21 Jul 1998 21:27:31 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA28773 for idr-outgoing; Tue, 21 Jul 1998 21:24:56 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA28769 for <[e-mail]>; Tue, 21 Jul 1998 21:24:50 -0400 (EDT)
Received: from syzygy.ieng.com (syzygy.ieng.com [207.24.215.2]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id VAA28307 for <[e-mail]>; Tue, 21 Jul 1998 21:24:49 -0400 (EDT)
Received: from [146.115.140.239] (slip166-72-85-28.ny.us.ibm.net [166.72.85.28]) by syzygy.ieng.com (8.8.5/8.7.3) with ESMTP id VAA00210; Tue, 21 Jul 1998 21:24:41 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: [e-mail]
Message-Id: <v04011709b1daf92441c0@[146.115.140.239]>
In-Reply-To: <[e-mail]>
Date: Tue, 21 Jul 1998 21:05:37 -0500
To: "jaihari loganathan" <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: BGP policy question
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

At 3:18 PM -0700 7/21/98, jaihari loganathan wrote:
>     Suppose a BGP implementation is peering with three peers
>     P1,P2,P3
>
>     A prefix 'p' is learnt from P1 and P3 and the policy decides
>     that we use the route from P1 as the best route and that from
>     P3 is installed as an alternate route.
>
>     Is it possible to enforce a policy that mandates we only advertise
>routes learnt from P3 to P2.

Sure.

>     Since the route to the prefix 'p' from P3 is only a second best
>      route, if this policy is enforced, we will be barred from
>      advertising to P2 the route from P1 (which the local speaker
>      itself uses), while we cannot advertise the route from P3 because
>it violates BGP's policy of only advertising the local speaker
>      itself uses.

That is correct.

Regards,

--John
--
John Scudder                        email:  [e-mail]
Internet Engineering Group, LLC     phone:  [phone] x14
122 S. Main, Suite 280              fax:    [phone]
Ann Arbor, MI  48104                www:    http://www.ieng.com


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id TAA23573 for <[e-mail]>; Tue, 21 Jul 1998 19:23:40 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA27000 for idr-outgoing; Tue, 21 Jul 1998 19:21:18 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA26996 for <[e-mail]>; Tue, 21 Jul 1998 19:21:13 -0400 (EDT)
Received: from smtp-gw.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id TAA24736 for <[e-mail]>; Tue, 21 Jul 1998 19:21:12 -0400 (EDT)
Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by smtp-gw.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id QAA27672; Tue, 21 Jul 1998 16:20:42 -0700 (PDT)
Received: from lobster1.corpeast.Baynetworks.com (ns2.corpeast.baynetworks.com [192.32.72.17]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with SMTP id QAA26526; Tue, 21 Jul 1998 16:20:33 -0700 (PDT)
Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-nf0)  by lobster1.corpeast.Baynetworks.com (4.1/BNET-97/04/29-S) id AA25959; Tue, 21 Jul 98 19:20:38 EDT for [e-mail]
Received: from lee.corpeast.baynetworks.com ([132.245.55.86]) by bl-mail1.corpeast.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13458) with SMTP id AAA8530; Tue, 21 Jul 1998 19:20:32 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 21 Jul 1998 19:20:23 -0400
To: "jaihari loganathan" <[e-mail]>, [e-mail]
From: [e-mail] (Lee Ingersoll)
Subject: Re: BGP policy question
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 03:18 PM 7/21/98 PDT, jaihari loganathan wrote:

>Folks,

>     Suppose a BGP implementation is peering with three peers

>     P1,P2,P3

>

>     A prefix 'p' is learnt from P1 and P3 and the policy decides

>     that we use the route from P1 as the best route and that from

>     P3 is installed as an alternate route.

>

>     Is it possible to enforce a policy that mandates we only advertise 

>routes learnt from P3 to P2.


You can define a policy which will only announce P3 learned routes to P2.  Since the P3 route is not the BEST route, P1's will be installed into your routing table and this will be the one announced.  Your announce policy to P2 will force this route (p) to NOT be announced to P2.  Therefore, P2 won't learn of route P from you.


Why are you trying to send P3's prefix to P2 when your router selects P1's as the best?  What's your goal?  If P2 must go through you to get to 'p', what does it care whether it came from P1 or P3?  Can P2 access P3 directly or must it go through you anyway?  If it can access it directly, you could override the NEXT HOP.  Or if P2 is looking at the AS PATH, modify it prior to announcing to P2.  Whatever you do _be careful_ you don't create routing loops, or black holes (if P3 goes away).  


Lee

  

>    

>     Since the route to the prefix 'p' from P3 is only a second best

>      route, if this policy is enforced, we will be barred from

>      advertising to P2 the route from P1 (which the local speaker

>      itself uses), while we cannot advertise the route from P3 because 

>it violates BGP's policy of only advertising the local speaker

>      itself uses.

>

>Thank You,

>-J

>    

>

>______________________________________________________

>Get Your Private, Free Email at http://www.hotmail.com

>



Lee Ingersoll

Corporate Systems Engineer, IP Services

Bay Networks

8 Federal St

Billerica, MA 01821

Voice: 978-916-4610

Pager: <color><param>ffff,0000,0000</param>800-309-0413

</color>mailto:[e-mail]


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id SAA23097 for <[e-mail]>; Tue, 21 Jul 1998 18:24:10 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA26366 for idr-outgoing; Tue, 21 Jul 1998 18:18:46 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA26359 for <[e-mail]>; Tue, 21 Jul 1998 18:18:41 -0400 (EDT)
Received: from hotmail.com (f101.hotmail.com [207.82.250.220]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id SAA22825 for <[e-mail]>; Tue, 21 Jul 1998 18:18:39 -0400 (EDT)
Received: (qmail 17689 invoked by uid 0); 21 Jul 1998 22:18:08 -0000
Message-ID: <[e-mail]>
Received: from 208.227.187.166 by www.hotmail.com with HTTP; Tue, 21 Jul 1998 15:18:08 PDT
X-Originating-IP: [208.227.187.166]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Subject: BGP policy question
Content-Type: text/plain
Date: Tue, 21 Jul 1998 15:18:08 PDT
Sender: [e-mail]
Precedence: bulk

Folks,
     Suppose a BGP implementation is peering with three peers
     P1,P2,P3

     A prefix 'p' is learnt from P1 and P3 and the policy decides
     that we use the route from P1 as the best route and that from
     P3 is installed as an alternate route.

     Is it possible to enforce a policy that mandates we only advertise 
routes learnt from P3 to P2.
    
     Since the route to the prefix 'p' from P3 is only a second best
      route, if this policy is enforced, we will be barred from
      advertising to P2 the route from P1 (which the local speaker
      itself uses), while we cannot advertise the route from P3 because 
it violates BGP's policy of only advertising the local speaker
      itself uses.

Thank You,
-J
    

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id KAA04553 for <[e-mail]>; Mon, 20 Jul 1998 10:16:03 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA27461 for idr-outgoing; Mon, 20 Jul 1998 10:09:24 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA27457 for <[e-mail]>; Mon, 20 Jul 1998 10:09:20 -0400 (EDT)
Received: from phoenix.ficon-tech.com (phoenix.ficon-tech.com [209.125.90.2]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id KAA09991 for <[e-mail]>; Mon, 20 Jul 1998 10:09:17 -0400 (EDT)
Received: from ficon-tech.com (192.168.137.12) by phoenix.ficon-tech.com (Worldmail 1.3.167); 20 Jul 1998 10:11:28 -0400
Message-ID: <[e-mail]>
Date: Mon, 20 Jul 1998 10:13:32 -0400
From: Rajesh Saluja <[e-mail]>
Reply-To: [e-mail]
Organization: Ficon Technology, Inc.
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: jaihari loganathan <[e-mail]>
CC: [e-mail]
Subject: Re: Update message handling RFC1771 section #9
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

jaihari loganathan wrote:

> Folks,
>     I have some questions on the handling of overlapped routes
>     in RFC 1771.
>
> RFC 1771 section # 9 Update Message Handling says:
>
> "ii) If the new route is an overlapping route that is included in an
> earlier route contained in the Adj-RIB-In, the BGP speaker shall run its
> Decision Process since the more specific route has implicitly made a
> portion of the less specific route unavailable for use ."
>
> A) "If the new route is an overlapping route that is included" :
>    Does this mean the new route is a more specific route?

Yes.

>
>
> B)   Let us consider a set of routes described by
>    less specific route 172.16.*.* is in the Adj-RIB-In.
>    And a more specific route 172.16.1.* is incoming.
>    How does this more specific route render 172.16.(0-255 except 1).*
>    unavailable for use?
>    (As they are still reachable by the less specific route
>     172.16.*.*)

Because the more specific route will be given preference. The route for
172.16.*.* will not be used for reaching the destinations described by
172.16.1.*.

>
>
> The next item says :
> iii) "If the new route has identical path attributes to an earlier route
> ........"
>
>     Is (iii) a special extension of ii) where PATH attributes are
>     identical?
>

Yes.

> Another unrelated question :
>
>    If a prefix 'p' is learnt from a BGP peer, is there anything that
>    precludes us from advertizing it back to the peer?
>    (sort of split horizon in distance vector protocols?)
>

You should not send the route back to the peer from whom you have learnt.
Even if you do so, the peer will know this by looking at ASPath and drop
that route.

> Thanks
> -J
>

-Rajesh

--
----------------------------------------------------------------------
Rajesh Saluja
Ficon Technology                 Voice:  [phone] ext 322
1000 Route 9 North               Fax  :  [phone]
Woodbridge, NJ 07095             mailto:[e-mail]
---------------------------------------------------------------------




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id DAA08744 for <[e-mail]>; Sat, 18 Jul 1998 03:05:30 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA02965 for idr-outgoing; Sat, 18 Jul 1998 02:41:29 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id CAA02959 for <[e-mail]>; Sat, 18 Jul 1998 02:41:25 -0400 (EDT)
Received: from hotmail.com (f240.hotmail.com [207.82.251.131]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id CAA14028 for <[e-mail]>; Sat, 18 Jul 1998 02:41:24 -0400 (EDT)
Received: (qmail 24702 invoked by uid 0); 18 Jul 1998 06:40:49 -0000
Message-ID: <[e-mail]>
Received: from 208.227.187.166 by www.hotmail.com with HTTP; Fri, 17 Jul 1998 23:40:49 PDT
X-Originating-IP: [208.227.187.166]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Subject: Update message handling RFC1771 section #9
Content-Type: text/plain
Date: Fri, 17 Jul 1998 23:40:49 PDT
Sender: [e-mail]
Precedence: bulk

Folks,
    I have some questions on the handling of overlapped routes
    in RFC 1771.

RFC 1771 section # 9 Update Message Handling says:

"ii) If the new route is an overlapping route that is included in an
earlier route contained in the Adj-RIB-In, the BGP speaker shall run its 
Decision Process since the more specific route has implicitly made a 
portion of the less specific route unavailable for use ."

A) "If the new route is an overlapping route that is included" :
   Does this mean the new route is a more specific route?

B)   Let us consider a set of routes described by
   less specific route 172.16.*.* is in the Adj-RIB-In.
   And a more specific route 172.16.1.* is incoming.
   How does this more specific route render 172.16.(0-255 except 1).*
   unavailable for use?
   (As they are still reachable by the less specific route
    172.16.*.*)

The next item says :
iii) "If the new route has identical path attributes to an earlier route 
........"
   
    Is (iii) a special extension of ii) where PATH attributes are
    identical?


Another unrelated question :

   If a prefix 'p' is learnt from a BGP peer, is there anything that
   precludes us from advertizing it back to the peer?
   (sort of split horizon in distance vector protocols?)

Thanks
-J


  

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id UAA21738 for <[e-mail]>; Thu, 16 Jul 1998 20:53:33 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA12365 for idr-outgoing; Thu, 16 Jul 1998 20:49:21 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA12361 for <[e-mail]>; Thu, 16 Jul 1998 20:49:16 -0400 (EDT)
Received: from www.cs.tsinghua.edu.cn ([166.111.68.3]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id UAA08932 for <[e-mail]>; Thu, 16 Jul 1998 20:49:09 -0400 (EDT)
Received: from www ([127.0.0.1]) by www.cs.tsinghua.edu.cn (Netscape Mail Server v2.02) with SMTP id AAA3000; Fri, 17 Jul 1998 08:46:23 +0900
Message-ID: <[e-mail]>
Date: Fri, 17 Jul 1998 08:46:23 +0900
From: Xiaobo Fan <[e-mail]>
Organization: Tsinghua University
X-Mailer: Mozilla 3.04Gold (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Safaa Hasan <[e-mail]>
CC: [e-mail]
Subject: Re: RFC 1771 clerification
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I have the same interpretation, with which I implemented my own BGP-4
software, which can interoperate with cisco's successfully.

Safaa Hasan wrote:
> 
> Refering to RFC 1771 secion-8 BGP Finite State machine.
> I could not understand the
> paragraph under active state (In this state BGp is TRYING TO AQUIRE a peer by
> INTIATING a transport protocol connection ).Is that paragraph  refering to
> connect state!!.My understanding is that active state is where the peer should keep
> listening after connect state's tcp-connection-request been timed out.It should
> stay in active state for another connect retry time before going into connect state
>  and send another tcp request.
> Any one who can clerify this?
> Safaa Hasan
> Nortel/PASSPORT ILS group

-- 

 ********************************************************
 *                                                      *
 * Xiaobo Fan      : M.S. of Dept. of Computer Science  *
 *                   Tsinghua Univ. , Beijing, 100084   *
 *                   China                              *
 * Address         : Building 14, Room 542              *
 * Tel             : (8610)62785822(O)                  *
 * Email           : [e-mail]         *
 * URL             : http://dream.cs.tsinghua.edu.cn    *
 *                                                      *
 ********************************************************


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id SAA20621 for <[e-mail]>; Thu, 16 Jul 1998 18:48:44 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA11024 for idr-outgoing; Thu, 16 Jul 1998 18:43:25 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA11020 for <[e-mail]>; Thu, 16 Jul 1998 18:43:21 -0400 (EDT)
Received: from smtpott1.nortel.ca (smtpott1.nortel.ca [192.58.194.78]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id SAA04365 for <[e-mail]>; Thu, 16 Jul 1998 18:43:20 -0400 (EDT)
Message-Id: <[e-mail]>
Received: from zcars00t by smtpott1; Thu, 16 Jul 1998 18:42:55 -0400
Received: from ca.nortel.com by zcars00t.ca.nortel.com  id <[e-mail]>; Thu, 16 Jul 1998 05:22:31 -0400
Date: 16 Jul 1998 05:22 EDT
To: [e-mail]
From: "Safaa Hasan" <[e-mail]>
Subject: RFC 1771 clerification
Sender: [e-mail]
Precedence: bulk

Refering to RFC 1771 secion-8 BGP Finite State machine.
I could not understand the 
paragraph under active state (In this state BGp is TRYING TO AQUIRE a peer by
INTIATING a transport protocol connection ).Is that paragraph  refering to 
connect state!!.My understanding is that active state is where the peer should keep 
listening after connect state's tcp-connection-request been timed out.It should 
stay in active state for another connect retry time before going into connect state
 and send another tcp request.
Any one who can clerify this?
Safaa Hasan
Nortel/PASSPORT ILS group


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id JAA00012 for <[e-mail]>; Wed, 15 Jul 1998 09:07:04 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA08904 for idr-outgoing; Wed, 15 Jul 1998 08:58:44 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA08897 for <[e-mail]>; Wed, 15 Jul 1998 08:58:37 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA13259; Wed, 15 Jul 1998 08:58:03 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: [e-mail]
From: The IESG <[e-mail]>
SUBJECT: Last Call: BGP Route Flap Damping to Proposed Standard
Reply-to: [e-mail]
Date: Wed, 15 Jul 1998 08:58:03 -0400
Sender: [e-mail]
Precedence: bulk

The IESG has received a request from the Inter-Domain Routing Working
Group to consider BGP Route Flap Damping
<draft-ietf-idr-route-damp-03.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by July 29, 1998.

Files can be obtained via
ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-route-damp-03.txt



Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id KAA16116 for <[e-mail]>; Tue, 14 Jul 1998 10:29:33 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA17739 for idr-outgoing; Tue, 14 Jul 1998 10:23:04 -0400 (EDT)
Received: from mail.aap.ans.net (mail.aap.ans.net [147.225.37.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA17732 for <[e-mail]>; Tue, 14 Jul 1998 10:22:59 -0400 (EDT)
Received: from 205.134.236.31 (ppp-asx205--031.sirius.net [205.134.236.31] (may be forged)) by mail.aap.ans.net (8.8.7/8.8.7) with SMTP id KAA01938 for <[e-mail]>; Tue, 14 Jul 1998 10:22:55 -0400 (EDT)
Date: Tue, 14 Jul 1998 10:22:55 -0400 (EDT)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], &@ans.net, [e-mail]
Subject:  To Your Success -91394
X-Reply-To:  success600.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

This is a FREE offer if you wish to be removed from future mailings, please e-mail 
to… ([e-mail]) and this software will automatically block you 
from their future mailings.

Attention Network Marketers and Opportunity  Seekers
Please read completely
$10 can = $2000 per month, week, or even a day

 Success by Design Presents...

The next major Wave...Get The Facts

Email  to….   [e-mail]
Put name, phone, fax, E-mail

This is the Hottest Opportunity to hit the MLM industry in over 50 years.
Get in Before The Masses!!! Or Before Your Downline Does!!!

Only 1 time $10  Could make you more money than you Dreamed of!!!
For $10 one time, you could build up to $26,000 per DAY With our power matrix 
Plan!!!

Easy program to promote..... You don't have to sell anyone on the product! 
Everyone knows the product.  one of the HOTTEST Products in the industry!!

Our 2x7 matrix pays weekly on  every level. You don't have to fill a matrix to get paid. 
Plus a Unilevel that pays 7 levels. The way this is set up the matrix will build your 
Power Unilevel and produce massive residual income in record time.

 Now is your chance to get in on the ground floor, of what is to be the next major 
wave in  MLM. 

Have fun! This is easy, simple, no-brainer, uncomplicated program!!!

Get The Facts
You can telesponsor in right over the phone 24 hrs per day, 7 days a week 
When you sponsor in, you fall in on the next available position in the downline and 
every one who comes in after you will fall in your downline. There are NO orphans

Get started NOW!!

For more information E-mail to……[e-mail]

Please put 
Name 
Phone
Fax
E-mail

Thank You For Responding 

PS I made $8,000 my 1st week in the business.  I joined all 3 matrixes at the same 
time.
One more thing the company puts a spot in for everyone you sponsor.
 




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id TAA08583 for <[e-mail]>; Mon, 13 Jul 1998 19:49:05 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA07634 for idr-outgoing; Mon, 13 Jul 1998 19:45:43 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA07630 for <[e-mail]>; Mon, 13 Jul 1998 19:45:36 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id QAA12137; Mon, 13 Jul 1998 16:45:03 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id QAA09838; Mon, 13 Jul 1998 16:43:50 -0700 (PDT)
To: [e-mail] (Wayne Mesard)
cc: [e-mail]
Subject: Re: BGP alternate routes
References: [e-mail] (Wayne Mesard) <[e-mail]>
From: Tony Li <[e-mail]>
Date: 13 Jul 1998 16:43:50 -0700
In-Reply-To: [e-mail]'s message of 13 Jul 98 19:06:35 GMT
Message-ID: <[e-mail]>
Lines: 34
X-Mailer: Gnus v5.3/Emacs 19.34
Sender: [e-mail]
Precedence: bulk

[e-mail] (Wayne Mesard) writes:

> 
> [e-mail] (Tony Li) writes:
> > >      The question is : IS IT MANDATORY THEN TO STORE ALL ALTERNATE
> > >      ROUTES TO A DESTINATION?
> 
> > The protocol specification
> > says NOTHING about what you have to store.  If you decided to not store the
> > route, that's fine.  It would be exactly as if you rejected the route for
> > administrative purposes.
> 
> Really?  RFC-1771, sec 9, par 5 sez:
> 
>    If the UPDATE message contains a feasible route, it shall be placed
>    in the appropriate Adj-RIB-In...                    ^^^^^
>                                                        |||||
> 
> And sec 3.2, par 5 sez:
> 
>    In summary, the Adj-RIBs-In contain unprocessed routing information
>                                        ^^^^^^^^^^^
>    that has been advertised to the local BGP speaker by its peers;


You might recall that an IETF specification cannot (and in this case does
not) specify the internal behavior.  It specifies a functional behavior.

Certainly there are conformant implementations out there (e.g., Cisco) that
will not place a feasible route in an Adj-RIB-In.  In fact, Cisco's
implementation doesn't even have the abstraction of an Adj-RIB-In.

Tony


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id PAA05556 for <[e-mail]>; Mon, 13 Jul 1998 15:15:15 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA02814 for idr-outgoing; Mon, 13 Jul 1998 15:09:14 -0400 (EDT)
Received: from tofu.ibnets.com (tofu.ironbridgenetworks.com [146.115.140.72]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA02807 for <[e-mail]>; Mon, 13 Jul 1998 15:09:05 -0400 (EDT)
Received: (from wmesard@localhost) by tofu.ibnets.com (8.8.7/8.8.7) id PAA14018; Mon, 13 Jul 1998 15:06:35 -0400
Date: Mon, 13 Jul 1998 15:06:35 -0400
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Wayne Mesard <[e-mail]>
To: [e-mail]
Subject: Re: BGP alternate routes
Newsgroups: lists.ietf.idr
In-Reply-To: Tony Li's message of 12 July 1998 04:46:08
References: <[e-mail]>
X-Mailer: VM 6.38 under Emacs 20.2.1
Sender: [e-mail]
Precedence: bulk

[e-mail] (Tony Li) writes:
> >      The question is : IS IT MANDATORY THEN TO STORE ALL ALTERNATE
> >      ROUTES TO A DESTINATION?

> The protocol specification
> says NOTHING about what you have to store.  If you decided to not store the
> route, that's fine.  It would be exactly as if you rejected the route for
> administrative purposes.

Really?  RFC-1771, sec 9, par 5 sez:

   If the UPDATE message contains a feasible route, it shall be placed
   in the appropriate Adj-RIB-In...                    ^^^^^
                                                       |||||

And sec 3.2, par 5 sez:

   In summary, the Adj-RIBs-In contain unprocessed routing information
                                       ^^^^^^^^^^^
   that has been advertised to the local BGP speaker by its peers;

Wayne();


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id PAA22416 for <[e-mail]>; Sun, 12 Jul 1998 15:44:11 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA12428 for idr-outgoing; Sun, 12 Jul 1998 15:37:45 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA12422 for <[e-mail]>; Sun, 12 Jul 1998 15:37:39 -0400 (EDT)
Received: from skycorp.skynet.be (skycorp.skynet.be [195.238.0.128]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id PAA18424 for <[e-mail]>; Sun, 12 Jul 1998 15:37:38 -0400 (EDT)
Received: from login.skynet.be (dialup32.wavre.skynet.be [195.238.10.32]) by skycorp.skynet.be (8.8.8/jovi-relay-1.1-vw) with ESMTP id VAA11303; Sun, 12 Jul 1998 21:36:47 +0200 (MET DST)
Message-Id: <[e-mail]>
From: "benoit tilmant" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Add idr-request, Add iwg [e-mail]
Date: Sun, 12 Jul 1998 21:40:21 +0200
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Add idr-request, Add iwg [e-mail]


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id DAA17182 for <[e-mail]>; Sun, 12 Jul 1998 03:44:30 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id DAA08350 for idr-outgoing; Sun, 12 Jul 1998 03:40:41 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id DAA08343 for <[e-mail]>; Sun, 12 Jul 1998 03:40:36 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id DAA28096 for <[e-mail]>; Sun, 12 Jul 1998 03:40:35 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id AAA02861; Sun, 12 Jul 1998 00:40:04 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id AAA05977; Sun, 12 Jul 1998 00:38:53 -0700 (PDT)
To: [e-mail] (jaihari loganathan)
cc: [e-mail]
Subject: Re: BGP alternate routes
References: <[e-mail]>
From: Tony Li <[e-mail]>
Date: 12 Jul 1998 00:38:53 -0700
In-Reply-To: [e-mail]'s message of 11 Jul 98 21:39:41 GMT
Message-ID: <[e-mail]>
Lines: 30
X-Mailer: Gnus v5.3/Emacs 19.34
Sender: [e-mail]
Precedence: bulk

>      Suppose there is a destination prefix 'p'
>      And 'p' is heard from multiple BGP peers peer-A, peer-B.
>      And peer-B's route loses against peer-A's route.
>       peer-B's route is chosen to be advertised to other BGP peers.
>      AT THIS POINT , does the implementation need to store both
>      the routes?


Need to?  Yes.  Suppose that peer-A's route is withdrawn....  you'd be left
without any route, when there's a valid alternative.


>      Suppose that  peer-B's route to 'p' is WITHDRAWN,
>      
>      1) if we did not store peer-A's route, we will have no means
>        to regain it since BGP is not a periodic refresh protocol.
>        (And if the route to 'p' does not change, peer-A is not going
>        to readvertise it to us)
> 
>      The question is : IS IT MANDATORY THEN TO STORE ALL ALTERNATE
>      ROUTES TO A DESTINATION?


Note that this is now a different question.  The protocol specification
says NOTHING about what you have to store.  If you decided to not store the
route, that's fine.  It would be exactly as if you rejected the route for
administrative purposes.

Tony


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id DAA17183 for <[e-mail]>; Sun, 12 Jul 1998 03:44:30 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id DAA08357 for idr-outgoing; Sun, 12 Jul 1998 03:42:01 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id DAA08353 for <[e-mail]>; Sun, 12 Jul 1998 03:41:57 -0400 (EDT)
Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id DAA28126 for <[e-mail]>; Sun, 12 Jul 1998 03:41:56 -0400 (EDT)
Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id AAA02883; Sun, 12 Jul 1998 00:41:25 -0700 (PDT)
Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id AAA05984; Sun, 12 Jul 1998 00:40:15 -0700 (PDT)
To: [e-mail] (jaihari loganathan)
cc: [e-mail]
Subject: Re: section 9.2.4.2 RFC1771
References: <[e-mail]>
From: Tony Li <[e-mail]>
Date: 12 Jul 1998 00:40:15 -0700
In-Reply-To: [e-mail]'s message of 12 Jul 98 00:09:11 GMT
Message-ID: <[e-mail]>
Lines: 16
X-Mailer: Gnus v5.3/Emacs 19.34
Sender: [e-mail]
Precedence: bulk

[e-mail] (jaihari loganathan) writes:

>      RFC 1771 section 9.2.4.2 Aggregating routing information states :
>      "Routes that have the following attributes shall not be aggregated 
> unless the corresponding attributes of each route are identical : 
> MUTLTI_EXIT_DISC, NEXT_HOP"
> 
>       I understand NEXT_HOP is a well known mandatory attribute which 
> cannot be missing in any routing update. So how can there be a route 
> without a NEXT_HOP attribute?

The text is overly general, without being incorrect.  ;-)

It was written this way since MED is optional.

Tony


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id VAA14221 for <[e-mail]>; Sat, 11 Jul 1998 21:07:55 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA05070 for idr-outgoing; Sat, 11 Jul 1998 21:05:47 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA05066 for <[e-mail]>; Sat, 11 Jul 1998 21:05:43 -0400 (EDT)
From: [e-mail]
Received: from 208.141.116.73 ([208.141.116.73]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id VAA16078; Sat, 11 Jul 1998 21:05:32 -0400 (EDT)
Date: Sat, 11 Jul 1998 21:05:32 -0400 (EDT)
Message-Id: <[e-mail]>
Subject:  That girl
X-Reply-To:  [e-mail]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

ADD SIZZLE TO YOUR SEX LIFE!!!           
AMAZING FRAGARANCE COULD TRIGGER SEXUAL DESIRE IN WOMEN!

SCENTUAL, a patented pheremone fragrance, boosts your sex appeal 
making you irresistible to women scientifically by using pheremones.

What are pheremones?  Pheremones are naturally occurring chemicals 
released by organisms into the environment, where they serve as 
signals or messengers to the opposite sex to stimulate courtship
and mating.  The question is, are humans affected by pheremones?  

ABSOLUTELY!

SCENTUAL can help you find YOUR perfect woman by making you
irresistable!

Introductory price $ 29.95 per bottle

30 DAY MONEY BACK GUARANTE: If for any reason you are not 
100% completely satisfied, just return the unused portion 
within the first 30 days after purchase, to receive a full 
refund!
            
Call now for immediate delivery!
Operators are standing by 24 hours a day, 7 days a week.

TO ORDER CALL:    1-800-794-2988
we accept Visa, Mastercard, and American Express
        
Or send your check or money-order to :
SALES GRAPHIC INC.
1280 Bison # B-9 ste 606
Newport Beach, CA 92660

                                             
DON'T BE LEFT BEHIND!

--------------------------------------------------------------------
The Mailing List that you are being mailed from was filtered against
the Global Remove List at: http://remove-list.com

Remove-List is a free public service offering to help the general public
get removed from bulk mailings lists and has not sent this message. If 
you want their help please add your name to their list and we you will 
not receive a bulk email from us or any other ethical bulk emailer.
-----------------------------------------------------------------------

Message Delivery Provided by:
SuccessMarketing
PO Box 302
Chatham, IL 62629
[phone]




Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id UAA13989 for <[e-mail]>; Sat, 11 Jul 1998 20:12:15 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA04603 for idr-outgoing; Sat, 11 Jul 1998 20:09:47 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA04599 for <[e-mail]>; Sat, 11 Jul 1998 20:09:43 -0400 (EDT)
Received: from hotmail.com (f139.hotmail.com [207.82.251.18]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id UAA14630 for <[e-mail]>; Sat, 11 Jul 1998 20:09:42 -0400 (EDT)
Received: (qmail 2744 invoked by uid 0); 12 Jul 1998 00:09:11 -0000
Message-ID: <[e-mail]>
Received: from 208.227.187.166 by www.hotmail.com with HTTP; Sat, 11 Jul 1998 17:09:11 PDT
X-Originating-IP: [208.227.187.166]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Subject: section 9.2.4.2 RFC1771 
Content-Type: text/plain
Date: Sat, 11 Jul 1998 17:09:11 PDT
Sender: [e-mail]
Precedence: bulk

Folks,
     RFC 1771 section 9.2.4.2 Aggregating routing information states :
     "Routes that have the following attributes shall not be aggregated 
unless the corresponding attributes of each route are identical : 
MUTLTI_EXIT_DISC, NEXT_HOP"

      I understand NEXT_HOP is a well known mandatory attribute which 
cannot be missing in any routing update. So how can there be a route 
without a NEXT_HOP attribute?
-JL

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id RAA12787 for <[e-mail]>; Sat, 11 Jul 1998 17:44:34 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA03460 for idr-outgoing; Sat, 11 Jul 1998 17:40:20 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA03456 for <[e-mail]>; Sat, 11 Jul 1998 17:40:14 -0400 (EDT)
Received: from hotmail.com (f229.hotmail.com [207.82.251.120]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id RAA11258 for <[e-mail]>; Sat, 11 Jul 1998 17:40:13 -0400 (EDT)
Received: (qmail 19378 invoked by uid 0); 11 Jul 1998 21:39:41 -0000
Message-ID: <[e-mail]>
Received: from 208.227.187.166 by www.hotmail.com with HTTP; Sat, 11 Jul 1998 14:39:41 PDT
X-Originating-IP: [208.227.187.166]
From: "jaihari loganathan" <[e-mail]>
To: [e-mail]
Subject: BGP alternate routes
Content-Type: text/plain
Date: Sat, 11 Jul 1998 14:39:41 PDT
Sender: [e-mail]
Precedence: bulk

Folks,
     Could you explain how BGP implementation should handle multiple
     alternative routes to a destination.
     Suppose there is a destination prefix 'p'
     And 'p' is heard from multiple BGP peers peer-A, peer-B.
     And peer-B's route loses against peer-A's route.
      peer-B's route is chosen to be advertised to other BGP peers.
     AT THIS POINT , does the implementation need to store both
     the routes?
       

     Suppose that  peer-B's route to 'p' is WITHDRAWN,
     
     1) if we did not store peer-A's route, we will have no means
       to regain it since BGP is not a periodic refresh protocol.
       (And if the route to 'p' does not change, peer-A is not going
       to readvertise it to us)

     The question is : IS IT MANDATORY THEN TO STORE ALL ALTERNATE
     ROUTES TO A DESTINATION?

Thanks,
-JL

     

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id RAA04215 for <[e-mail]>; Fri, 10 Jul 1998 17:13:07 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA20463 for idr-outgoing; Fri, 10 Jul 1998 17:08:16 -0400 (EDT)
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA20444 for <[e-mail]>; Fri, 10 Jul 1998 17:08:06 -0400 (EDT)
Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id OAA22753; Fri, 10 Jul 1998 14:07:34 -0700
Message-Id: <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: draft-ietf-idr-route-damp-03.txt to PS
Date: Fri, 10 Jul 98 14:07:33 PDT
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Rob,

The IDR WG would like to ask the IESG to advance
draft-ietf-idr-route-damp-03.txt to a Proposed Standard.

Yakov.


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id NAA29351 for <[e-mail]>; Mon, 6 Jul 1998 13:29:35 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA19907 for idr-outgoing; Mon, 6 Jul 1998 13:24:34 -0400 (EDT)
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA19902 for <[e-mail]>; Mon, 6 Jul 1998 13:24:30 -0400 (EDT)
Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id KAA05086 for [e-mail]; Mon, 6 Jul 1998 10:23:56 -0700
Message-Id: <[e-mail]>
To: [e-mail]
Subject: IDR WG meeting schedule
Date: Mon, 06 Jul 98 10:23:55 PDT
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

Here are the dates for the WG meeting:

	Wednesday, August 26 at 0900-1130
		other groups scheduled at that time: ipfc, OPS Area Meeting,
			smime, diffserv
	Thursday, August 27 at 1300-1500
		other groups scheduled at that time: hubmib, saag, rtfm

Please send me and Sue proposals for the agenda items.

Yakov.


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id MAA27627 for <[e-mail]>; Fri, 3 Jul 1998 12:26:20 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA17463 for idr-outgoing; Fri, 3 Jul 1998 12:21:32 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA17458 for <[e-mail]>; Fri, 3 Jul 1998 12:21:27 -0400 (EDT)
From: [e-mail]
Received: from www.telecommex.com ([207.48.68.252]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id MAA17744 for <[e-mail]>; Fri, 3 Jul 1998 12:21:22 -0400 (EDT)
Received: from tara by www.telecommex.com via SMTP (951211.SGI.8.6.12.PATCH1502/940406.SGI) id BAA02434; Fri, 3 Jul 1998 01:24:49 -0500
Date: Fri, 3 Jul 1998 01:24:49 -0500
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Are you an Internet Marketer?
Sender: [e-mail]
Precedence: bulk

Dear Internet Marketer,

Are you tired of endlessly posting your ad to online classified sites that
just don't get the job done? The fact is there are over 300 such sites
scattered about the Web and frankly none of them generate enough traffic
to be worth your while. Even when someone does visit one of these sites,
your ad is hopelessly lost in a myriad of similar offerings.

The true professionals of online marketing have known for some time that
nothing creates results the way a direct bulk email campaign does. We have
assembled a complete package on one CD-ROM that will enable to get your
message out to millions for surprisingly little cost and effort.

INTRODUCING...MILLIONS VOL. 1

We took a total of over 92 million email addresses from many of the 
touted CD's that are out there (bought them all - some were $300+)!  We
added the millions we had in storage to those.   When we combined them
all, we had in  excess of 100+ million addresses in one huge file. 

We then ran a super "sort/de-dupe" program against this huge list. 
It cut the file down to less than 25 million!!! Can you believe that? It
seems that most people that are selling CD's are duping the public by
putting numerous files of addresses in the CD over and over. This created
many duplicate addresses. They also had many program
 "generated" email addresses like Compuserve, MCI, ANON's, etc. 
This causes a tremendous amount of undeliverables, and for  those 
that use Stealth programs, clogs up servers quickly with trash, etc. 

We then ran a program that contained 150+ keywords to remove 
addresses with vulgarity,  profanity, sex-related names, postmaster,
 webmaster, flamer, abuse, spam, etc., etc.   Also eliminated all .edu,
.mil, .org, .gov, etc.   After that list was run against the remaining
list, it  reduced it down to near 16 million addresses! 

So, you see, our list will save people hundreds of dollars buying all
others that are out there on  CD and otherwise. Using ours will be like
using the 100+ million that we started with, but a lot less money and a
lot less time!!  

Besides the 16 Million general email address we include over 400,000
TARGETED addresses of Business Opportunity Seekers, MLM'ers and
other Internet Marketers. These are people EAGER to hear about your
products and services. 
Other services charge upwards of 5 cents per address for this type of
list. We include it at no extra extra charge when you purchase Millions
Vol. 1

We also included a 5+ million "Remove/Flamer" file broken into seperate
files for ease of  extracting and adding to your own database of removes. 

To help you manage your email lists, you'll find a fully functional
evaluation copy of BulkMate 4.05 on your CD. BulkMate is an indispensible
tool for the serious bulk mailer. Among its 10 utilites are the ability to
filter any address list against a remove list, sort any list
alphabetically and automatically remove dupes, remove specific domains
from any list and count the number of addresses in each list.


 "You can buy from the REST or you can buy from the BEST.   Your choice.
_____________________________

What our clients are saying:

"I received the CD on Friday evening.   Like a kid with a new toy, I
immediately started bulking out using the new email addresses.  Over the
course of the weekend, I emailed out over 500,000 emails and I received
less than TWENTY undeliverables!!  I am totally satisfied with my
purchase!!  Thanks Syrynx!!"

Dave Buckley
Houston,  TX


"This list is worth it's weight in gold!!  I sent out 10,000 emails for my
product and received 185 orders!  

Ann Colby
New Orleans, LA


"I am absolutely delighted! Your support is first rate. When I needed help
you were there for me. I got a real person on the phone. I've been
marketing my product now for two weeks and can't believe how many orders
I've received. I can't thank you enough!

Gail Swanton
Boston, MA


****************************************

                  HERE'S THE BOTTOM LINE

Here is what you get when you order today!

>> 16 Million Email Addresses... 1 per line in simple text format on a CD.
Files are in lots of 100,000 (no codes needed to open files). 
All files are separated by domain name for your convenience.

PLUS you receive a tremendous REMOVE list!

AND

Over 400,000 Targeted email addresses.

AND

The sampling of CyberPromo's HOT list.

AND

BulkMate 4.05 The ultimate mail management tool.

>>> NOW ONLY $149.00!   

All lists are completely free of any Duplicates. We also on a continual
basis, add New Names and Remove Undeliverables and Remove Requests.   

The result is the Cleanest Email Addresses Available Anywhere 
to use over and over again, for a FRACTION of the cost that other 
companies charge. Typical rates for acquiring email lists are from 
1 cent to as high as 3 cents per email address - that's
"INFORMATION HIGHWAY" ROBBERY!.

Don't even hesitate on this one or you will miss out on the most 
effective way to market anywhere..PERIOD!

>>>As a special bonus we've included the entire suite of Earthonline
>>>bulk email and marketing software demos on the CD. Including
>>>the just released DirectMail 2.3 mailer. Use it free for 10 days !!
>>>You'll also get our  private Website address where you can check
>>> for product upgrades and other valuable marketing information.


To order our email package, simply print out the EZ ORDER FORM 
below and fax or mail it to our office today.

We accept Checks by Fax and Mail and C.O.D.

_________________
EZ Order Form 


_____Yes! I would like to order MILLIONS Vol. 1 email addresses 
for only $149.00.

All orders are sent by US Priority Mail and we pay the shipping costs!

ORDERING OPTIONS

*Mail (USPS)
   *Include a check or money order for the correct amount.
   *Make the check payable to:  Syrynx, Inc.
   *Include your phone number and/or email address in case we need to
   contact you. *Mail to:

       Syrynx, Inc.
       500 Lake Avenue
       Suite 154 
       Lake Worth, Florida  33460

*C.O.D.
   *Fill out the order form completely and write/type COD on the form.
   *Mail the form to the above address or fax to 305-418-7590 *Please have
   a certified/cashiers check or money order in the amount
    of $165.00 payable to Syrynx, Inc ready when the order arrives.
    The additonal $16.00 covers overnight shipping and C.O.D. fees.

*Fax
   *This is the preferred payment method at Syrynx, Inc.
   *ALL FUNDS ARE TO BE IN USA CURRENCY.
   *Your order can be received 24 hours a day, 7 days a week.
   *Print out and complete the following form.
   *To this form, attach a BLANK CHECK with "VOID" written
    somewhere on the body of the check.
   *This gives us the necessary account information to process your order.
   *Please note that Syrynx, Inc. charges a $40.00 fee for ALL BAD CHECKS.
   



Thank you for your order.

Syrynx, Inc.


          **********  MILLIONS VOL.1 ORDER FORM **********

*You must complete the entire form or your order can not be processed.
*You will need to tape the blank check in the space indicated below. *Fill
out and sign the authorization section below.

*Fax the ENTIRE FORM to [phone].


*Please, print the following information.


First Name: _______________________________________________________

Last Name: _______________________________________________________

Street Address: ___________________________________________________

_________________________________________________________________

City: ____________________________________________________________

State: _____________________            Zip: _________________________

Phone Number:  __________________________________________________

EMail Address: ___________________________________________________



           * * * * * * * * * *  Authorization  * * * * * * * * * *
                        (leave blank for C.O.D. orders) 

I, ________________________________________________, hereby authorize
Syrynx, Inc. to withdraw $________________________ from my checking
account, account information enclosed, one time only, for the purchase of
the Millions Vol. 1 CD-ROM. I have read and I understand the terms and
conditions as stated above.  The signature below is the authorized
signature of the holder of the checking account.  I understand that
Syrynx, Inc. charges $40.00 for bad checks.  I understand that if the
funds are not available in my account, I agree to pay the amount of this
order plus the $40.00 fee. (Cash or Certified Funds Only).  Authorized
Signature _______________________________________________

Date: __________________ 

order code:mvi

*Attach voided, blank check below. (do not attach check for C.O.D. orders)













Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id AAA23020 for <[e-mail]>; Fri, 3 Jul 1998 00:23:23 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA11811 for idr-outgoing; Fri, 3 Jul 1998 00:19:45 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA11807 for <[e-mail]>; Fri, 3 Jul 1998 00:19:40 -0400 (EDT)
Received: from roam.psg.com ([e-mail] [147.28.2.2]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id AAA25680 for <[e-mail]>; Fri, 3 Jul 1998 00:19:39 -0400 (EDT)
Received: by roam.psg.com  id m0yrr43-00000IC; Thu, 2 Jul 1998 14:38:47 -0700 (PDT) (Smail3.2.0.96#1)
Message-Id: <[e-mail]>
Date: Thu, 2 Jul 1998 14:38:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Randy Bush <[e-mail]>
To: Marcelo Manta <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: bgp
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I have the exact same question. Is there other providers, besides MCI,
> that changes their local preferences based on received communities ?

randy


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id NAA18212 for <[e-mail]>; Thu, 2 Jul 1998 13:39:57 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA03724 for idr-outgoing; Thu, 2 Jul 1998 13:39:23 -0400 (EDT)
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA03720 for <[e-mail]>; Thu, 2 Jul 1998 13:39:18 -0400 (EDT)
Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id KAA03597; Thu, 2 Jul 1998 10:38:40 -0700
Message-Id: <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: draft-ietf-idr-bgp-tcp-md5-01.txt to PS
Date: Thu, 02 Jul 98 10:38:40 PDT
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Rob,

The IDR WG would like to ask the IESG to advance 
draft-ietf-idr-bgp-tcp-md5-01.txt to a Proposed Standard.

Yakov.


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id NAA18206 for <[e-mail]>; Thu, 2 Jul 1998 13:39:48 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA03712 for idr-outgoing; Thu, 2 Jul 1998 13:38:51 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA03700 for <[e-mail]>; Thu, 2 Jul 1998 13:38:46 -0400 (EDT)
Received: from smartsmtp.saga.com.br ([200.239.239.73]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id NAA28271 for <[e-mail]>; Thu, 2 Jul 1998 13:38:39 -0400 (EDT)
Received: from 200.231.130.25 by smartsmtp.saga.com.br with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id NTVQFK3P; Thu, 2 Jul 1998 14:36:21 -0300
Message-ID: <[e-mail]>
Date: Thu, 02 Jul 1998 14:37:00 -0200
From: Marcelo Manta <[e-mail]>
Organization: Saga Sistemas e Computadores
X-Mailer: Mozilla 4.03 [en] (Win95; I)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: bgp
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I have the exact same question. Is there other providers, besides MCI,
that changes their local preferences based on received communities ?

TIA,

[e-mail] wrote:
> 
> I am trying to identify BGP policies for various ISPs.  Can you direct me??
> 
> thanks
> 
> dg

-- 
Marcelo Manta
SAGA
PGP fingerprint = E3 B8 AC AF 24 61 E7 E5  B8 38 01 D1 3C F4 32 5E


Received: from merit.edu (merit.edu [198.108.1.42]) by nic.merit.edu (8.8.7/8.8.7) with ESMTP id KAA16842 for <[e-mail]>; Thu, 2 Jul 1998 10:52:17 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA00311 for idr-outgoing; Thu, 2 Jul 1998 10:42:41 -0400 (EDT)
Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA00307 for <[e-mail]>; Thu, 2 Jul 1998 10:42:31 -0400 (EDT)
From: [e-mail]
Received: from sprint-canada.com (sctorfw001.sprint-canada.com [207.107.50.21]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id KAA16101 for <[e-mail]>; Thu, 2 Jul 1998 10:42:30 -0400 (EDT)
Received: by sctorfw001.sprint-canada.com id <15256>; Thu, 2 Jul 1998 10:39:15 -0400
Message-Id: <[e-mail]>
X-Mailer: ccMail Link to SMTP R8.11.00.3
Date: Thu, 2 Jul 1998 11:38:01 -0400
To: <[e-mail]>
Subject: bgp
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Description: "cc:Mail Note Part"
Sender: [e-mail]
Precedence: bulk

I am trying to identify BGP policies for various ISPs.  Can you direct me??

thanks

dg