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

From: Sandy Murphy <[email-masked]>
Date: Mon, 27 Jul 1998 13:45:16 -0400 (EDT)

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

---

From: Pedro Marques <[email-masked]>
Date: Mon, 27 Jul 1998 11:32:37 -0700 (PDT)

>>>>> "Sandy" == Sandy Murphy <[email-masked]> 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.

---

From: Antoni Przygienda <[email-masked]>
Date: Mon, 27 Jul 1998 15:22:36 -0400

> 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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 28 Jul 1998 11:42:12 -0400

> try to pay particular attention to security related standards.

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

---

From: "Luis A. Sanchez" <[email-masked]>
Date: Tue, 28 Jul 1998 16:14:50 +0000 (GMT)

> to be plugged other than weakness in MD5?).

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

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 29 Jul 1998 10:05:05 -0400

> terms will be appropriate in this context.

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

> 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.

> section 4.5 needs some more explanation and clarification.

OK.

> choose to use it will be able to assess the level of security provided

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.

From: [email-masked]
Date: Fri, 31 Jul 1998 21:39:18 -0500
To: [email-masked]
Sender: [email-masked]

Very Respected [email-masked]

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
[email-masked]

From: "jaihari loganathan" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RFC 1771 9.1.2 Route selection
Date: Thu, 30 Jul 1998 21:51:08 PDT
Sender: [email-masked]

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 [email-masked] 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 <[email-masked]>
>Subject: Re: RFC 1771 9.1.2 Route selection
>To: jaihari loganathan <[email-masked]>
>cc: [email-masked]
>In-Reply-To: <[email-masked]>
>Message-ID: <[email-masked]>
>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

Date: Fri, 31 Jul 1998 09:38:37 -0530 (IST)
From: Ajay Agrawal <[email-masked]>
Subject: Re: RFC 1771 9.1.2 Route selection
To: jaihari loganathan <[email-masked]>
cc: [email-masked]
Sender: [email-masked]

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 

From: [email-masked]
To: <[email-masked]>
Subject: battery of the future...
Date: Thu, 30 Jul 1998 09:35:31
Sender: [email-masked]

 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.

 

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: RFC 1771 9.1.2 Route selection
Date: Thu, 30 Jul 1998 04:55:47 PDT
Sender: [email-masked]

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

Date: Wed, 29 Jul 1998 19:58:19 -0400
From: Rajesh Saluja <[email-masked]>
Organization: @Home Network
To: jaihari loganathan <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: RFC 1771 Section 9.1 clarification
Sender: [email-masked]

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
[email-masked]

From: "jaihari loganathan" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: RFC 1771 Section 9.1 clarification
Date: Wed, 29 Jul 1998 16:25:01 PDT
Sender: [email-masked]

>> 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

Date: Wed, 29 Jul 1998 10:52:09 -0400
From: Rajesh Saluja <[email-masked]>
Reply-To: [email-masked]
Organization: Ficon Technology, Inc.
To: jaihari loganathan <[email-masked]>
CC: [email-masked]
Subject: Re: RFC 1771 Section 9.1 clarification
Sender: [email-masked]

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:  (732) 283-2770 ext 322
1000 Route 9 North               Fax  :  (732) 283-2848
Woodbridge, NJ 07095             mailto:[email-masked]
---------------------------------------------------------------------

To: "Luis A. Sanchez" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard??? 
Date: Wed, 29 Jul 1998 10:05:05 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

> terms will be appropriate in this context.

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

> 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.

> section 4.5 needs some more explanation and clarification.

OK.

> choose to use it will be able to assess the level of security provided

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.

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: RFC 1771 Section 9.1 clarification
Date: Wed, 29 Jul 1998 02:51:35 PDT
Sender: [email-masked]

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

From: "Luis A. Sanchez" <[email-masked]>
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
To: [email-masked] (Sandy Murphy)
Date: Tue, 28 Jul 1998 20:13:31 +0000 (GMT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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.             

To: [email-masked] (Sandy Murphy)
cc: [email-masked]
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
From: Tony Li <[email-masked]>
Date: 28 Jul 1998 16:31:02 -0700
Lines: 12
Sender: [email-masked]

[email-masked] (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

Date: Tue, 28 Jul 1998 17:55:40 -0400 (EDT)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

From: "Luis A. Sanchez" <[email-masked]>
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
To: [email-masked]
Date: Tue, 28 Jul 1998 16:14:50 +0000 (GMT)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Curtis,

Now, the hard ones:

Luis

To: Sandy Murphy <[email-masked]>
cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard??? 
Date: Tue, 28 Jul 1998 11:42:12 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

Curtis

Date: Mon, 27 Jul 1998 15:31:51 -0400 (EDT)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
Cc: [email-masked]
Sender: [email-masked]

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

Date: Mon, 27 Jul 1998 15:22:36 -0400
From: Antoni Przygienda <[email-masked]>
Organization: Bell Labs, Lucent
To: Sandy Murphy <[email-masked]>
CC: [email-masked]
Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard???
Sender: [email-masked]

> try to pay particular attention to security related standards.

Date: Mon, 27 Jul 1998 11:32:37 -0700 (PDT)
From: Pedro Marques <[email-masked]>
To: Sandy Murphy <[email-masked]>
Cc: [email-masked]
Subject: using the TCP MD5 protection for BGP - Proposed Standard???
Sender: [email-masked]

Sandy,

regards,
  Pedro.

Date: Mon, 27 Jul 1998 13:45:16 -0400 (EDT)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: using the TCP MD5 protection for BGP - Proposed Standard???
Cc: [email-masked]
Sender: [email-masked]

--Sandy

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
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: [email-masked]

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.

From: [email-masked]
To: web@marketing
Subject: Comprehensive manual reveals powerful Internet marketing techniques!
Date: 26 Jul 1998 22:29:22 -0700
Sender: [email-masked]

       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"!

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: Implementation question
Date: Sat, 25 Jul 1998 17:32:49 PDT
Sender: [email-masked]

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

To: "jaihari loganathan" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: RFC 1771 dynamic policy configuration 
Date: Thu, 23 Jul 1998 12:43:44 -0400
From: Susan Hares <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 23 Jul 1998 11:22:30 -0400
From: Rajesh Saluja <[email-masked]>
Reply-To: [email-masked]
Organization: Ficon Technology, Inc.
To: [email-masked]
Subject: Corrections required in RFC 1771 Finite state machine
Sender: [email-masked]

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:  (732) 283-2770 ext 322
1000 Route 9 North               Fax  :  (732) 283-2848
Woodbridge, NJ 07095             mailto:[email-masked]
---------------------------------------------------------------------

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: RFC 1771  dynamic policy configuration
Date: Thu, 23 Jul 1998 02:34:45 PDT
Sender: [email-masked]

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

Date: Tue, 21 Jul 1998 19:44:35 -0700 (PDT)
From: "Jason L. Weisberger" <[email-masked]>
To: jaihari loganathan <[email-masked]>
cc: [email-masked]
Subject: Re: BGP policy question
Sender: [email-masked]

>      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

Date: Tue, 21 Jul 1998 21:05:37 -0500
To: "jaihari loganathan" <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: BGP policy question
Cc: [email-masked]
Sender: [email-masked]

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:  [email-masked]
Internet Engineering Group, LLC     phone:  (734) 213-4939 x14
122 S. Main, Suite 280              fax:    (734) 669-8661
Ann Arbor, MI  48104                www:    http://www.ieng.com

Date: Tue, 21 Jul 1998 19:20:23 -0400
To: "jaihari loganathan" <[email-masked]>, [email-masked]
From: [email-masked] (Lee Ingersoll)
Subject: Re: BGP policy question
Sender: [email-masked]

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:[email-masked]

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: BGP policy question
Date: Tue, 21 Jul 1998 15:18:08 PDT
Sender: [email-masked]

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

Date: Mon, 20 Jul 1998 10:13:32 -0400
From: Rajesh Saluja <[email-masked]>
Reply-To: [email-masked]
Organization: Ficon Technology, Inc.
To: jaihari loganathan <[email-masked]>
CC: [email-masked]
Subject: Re: Update message handling RFC1771 section #9
Sender: [email-masked]

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:  (732) 283-2770 ext 322
1000 Route 9 North               Fax  :  (732) 283-2848
Woodbridge, NJ 07095             mailto:[email-masked]
---------------------------------------------------------------------

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: Update message handling RFC1771 section #9
Date: Fri, 17 Jul 1998 23:40:49 PDT
Sender: [email-masked]

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

Date: Fri, 17 Jul 1998 08:46:23 +0900
From: Xiaobo Fan <[email-masked]>
Organization: Tsinghua University
To: Safaa Hasan <[email-masked]>
CC: [email-masked]
Subject: Re: RFC 1771 clerification
Sender: [email-masked]

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           : [email-masked]         *
 * URL             : http://dream.cs.tsinghua.edu.cn    *
 *                                                      *
 ********************************************************

Date: 16 Jul 1998 05:22 EDT
To: [email-masked]
From: "Safaa Hasan" <[email-masked]>
Subject: RFC 1771 clerification
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: The IESG <[email-masked]>
SUBJECT: Last Call: BGP Route Flap Damping to Proposed Standard
Reply-to: [email-masked]
Date: Wed, 15 Jul 1998 08:58:03 -0400
Sender: [email-masked]

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
[email-masked] or [email-masked] mailing lists by July 29, 1998.

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

Date: Tue, 14 Jul 1998 10:22:55 -0400 (EDT)
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject:  To Your Success -91394
Sender: [email-masked]

This is a FREE offer if you wish to be removed from future mailings, please e-mail 
to… ([email-masked]) 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….   [email-masked]
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……[email-masked]

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.

To: [email-masked] (Wayne Mesard)
cc: [email-masked]
Subject: Re: BGP alternate routes
From: Tony Li <[email-masked]>
Date: 13 Jul 1998 16:43:50 -0700
Lines: 34
Sender: [email-masked]

[email-masked] (Wayne Mesard) writes:

> 
> [email-masked] (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

Date: Mon, 13 Jul 1998 15:06:35 -0400
From: Wayne Mesard <[email-masked]>
To: [email-masked]
Subject: Re: BGP alternate routes
Newsgroups: lists.ietf.idr
Sender: [email-masked]

[email-masked] (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();

From: "benoit tilmant" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Add idr-request, Add iwg [email-masked]
Date: Sun, 12 Jul 1998 21:40:21 +0200
Sender: [email-masked]

Add idr-request, Add iwg [email-masked]

To: [email-masked] (jaihari loganathan)
cc: [email-masked]
Subject: Re: BGP alternate routes
From: Tony Li <[email-masked]>
Date: 12 Jul 1998 00:38:53 -0700
Lines: 30
Sender: [email-masked]

>      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

To: [email-masked] (jaihari loganathan)
cc: [email-masked]
Subject: Re: section 9.2.4.2 RFC1771
From: Tony Li <[email-masked]>
Date: 12 Jul 1998 00:40:15 -0700
Lines: 16
Sender: [email-masked]

[email-masked] (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

From: [email-masked]
Date: Sat, 11 Jul 1998 21:05:32 -0400 (EDT)
Subject:  That girl
Sender: [email-masked]

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
(217)483-4015

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: section 9.2.4.2 RFC1771 
Date: Sat, 11 Jul 1998 17:09:11 PDT
Sender: [email-masked]

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

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: BGP alternate routes
Date: Sat, 11 Jul 1998 14:39:41 PDT
Sender: [email-masked]

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

To: [email-masked]
cc: [email-masked]
Subject: draft-ietf-idr-route-damp-03.txt to PS
Date: Fri, 10 Jul 98 14:07:33 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Rob,

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

Yakov.

To: [email-masked]
Subject: IDR WG meeting schedule
Date: Mon, 06 Jul 98 10:23:55 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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.

From: [email-masked]
Date: Fri, 3 Jul 1998 01:24:49 -0500
To: [email-masked]
Subject: Are you an Internet Marketer?
Sender: [email-masked]

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 (305) 418-7590.

*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)

Date: Thu, 2 Jul 1998 14:38:47 -0700 (PDT)
From: Randy Bush <[email-masked]>
To: Marcelo Manta <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: bgp
Sender: [email-masked]

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

randy

To: [email-masked]
cc: [email-masked]
Subject: draft-ietf-idr-bgp-tcp-md5-01.txt to PS
Date: Thu, 02 Jul 98 10:38:40 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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.

Date: Thu, 02 Jul 1998 14:37:00 -0200
From: Marcelo Manta <[email-masked]>
Organization: Saga Sistemas e Computadores
To: [email-masked]
CC: [email-masked]
Subject: Re: bgp
Sender: [email-masked]

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

TIA,

[email-masked] 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

From: [email-masked]
Date: Thu, 2 Jul 1998 11:38:01 -0400
To: <[email-masked]>
Subject: bgp
Content-Description: "cc:Mail Note Part"
Sender: [email-masked]

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

thanks

dg