Subject: Re: WG Last Call
From: Antoni Przygienda <[email-masked]>
To: Joel Halpern <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Date: Wed, 24 Dec 1997 00:32:14 -0500

Joel Halpern wrote:

> I have a question for the working group about this advancement.
> First, let me state that I understand that what is described here is in
> use and works.
>
> On the other hand, judging from other factors, the desired direction would
> be to support IPsec, when that is deployed (deployable?  take your pick).
>
> Clearly, document this (MD5 TCP Shim) is a good thing, and we should have
> it.
> The question I see is whether proposed standard is the correct status for
> this document.  Given that it works, "Experimental" is wrong since that
> would imply that it might not work.
> However, Informational would seem a better general category.  One might
> object that in fact we want a stronger imprimature than informational.
> Would BCP be suitable?  Would an Informational document with a BCP
> applicability statement be better?
> Or can someone make a good case for proposed status?  If we accept that
> IPsec is the long term way to go, then we do not expect to advance this up
> the standards track.  Making a PS with the hope of making it historic
> seems odd to me.
>

Given my perception of the working group discussions they were indicating
that the scheme issuffering from some assumptions (e.g. proper TCP sequence
number generation
for nonces to prevent replay attacks [which are not well documented in the
draft])
and technical imperfections (such as MD5 vulnerability, which are pretty
well documented in the draft). I did not understand whether the group decided

finally to make it a PS or informational only. Opinions were manifold ....

I thought to hear out that IPSec would be the preffered way (in case it will
be
deployed).

                            thank you

                            --- tony

> On Tue, 23 Dec 1997, Yakov Rekhter wrote:
>
> > Folks,
> >
> > This is to begin the WG Last Call on advancing
> > draft-heffernan-bgp-tcp-md5-00.txt to a Proposed Standard. The Last
> > Call ends 1/15/98.
> >
> > Yakov.
> >
>
> Yours,
> Joel M. Halpern                         [email-masked]
> Newbridge Networks Inc.

Date: Tue, 23 Dec 97 09:22 PST
From: Randy Bush <[email-masked]>
To: Joel Halpern <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: WG Last Call
Sender: [email-masked]

It is a protocol spec, and is widely deployed.  So BCP is less appropriate
than Proposed.

This is just an old cleanup item.  Can we just let it progress?

randy

Date: Tue, 23 Dec 1997 11:36:13 -0500 (EST)
From: Joel Halpern <[email-masked]>
To: Yakov Rekhter <[email-masked]>
cc: [email-masked]
Subject: Re: WG Last Call
Sender: [email-masked]

I have a question for the working group about this advancement.
First, let me state that I understand that what is described here is in
use and works.

On the other hand, judging from other factors, the desired direction would
be to support IPsec, when that is deployed (deployable?  take your pick).

Clearly, document this (MD5 TCP Shim) is a good thing, and we should have
it.
The question I see is whether proposed standard is the correct status for
this document.  Given that it works, "Experimental" is wrong since that
would imply that it might not work.
However, Informational would seem a better general category.  One might
object that in fact we want a stronger imprimature than informational.  
Would BCP be suitable?  Would an Informational document with a BCP
applicability statement be better?
Or can someone make a good case for proposed status?  If we accept that
IPsec is the long term way to go, then we do not expect to advance this up
the standards track.  Making a PS with the hope of making it historic
seems odd to me.

On Tue, 23 Dec 1997, Yakov Rekhter wrote:

> Folks,
> 
> This is to begin the WG Last Call on advancing
> draft-heffernan-bgp-tcp-md5-00.txt to a Proposed Standard. The Last
> Call ends 1/15/98.
> 
> Yakov.
> 

Yours,
Joel M. Halpern                         [email-masked]
Newbridge Networks Inc.

To: [email-masked]
Subject: WG Last Call
Date: Tue, 23 Dec 97 07:24:31 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

This is to begin the WG Last Call on advancing
draft-heffernan-bgp-tcp-md5-00.txt to a Proposed Standard. The Last
Call ends 1/15/98.

Yakov.

Date: Fri, 19 Dec 1997 20:41:34 -0500
To: Pedro Marques <[email-masked]>, Dimitry Haskin <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: Last Call (draft-ietf-idr-bgp4-ipv6-00.txt)
Cc: [email-masked]
Sender: [email-masked]

At 04:07 PM 12/19/97 -0800, Pedro Marques wrote:
>>>>>> "Dimitry" == Dimitry Haskin <[email-masked]> writes:
>
>
>    Dimitry> "Implementations should be able to support disabling the
>    Dimitry> advertisement of a global scope address in the Next Hop
>    Dimitry> Network Address field of an IPv6 MP_REACH_NLRI attribute
>    Dimitry> which is sent to an external peer.
>
>    >>  So what would the nexthop look like ?
>    >> 
>
>    Dimitry> In this case in contains a link-local scope address only.
>    Dimitry> In the default case both link-local and global addresses
>    Dimitry> are advertised as in your draft.
>
>Personally, I see your proposal as a step backwards as it drives us further
>away from what i see as the desirable objective which is to not have 
>link local addresses in routing protocols or routing tables.
>
I don't agree but this is a different subject. In any extend at this point
link-local addresses are required in forwarding tables and therefore in
routing protocols, like it or not.  My proposal does not make this
requirement any more or any less.

>My suggestion would be to take the discussion on what is essentially an
>IPv6 architecture problem to the IPng WG and advance this document to PS.
>
I doubt very much you'll get any where with your architectural disagreement
but you welcome to try. As far as the document is concerned, you can't
remove requirement for the link-local address at this point.  Therefore the
use of global next hop addresses is only limited to what is advertised in
the Next Hop field. The text that I offered does not modify default
behavior that you specified.  It only allows some extra flexibility when it
is *explicitly* known that the advertised global address is not used by
receiving peer in any way.  I belive my request is quite reasonable in the
context of the current architecture.  In the unlikely event that you get to
change the IPv6 architecture, it will be completely different ball game and
all protocol specs will need to be revisited any way.

>I would really like to abolish the use of link locals altogether but that
>would need approval from the IPng WG also...
>
>  Pedro.
>
Dimitry

Date: Fri, 19 Dec 1997 16:07:01 -0800 (PST)
From: Pedro Marques <[email-masked]>
To: Dimitry Haskin <[email-masked]>
Cc: [email-masked]
Subject: Re: Last Call (draft-ietf-idr-bgp4-ipv6-00.txt)
Sender: [email-masked]

>>>>> "Dimitry" == Dimitry Haskin <[email-masked]> writes:

    Dimitry> "Implementations should be able to support disabling the
    Dimitry> advertisement of a global scope address in the Next Hop
    Dimitry> Network Address field of an IPv6 MP_REACH_NLRI attribute
    Dimitry> which is sent to an external peer.

    >>  So what would the nexthop look like ?
    >> 

    Dimitry> In this case in contains a link-local scope address only.
    Dimitry> In the default case both link-local and global addresses
    Dimitry> are advertised as in your draft.

Personally, I see your proposal as a step backwards as it drives us further
away from what i see as the desirable objective which is to not have 
link local addresses in routing protocols or routing tables.

My suggestion would be to take the discussion on what is essentially an
IPv6 architecture problem to the IPng WG and advance this document to PS.

I would really like to abolish the use of link locals altogether but that
would need approval from the IPng WG also...

  Pedro.

Date: Fri, 19 Dec 1997 18:50:58 -0500
To: Pedro Marques <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: Last Call (draft-ietf-idr-bgp4-ipv6-00.txt)
Cc: Dimitry Haskin <[email-masked]>, [email-masked]
Sender: [email-masked]

At 02:30 PM 12/19/97 -0800, Pedro Marques wrote:
>>>>>> "Dimitry" == Dimitry Haskin <[email-masked]> writes:
>
>    Dimitry> Let me offer the text that I'd like to have inserted in
>    Dimitry> the draft.  Hopefully it will be more acceptable to all
>    Dimitry> sides in the argument.
>
>    Dimitry> "Implementations should be able to support disabling the
>    Dimitry> advertisement of a global scope address in the Next Hop
>    Dimitry> Network Address field of an IPv6 MP_REACH_NLRI attribute
>    Dimitry> which is sent to an external peer.
>
>So what would the nexthop look like ?
>
In this case in contains a link-local scope address only.  In the default
case both link-local and global addresses are advertised as in your draft.

>  Pedro.

Dimitry

Date: Fri, 19 Dec 1997 14:30:42 -0800 (PST)
From: Pedro Marques <[email-masked]>
To: Dimitry Haskin <[email-masked]>
Cc: [email-masked]
Subject: Re: Last Call (draft-ietf-idr-bgp4-ipv6-00.txt)
Sender: [email-masked]

>>>>> "Dimitry" == Dimitry Haskin <[email-masked]> writes:

    Dimitry> Let me offer the text that I'd like to have inserted in
    Dimitry> the draft.  Hopefully it will be more acceptable to all
    Dimitry> sides in the argument.

    Dimitry> "Implementations should be able to support disabling the
    Dimitry> advertisement of a global scope address in the Next Hop
    Dimitry> Network Address field of an IPv6 MP_REACH_NLRI attribute
    Dimitry> which is sent to an external peer.

So what would the nexthop look like ?

  Pedro.

Date: Fri, 19 Dec 1997 12:40:40 -0500
To: Dimitry Haskin <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: Last Call (draft-ietf-idr-bgp4-ipv6-00.txt)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Let me offer the text that I'd like to have inserted in the draft.
Hopefully it will be more acceptable to all sides in the argument.

"Implementations should be able to support disabling the advertisement of a
global scope address in the Next Hop Network Address field of an IPv6
MP_REACH_NLRI attribute which is sent to an external peer. This capability
should be only used when there is explicit knowledge that the external peer
does not use the global scope next hop address in it operation (e.g.
re-writes the Next Hop Address with one of its own addresses). By default,
a global scope address shall be advertised in the Next Hop Network Address
field of an IPv6 MP_REACH_NLRI attribute."

Dimitry

At 05:42 PM 12/16/97 -0500, Dimitry Haskin wrote:
>Hi,
>
>1) It is not necessary to *mandate* that a global scope address be always
>present in the Next Hop Network Address field of an IPv6 MP_REACH_NLRI
>attribute which is sent between external peers that share a common link.
>In certain peering arrangements a border router re-writes the Next Hop
>Address with one of its own addresses when disseminating external routes to
>internal peers. In such cases it is sufficient to advertise only link-local
>scope addresses between external bgp peers and sending a global scope
>address in addition to a link-local address serves no purpose and only adds
>to administrative burden.
>
>Rewriting the Next Hop Address by border routers has become a quite common
>practice in IPv4 BGP deployments and I believe it will be more so in IPv6
>since it can make BGP peerings immune to renumbering in peering ASs.
>
>To summarize I request that advertising a global scope address in the Next
>Hop Network Address field of an IPv6 MP_REACH_NLRI attribute which is sent
>between external peers that share a common link be optional - i.e. a
>subject to the peering arrangement.
>
>2) A nit:
>
>>From section 4:
>
>   The link-local address shall be included in the Next Hop field if and
>   only if the BGP speaker shares a common subnet with the entity
>                                           ^^^^^^
>   identified by the global IPv6 address carried in the Network Address
>   of Next Hop field and the peer the route is being advertised to.
>
>"Subnet" should be replaced with "link". To use link-local addresses it is
>sufficient to share a link.
>
>Dimitry
>
>At 04:01 PM 12/13/97 PST, Yakov Rekhter wrote:
>>Folks,
>>
>>This is to start the WG Last Call on
>>draft-ietf-idr-bgp4-ipv6-00.txt.
>>
>>The Last Call ends 12/30.
>>
>>Yakov.
>>
>>
>
>

To: Quaizar Vohra <[email-masked]>
cc: [email-masked]
Subject: Re: 1st draft of notes 
Date: Thu, 18 Dec 1997 16:08:23 -0800
From: Paul Traina <[email-masked]>
Sender: [email-masked]

  From: Quaizar Vohra <[email-masked]>
  Subject: Re: 1st draft of notes 
  Paul Traina writes:
   >   
   >   I have one more question. Wouldn't it be useful to be able to disable
   >   or enable or reset peering for one address family over a TCP
   >   connection without disrupting peering for other address families, if
   >   multiple address family peerings are being done over the same TCP
   >   connection. As new IPv4 unicast peering takes around 10 to 15 minutes
   >   to become stable. Or one can live with this as reconfiguration happens
   >   very infrequently.Also in practise many AFs might not be run over the
   >   same TCP connecrion.
   > 
   > I don't recall there being anything forcing BGP to run on top of IPV4...
   > but I haven't read the spec in ages, so I am not qualified to comment.

  I think my question was not very clear. You are running BGP
  (either on top of IPv4 or IPv6), and you are exchanging, say 
  for example IPv4 unicast as well as IPv6 unicast routes over the
  same TCP connection. If there are large number of routes, exchanging
  of these routes on a newly initiated peering can take quite a while
  (e.g. 10 - 15 minutes for current complete internet routes). So 
  if you are exhanging routes for multiple AFs, it would be nice to 
  enable, disable or reset peering on a per AF basis. 

I thought that's what you meant.  There's currently no mechanism in BGP
to do that other than break the connection.  Therefore if you were to want
to do that, you'd tend to establish multiple BGP connections, and it would
be logical (but not required) to run the IPv6 over the IPv6 connection and
the IPv4 over the v4 connection.

To: Quaizar Vohra <[email-masked]>
cc: Paul Traina <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: 1st draft of notes 
Date: Thu, 18 Dec 1997 17:15:21 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Quaizar Vohra writes:
> 
> (e.g. 10 - 15 minutes for current complete internet routes).

If it takes that long your router is seriously broken.  :-(

> I think my question was not very clear. You are running BGP
> (either on top of IPv4 or IPv6), and you are exchanging, say 
> for example IPv4 unicast as well as IPv6 unicast routes over the
> same TCP connection. If there are large number of routes, exchanging
> of these routes on a newly initiated peering can take quite a while
> if you are exhanging routes for multiple AFs, it would be nice to 
> enable, disable or reset peering on a per AF basis. 
> 
> Quaizar

I do see your point though.  This would fall under import or export
policy.  You should be able to change and export statement on a router
and withdraw (or block the announcement of) either IPv4 or IPv6.  This
is outside of the scope of the protocol itself.

Curtis

From: Quaizar Vohra <[email-masked]>
Date: Thu, 18 Dec 1997 12:45:54 -0800 (PST)
To: Paul Traina <[email-masked]>
Cc: Quaizar Vohra <[email-masked]>, [email-masked]
Subject: Re: 1st draft of notes 
Sender: [email-masked]

Paul Traina writes:
 >   
 >   I have one more question. Wouldn't it be useful to be able to disable
 >   or enable or reset peering for one address family over a TCP
 >   connection without disrupting peering for other address families, if
 >   multiple address family peerings are being done over the same TCP
 >   connection. As new IPv4 unicast peering takes around 10 to 15 minutes
 >   to become stable. Or one can live with this as reconfiguration happens
 >   very infrequently.Also in practise many AFs might not be run over the
 >   same TCP connecrion.
 > 
 > I don't recall there being anything forcing BGP to run on top of IPV4...
 > but I haven't read the spec in ages, so I am not qualified to comment.

I think my question was not very clear. You are running BGP
(either on top of IPv4 or IPv6), and you are exchanging, say 
for example IPv4 unicast as well as IPv6 unicast routes over the
same TCP connection. If there are large number of routes, exchanging
of these routes on a newly initiated peering can take quite a while
(e.g. 10 - 15 minutes for current complete internet routes). So 
if you are exhanging routes for multiple AFs, it would be nice to 
enable, disable or reset peering on a per AF basis. 

Quaizar

To: Quaizar Vohra <[email-masked]>
cc: [email-masked]
Subject: Re: 1st draft of notes 
Date: Thu, 18 Dec 1997 12:21:23 -0800
From: Paul Traina <[email-masked]>
Sender: [email-masked]

  From: Quaizar Vohra <[email-masked]>
  Subject: Re: 1st draft of notes 
  
  Thanks Paul for your explanation.
  
  I agree that global addresses makes toubleshooting easier and
  other scope addresses might make it a little more difficult.
  
  But I remember you saying that ingress routers very often 
  change the external nexthop to their own addresses. 

If they don't extend their IGP to cover the DMZ, yes.  That's the
way we did it BGP3, but in BGP4 we decided to carry the neighbor's
egress router by default because it gave you better shortcutting
or metric checking ability.
  
  Allowing receiver to control whether xmitter uses global scoped 
  address springs from the above need itself. So if the above need
  is absolutely neccesary then one should mandate use of global
  addresses (I don't have much operational experience :-)).
  
  I know that mandating of global addresses makes code simpler.
  I agree that private global addresses will make a better solution than
  link local addresses. 
  
  I have one more question. Wouldn't it be useful to be able to disable
  or enable or reset peering for one address family over a TCP
  connection without disrupting peering for other address families, if
  multiple address family peerings are being done over the same TCP
  connection. As new IPv4 unicast peering takes around 10 to 15 minutes
  to become stable. Or one can live with this as reconfiguration happens
  very infrequently.Also in practise many AFs might not be run over the
  same TCP connecrion.

I don't recall there being anything forcing BGP to run on top of IPV4...
but I haven't read the spec in ages, so I am not qualified to comment.

From: Quaizar Vohra <[email-masked]>
Date: Thu, 18 Dec 1997 12:09:51 -0800 (PST)
To: Paul Traina <[email-masked]>
CC: [email-masked]
Subject: Re: 1st draft of notes 
Sender: [email-masked]

Thanks Paul for your explanation.

I agree that global addresses makes toubleshooting easier and
other scope addresses might make it a little more difficult.

But I remember you saying that ingress routers very often 
change the external nexthop to their own addresses. 

Allowing receiver to control whether xmitter uses global scoped 
address springs from the above need itself. So if the above need
is absolutely neccesary then one should mandate use of global
addresses (I don't have much operational experience :-)).

I know that mandating of global addresses makes code simpler.
I agree that private global addresses will make a better solution than
link local addresses. 

I have one more question. Wouldn't it be useful to be able to disable
or enable or reset peering for one address family over a TCP
connection without disrupting peering for other address families, if
multiple address family peerings are being done over the same TCP
connection. As new IPv4 unicast peering takes around 10 to 15 minutes
to become stable. Or one can live with this as reconfiguration happens
very infrequently.Also in practise many AFs might not be run over the
same TCP connecrion.

Thanks

Quaizar

To: Quaizar Vohra <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: 1st draft of notes 
Date: Wed, 17 Dec 1997 16:26:13 -0800
From: Paul Traina <[email-masked]>
Sender: [email-masked]

There already is operational experience that demonstrates the desire
for using addresses that are global throughout one administrative
domain with BGP4.  Using a global address gives you the ability to
directly pin something to a neighbor's egress router instead of
your ingress router.

Unfortunately, there's no half-way point between LL and global, so
the only way to carry this functionality forward is to use a global.

Whether or not a global address is required is of interest to the
receiving AS.  It needs to be under the receiver's control.  Therfore
if you do not mandate it, you must mandate negotiation with the default
being "send the global"  which means you have to administratively assign
a global address to that interface anyway.

Either way you optimize, you lose.  So I'd rather optimize in the direction
of having more data available rather than worry about renumbering BGPv6
ebgp peers, which can be solved several other ways (such as assigning
private (read: 1597) "global" addresses to your neighbors peers.

In any case, link-local addresses are a crock that should be taken
out back behind the barn and put down like a terminally ill animal.
They should only exist when a box is in the process of learning
it's place in the world.

Thank you for your indulgence,

Paul

From: Quaizar Vohra <[email-masked]>
Date: Wed, 17 Dec 1997 15:07:15 -0800 (PST)
To: [email-masked]
Cc: [email-masked]
Subject: 1st draft of notes
Sender: [email-masked]

[email-masked] writes:
 > 
 > 9) BGP-4+ for IPv6
 > 	draft-ietf-idr-bgp4-ipv6-00.txt
 > 	(Pedro Marques, F. Dupont)
 > 
 >     Discussion:
 > 	Discussion on the mailing list has raised Dimitry Haskin's
 > 	concerns about the requirement for Global addresses.
 > 	There is no clear consensus that this is a problem.
 > 	Code implementation require the global addresses. 
 > 

As I could not attend the last ietf meeting, could someone please 
explain me why code implementation requires global addresses.
I would agree that they simplify an implementation by avoiding 
usage of link local or addresses of other scopes.

Also since there are reasons for not making global addresses 
a requirement it would be more flexible to remove such a requirement
till there is an operational experience which neccesitates global
addresses.

Quaizar

From: [email-masked]
Date: Wed, 17 Dec 1997 17:00:39 -0500 (EST)
To: [email-masked]
Subject: 1st draft of notes
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Hi all:

Here's my first rough draft on the working group notes.
Please let me know is wrong.  I'll be glad to fix it.

Sue Hares

=========== 
Notes

Agenda:

1) Agenda Bashing
2) Status on Current Documents
3) Route Flap Damping (Curtis Villamizar)
4) BGP-4+ practice and experience for multicast
	(Dave Meyer)

5) To be Multihomed: Requirements and Definitions
	Howard Berkowitz

6) MD5 TCP for BGP (Pedro Marques) 

7) BGP Security Analysis  (Sandy Murphy)

8) Use of MD5 for BGP Authentication
		(T. Przygienda)

9) BGP-4+ for IPv6
	draft-ietf-idr-bgp4-ipv6-00.txt
	(Pedro Marques, F. Dupont)

10) Capability Negotiation values 
	draft-marques-bgp-cap-mp-00.txt
	(Pedro Marques, F. Dupont)

More Detailed Notes on the working group

1) Agenda Bashing
2) Status of Current Documents:
	Last Call - Multiprotocol Extensions for BGP-4 
	Sent to RFC Editor - Guidelines for AS

3) BGP Route Damping 
	draft-ietf-idr-route-damp-00.txt

	presentation at: 
		http://engr.ans.net/route-damp/route-damp-ietf.ps

	Discussion:	
	Move to Working Group last call for 2 weeks,
	Release as Proposed standard.

	Change "fixed" timer in BGP-4 draft specification from
	"must" to may.

4) BGP-4+ practice and experience for multicast
	(Dave Meyer)

	No document, slides at: http
	Discussion about the needs of multicast:

	a) referred to "multicast" group for discussion of SAFI
		containing MRIB (unicast for Multicast routes)
		and  GRIB (Class D addresses)

	b) Capability Negotiation request for the particular
		support of SAFI in multiprotocol option.

5) To Be Multihomed: Requirements and Definitions
	(H. Berkowitz)	 

	[presentation location needed]    

	draft-berkowitz-multirqmt-00.txt

	Suggestion that the application documents be forwarded to
	the Operations area for review and publication of RFCs.
	
	Other reviews are possible in the following exterior 
	communities: NANOG, IOPS, IEPG.

6) MD5 TCP for BGP (Pedro Marques) 
     draft-heffenan-bgp-tcp-md5-00.txt
	will be re-issued as a working group draft
	for progression to Proposed Standard.
	A two week Last call will be issued after
	the draft has been publish on the mailing 
	list.

7) BGP Security Analysis  (Sandy Murphy)

  Sandy Murphy presented a security analysis of
  BGP as presented in RFC 1771.  Discussion ensued
  on presentation.  The note taker's high points were:

     A) for protecting the BGP to bgp authentication the
	   options were:

		IPSEC  
		TCP over MD5 (item 6)
		MD5 for BGP Authentication (item 8)
	 
	  IPSEC/TCP over MD5 provided protection against the
	  RESET and SYN attacks.  MD5 for BGP Authentication
	  does not protect against RESET and SYN attacks.

     B) Any security of BGP from creating ISP to final
	ISP by means of signatures on UPdate packet information
	(ASPATH, nlri grouping) does:
	
	a) also require filtering at each point to ensure the 
		necessary  aspath-nlri is correct

	b) require a substantial investment in authentication
	   administration for "signatures"

   The note taker requests additional feedback on this section
   of the meeting prior to producing the final minutes of the
   meeting.  			

8) Use of MD5 for BGP Authentication
		(T. Przygienda)
	draft-przygienda-bgp-md5-00.txt
	(presentation location required) 

9) BGP-4+ for IPv6
	draft-ietf-idr-bgp4-ipv6-00.txt
	(Pedro Marques, F. Dupont)

    Discussion:
	Discussion on the mailing list has raised Dimitry Haskin's
	concerns about the requirement for Global addresses.
	There is no clear consensus that this is a problem.
	Code implementation require the global addresses. 

	The Document will go to Last Call on the Working Group list 
	prior to being forward on Proposed Standard track. 

10) Capability Negotiation Option for IPv6

	draft-marques-bgp-cap-mp-00.txt

   Discussion:
	Capability option seems reasonable, but must await
	the forwarding of the Capability Options processing
	to proceed forward along the standards track. 
	Once the Capability Options have been forwarded, this
	document will go to the working group for last call. 

	 

Date: Tue, 16 Dec 1997 17:42:07 -0500
To: [email-masked]
From: Dimitry Haskin <[email-masked]>
Subject: Re: Last Call (draft-ietf-idr-bgp4-ipv6-00.txt)
Cc: [email-masked]
Sender: [email-masked]

Hi,

1) It is not necessary to *mandate* that a global scope address be always
present in the Next Hop Network Address field of an IPv6 MP_REACH_NLRI
attribute which is sent between external peers that share a common link.
In certain peering arrangements a border router re-writes the Next Hop
Address with one of its own addresses when disseminating external routes to
internal peers. In such cases it is sufficient to advertise only link-local
scope addresses between external bgp peers and sending a global scope
address in addition to a link-local address serves no purpose and only adds
to administrative burden.

Rewriting the Next Hop Address by border routers has become a quite common
practice in IPv4 BGP deployments and I believe it will be more so in IPv6
since it can make BGP peerings immune to renumbering in peering ASs.

To summarize I request that advertising a global scope address in the Next
Hop Network Address field of an IPv6 MP_REACH_NLRI attribute which is sent
between external peers that share a common link be optional - i.e. a
subject to the peering arrangement.

2) A nit:

>From section 4:

   The link-local address shall be included in the Next Hop field if and
   only if the BGP speaker shares a common subnet with the entity
                                           ^^^^^^
   identified by the global IPv6 address carried in the Network Address
   of Next Hop field and the peer the route is being advertised to.

"Subnet" should be replaced with "link". To use link-local addresses it is
sufficient to share a link.

Dimitry

At 04:01 PM 12/13/97 PST, Yakov Rekhter wrote:
>Folks,
>
>This is to start the WG Last Call on
>draft-ietf-idr-bgp4-ipv6-00.txt.
>
>The Last Call ends 12/30.
>
>Yakov.
>
>

To: "Ken Rosenfeld" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Route Dampening: How is a "route" defined? 
Date: Tue, 16 Dec 1997 10:43:56 -0800
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Ken, 

> Date:    Thu, 11 Dec 1997 16:32:41 -0500
> From:    "Ken Rosenfeld" <[email-masked]>
> To:      [email-masked]

> In the context of route dampening, how is a "route" defined?
> 
> <draft-ietf-idr-route-damp-00> states (p. 13):
>   "A route here is considered to be a tuple containing at least
>    NLRI prefix, next hop, and AS path."
> 

> I think the cisco IOS 11.2 implementation has a different view.
[deleted]

It was a bug - a penalty was charged when a withdrawn prefix was
re-announced.  It has been fixed in 011.002(009.001) and many 
other versions. The related ddts's are: CSCdj45833 / CSCdj39433. 

-- Enke

From: Quaizar Vohra <[email-masked]>
Date: Mon, 15 Dec 1997 18:04:32 -0800 (PST)
To: [email-masked]
Subject: peering changes in BGP4+
Sender: [email-masked]

I was wondering on the usefulness of providing a mechanism which would
allow one to manipulate peering on a per AF basis. If I am peering for
multiple Address families on the same TCP connection, I might want
to stop, start or reset peering for a particular address family without
disrupting active peerings on other AFs.

I don't know if such a mechanism would get used very often in practice.
It depends on whether people would like to run BGP for more than
one AF on the same TCP connection.

Any thoughts ?

Quaizar

To: [email-masked]
Subject: Last Call
Date: Sat, 13 Dec 97 16:01:35 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

This is to start the WG Last Call on
draft-ietf-idr-bgp4-ipv6-00.txt.

The Last Call ends 12/30.

Yakov.

To: [email-masked]
Subject: WG Last Call
Date: Fri, 12 Dec 97 10:40:20 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

This is the WG Last Call on advancing draft-ietf-idr-route-damp-00.txt
to a Proposed Standard. The Last Call completes on 12/29.

Yakov.

P.S. If you have editorial comments please send them directly to
Curtis.

To: [email-masked]
cc: "Ken Rosenfeld" <[email-masked]>, [email-masked]
Subject: Re: Route Dampening: How is a "route" defined? 
Date: Thu, 11 Dec 1997 23:51:03 -0800
From: Paul Traina <[email-masked]>
Sender: [email-masked]

  From: Curtis Villamizar <[email-masked]>
  Subject: Re: Route Dampening: How is a "route" defined? 
  
  In message <[email-masked]>, "Ken Rosenfeld" wri
>>te
  s:
  > In the context of route dampening, how is a "route" defined?
  > 
  > <draft-ietf-idr-route-damp-00> states (p. 13):
  >   "A route here is considered to be a tuple containing at least
  >    NLRI prefix, next hop, and AS path."
  > 
  > I think the cisco IOS 11.2 implementation has a different view.
  > 
  > I did the following test:
  > 
  > bgp simulator   <------------>      cisco router
  > -------------                       ------------
  > 
  > announce 178.0.0.0
  >          next-hop=192.1.1.3
  >          AS_PATH={2 51 78 34 89}
  > 
  > withdraw route                      penalty assigned
  > announce route                      penalty incremented
  > withdraw route                      penalty > suppress limit
  > announce route                      route suppressed
  > withdraw route
  > 
  > announce 178.0.0.0                  this new route inherits
  >          next-hop=192.1.1.2         penalty of previous route and
  >          AS_PATH={2 102 10 101}     is suppressed
  > 
  > Thanks,
  > 
  > Ken

  You are probably correct in pointing out that the definition or route
  or lack of needs to be more clearly stated in the route flap damping
  draft.
  
  In the beginning of section 4.4.3 the draft states (mid page 11 in the
  PS version, page 13 in the text version)
  
    The following information must be maintained per route.  A route here
    is considered to be a tuple containing at least NLRI prefix, next hop,
    and AS path.  The tuple may also contain other BGP attributes such as
    MULTI_EXIT_DISCRIMINATOR (MED).

I like your current definition in the draft, and have no objections with
clarifying it.

I'm glad you made the MED and NEXT_HOP optional -- there are good reasons
for including them,  but there are some intuitively obvious concerns too.

To: "Ken Rosenfeld" <[email-masked]>
cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: Route Dampening: How is a "route" defined? 
Date: Thu, 11 Dec 1997 21:44:13 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, "Ken Rosenfeld" write
s:
> In the context of route dampening, how is a "route" defined?
> 
> <draft-ietf-idr-route-damp-00> states (p. 13):
>   "A route here is considered to be a tuple containing at least
>    NLRI prefix, next hop, and AS path."
> 
> I think the cisco IOS 11.2 implementation has a different view.
> 
> I did the following test:
> 
> bgp simulator   <------------>      cisco router
> -------------                       ------------
> 
> announce 178.0.0.0
>          next-hop=192.1.1.3
>          AS_PATH={2 51 78 34 89}
> 
> withdraw route                      penalty assigned
> announce route                      penalty incremented
> withdraw route                      penalty > suppress limit
> announce route                      route suppressed
> withdraw route
> 
> announce 178.0.0.0                  this new route inherits
>          next-hop=192.1.1.2         penalty of previous route and
>          AS_PATH={2 102 10 101}     is suppressed
> 
> Thanks,
> 
> Ken

You are probably correct in pointing out that the definition or route
or lack of needs to be more clearly stated in the route flap damping
draft.

In the beginning of section 4.4.3 the draft states (mid page 11 in the
PS version, page 13 in the text version)

  The following information must be maintained per route.  A route here
  is considered to be a tuple containing at least NLRI prefix, next hop,
  and AS path.  The tuple may also contain other BGP attributes such as
  MULTI_EXIT_DISCRIMINATOR (MED).

This might almost be better conspicuously defined in a separate
subsection with:

   A route is defined as:

     NLRI
       prefix		required
       length		required
     AS path		required
     next hop		optional
     MED                optional

I'm not sure what other BPG attributes you might consider damping on.
If someone can't keep a constant MED or next hop it is a likely an
indication of instability in their IGP.  OTOH you may prefer to not
damp on next hop because you don't have to propogate the change
further and you amy want to not damp on MED because you either don't
have to propagate further if you use MED for only next hop resolution
or at worst don't have to propagate the change beyond your own IGP.

The draft is clear about only penalizing the down transition and not
the up transition.  I view Cisco's penalizing the up transition as a
bug.  I'll forward a message from the IEPG list that supports that
assertion.

Curtis

From: "Ken Rosenfeld" <[email-masked]>
Date: Thu, 11 Dec 1997 16:32:41 -0500
To: [email-masked]
Subject: Route Dampening: How is a "route" defined?
Sender: [email-masked]

In the context of route dampening, how is a "route" defined?

<draft-ietf-idr-route-damp-00> states (p. 13):
  "A route here is considered to be a tuple containing at least
   NLRI prefix, next hop, and AS path."

I think the cisco IOS 11.2 implementation has a different view.

I did the following test:

bgp simulator   <------------>      cisco router
-------------                       ------------

announce 178.0.0.0
         next-hop=192.1.1.3
         AS_PATH={2 51 78 34 89}

withdraw route                      penalty assigned
announce route                      penalty incremented
withdraw route                      penalty > suppress limit
announce route                      route suppressed
withdraw route

announce 178.0.0.0                  this new route inherits
         next-hop=192.1.1.2         penalty of previous route and
         AS_PATH={2 102 10 101}     is suppressed

Thanks,

Ken

Date: Mon, 8 Dec 1997 16:00:52 -0500
From: [email-masked] (Vivian_Lu)
To: [email-masked]
Subject: Re: third party nexthop
Sender: [email-masked]

Hi all,

Thanks to all the feedback to my question.
They have been very helpful.

Vivian.

> From [email-masked] Mon Nov 24 16:57:01 1997
> Date: Mon, 24 Nov 1997 16:24:36 -0500
> From: [email-masked] (Vivian_Lu)
> To: [email-masked]
> Subject: third party nexthop
> Cc: [email-masked]
> X-Sun-Charset: US-ASCII
> Sender: [email-masked]
> Content-Length: 2468
> 
> 
> Hi,
> 
> We are currently implementing bgp4, and have the following questions.
> 
> In the latest draft, (section 5.1.3 NEXT_HOP)
> 
>   "The NEXT_HOP path attribute defines the IP address of the border
>    router that should be used as the next hop to the destinations listed
>    in the UPDATE message.  When advertising a NEXT_HOP attribute to an
>    external peer, a router may use one of its own interface addresses in
>    the NEXT_HOP attribute provided the external peer to which the route
>    is being advertised shares a common subnet with the NEXT_HOP address.
>    This is known as a "first party" NEXT_HOP attribute.  A BGP speaker
>                                                          ^^^^^^^^^^^^^
>    can advertise to an external peer an interface of any internal peer
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    router in the NEXT_HOP attribute provided the external peer to which
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    the route is being advertised shares a common subnet with the
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    NEXT_HOP address.  This is known as a "third party" NEXT_HOP
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    attribute.  A BGP speaker can advertise any external peer router in
>    ^^^^^^^^^
>    the NEXT_HOP attribute provided that the IP address of this border
>    router was learned from an external peer and the external peer to
>    which the route is being advertised shares a common subnet with the
>    NEXT_HOP address.  This is a second form of "third party" NEXT_HOP
>    attribute."
> 
> It seems to me with the underlined restriction in the "third party" 
> NEXT_HOP case, the internal peer whose interface address is advertised
> in the NEXT_HOP attribute by the BGP speaker must be on the same subnet
> as BGP speaker and its external peer.
> 
> My question is when and how does this get used in the real world scenario?
> why will there be a need of a IBGP and EBGP running on two different machines
> on the same subnet?
> and how many vendors actually enforce this checking?
> 
> Your help is very much appreciated.
> 
> Vivian.
> ------------------------------------------------------------------------
> Vivian H. Lu                 E-MAIL: [email-masked]
> NetEdge Systems, Inc.        PHONE: (508)670-2934
> 85 Rangeway Road,            FAX: (508)262-0802
> Billerica, Massachusetts.
> ------------------------------------------------------------------------
> 
> 
> 

To: Andy Heffernan <[email-masked]>
cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: a draft that missed the deadline 
Date: Fri, 05 Dec 1997 11:06:09 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Andy Heffernan writes:
> [...]
> > I think the T1 NSS routers had MD4 signatures before that so that
> > probably means we get to blame Yakov for the idea.
> > 
> > Curtis
> 
> Since we're in the pre-IETF quiet-time period now, here's the TCP MD5
> draft as it I plan to submit it after December 7.  It's been renamed
> and revised a bit to make it more obvious that its intended use is to
> protect BGP sessions.
> 
> I won't be at the IETF, but Pedro Marques will do a short presentation
> on this, and should be able to answer questions about it (as will
> other folks who will be there).

Andy,

Thanks for the early copy.  It might be good to move this forward as
informational of BCP to document an existing implementation and do
something a bit stronger later.

Curtis

To: Tony Li <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: third party nexthop 
Date: Wed, 03 Dec 1997 14:13:15 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Tony Li writes:
> 
> Curtis,
> 
>    Didn't Barrnet have 6-8 peers with enss128 at Hayward in the old
>    NSFNET days and send tons of third party routes?  I thought for a
>    while you wrote the BGP code on the Barrnet side of this and I wrote
>    the BGP code on the NSFNET side.  (Senility?  Yours or mine? :)
> 
> Well, it's definitely senility cause I don't know of an ENSS that was ever
> at Hayward.  Stanford, yes....  ;-)

Oops.  Off by one hop.

> I don't dispute that the code is out there to support it.  I just don't
> know of people using it.
> 
>    Still goes on today.
> 
> Ok, I sit educated.  ;-)

The problems with partial connectivity in bridged or switched level 2
broadcast media have prompted many to disable third party routing
using next-hop-self.  Where problems have not occurred (for example,
single level 2 switch without this sort of bug or physical level 2
segment.

It is probably worth mentioning that it is a good idea to have a per
peer configurable option to disable third party routing and substitute
ones own interface address.  Doesn't hurt to call that option
next-hop-self since people are used to that name.

> Tony

Curtis

To: Andy Heffernan <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: a draft that missed the deadline 
Date: Thu, 04 Dec 1997 15:03:05 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Andy Heffernan writes:
> In article <[email-masked]> you write:
> >
> >Sandy,
> >
> >   I am well aware of Andy Heffernan's work (which I thought you also had
> >   a hand in, judging by our conversations about TCP RST's).  I did not
> >   mention it because, as you said, the work had been dropped from the
> >   IETF working group active consideration.
> >
> >Well, I don't believe that it was actively dropped so much as expired by
> >entropy.
> 
> The idea of having an MD5 signature for each TCP segment I think was
> Tony's, related to me about 4.5 years ago.  Don't know if he was
> thinking about carrying it in an option, but that's how it turned out.
> 
> The draft has been resubmitted, with an extra paragraph or two about
> the use of MD5 as the hash algorithm.  We'll see what we can do about
> (finally) turning it into an RFC of some flavor.

I think the T1 NSS routers had MD4 signatures before that so that
probably means we get to blame Yakov for the idea.

Curtis

Date: Thu, 4 Dec 1997 12:03:55 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: a draft that missed the deadline
Sender: [email-masked]

   I think the T1 NSS routers had MD4 signatures before that so that
   probably means we get to blame Yakov for the idea.

Oh, whew.  ;-)

Tony

To: [email-masked]
cc: [email-masked]
Subject: Re: a draft that missed the deadline 
Date: Thu, 04 Dec 1997 18:16:16 -0800
From: Andy Heffernan <[email-masked]>
Sender: [email-masked]

[...]
> I think the T1 NSS routers had MD4 signatures before that so that
> probably means we get to blame Yakov for the idea.
> 
> Curtis

Since we're in the pre-IETF quiet-time period now, here's the TCP MD5
draft as it I plan to submit it after December 7.  It's been renamed
and revised a bit to make it more obvious that its intended use is to
protect BGP sessions.

I won't be at the IETF, but Pedro Marques will do a short presentation
on this, and should be able to answer questions about it (as will
other folks who will be there).


INTERNET-DRAFT                                            Andy Heffernan
<draft-heffernan-bgp-tcp-md5-00.txt>                       cisco Systems
                                                        December 1, 1997

      Protection of BGP Sessions via the TCP MD5 Signature Option

Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any Internet
   Draft.

Abstract

   This memo describes a TCP extension to enhance security for BGP.  It
   defines a new TCP option for carrying an MD5 [RFC1321] digest in a
   TCP segment.  This digest acts like a signature for that segment,
   incorporating information known only to the connection end points.
   Since BGP uses TCP as its transport, using this option in the way
   described in this paper significantly reduces the danger from certain
   security attacks on BGP.

   This document specifies an experimental protocol for use in the
   Internet.

1.0  Introduction

   The primary motivation for this option is to allow BGP to protect
   itself against the introduction of spoofed TCP segments into the
   connection stream.  Of particular concern are TCP resets.

   To spoof a connection using the scheme described in this paper, an
   attacker would not only have to guess TCP sequence numbers, but would
   also have had to obtain the password included in the MD5 digest.
   This password never appears in the connection stream, and the actual

Heffernan                 Expires June 1, 1998                  [Page 1]

INTERNET-DRAFT          TCP MD5 Signature Option        December 1, 1997

   form of the password is up to the application.  It could even change
   during the lifetime of a particular connection so long as this change
   was synchronized on both ends (although retransmission can become
   problematical in some TCP implementations with changing passwords).

   Finally, there is no negotiation for the use of this option in a
   connection, rather it is purely a matter of site policy whether or
   not its connections use the option.

2.0  Proposal

   Every segment sent on a TCP connection to be protected against
   spoofing will contain the 16-byte MD5 digest produced by applying the
   MD5 algorithm to these items in the following order:

       1. the TCP pseudo-header (in the order: source IP address,
          destination IP address, zero-padded protocol number, and segment
          length)
       2. the TCP header, excluding options, and assuming a checksum of zero
       3. the TCP segment data (if any)
       4. an independently-specified key or password, known to both TCPs
          and presumably connection-specific

   The header and pseudo-header are in network byte order.  The nature
   of the key is deliberately left unspecified, but it must be known by
   both ends of the connection.  A particular TCP implementation will
   determine what the application may specify as the key.

   Upon receiving a signed segment, the receiver must validate it by
   calculating its own digest from the same data (using its own key) and
   comparing the two digest.  A failing comparison must result in the
   segment being dropped and must not produce any response back to the
   sender.  Logging the failure is probably advisable.

   Unlike other TCP extensions (e.g., the Window Scale option
   [RFC1323])), the absence of the option in the SYN,ACK segment must
   not cause the sender to disable its sending of signatures.  This
   negotiation is typically done to prevent some TCP implementations
   from misbehaving upon receiving options in non-SYN segments.  This is
   not a problem for this option, since the SYN,ACK sent during
   connection negotiation will not be signed and will thus be ignored.
   The connection will never be made, and non-SYN segments with options
   will never be sent.  More importantly, the sending of signatures must
   be under the complete control of the application, not at the mercy of
   the remote host not understanding the option.

3.0  Syntax

Heffernan                 Expires June 1, 1998                  [Page 2]

INTERNET-DRAFT          TCP MD5 Signature Option        December 1, 1997

   The proposed option has the following format:

             +---------+---------+-------------------+
             | Kind=19 |Length=18|   MD5 digest...   |
             +---------+---------+-------------------+
             |                                       |
             +---------------------------------------+
             |                                       |
             +---------------------------------------+
             |                                       |
             +-------------------+-------------------+
             |                   |
             +-------------------+

   The MD5 digest is always 16 bytes in length, and the option would
   appear in every segment of a connection.

4.0  Some Implications

4.1  Connectionless Resets

   A connectionless reset will be ignored by the receiver of the reset,
   since the originator of that reset does not know the key, and so
   cannot generate the proper signature for the segment.  This means,
   for example, that connection attempts by a TCP which is generating
   signatures to a port with no listener will time out instead of being
   refused.  Similarly, resets generated by a TCP in response to
   segments sent on a stale connection will also be ignored.
   Operationally this can be a problem since resets help BGP recover
   quickly from peer crashes.

4.2  Performance

   The performance hit in calculating digests may inhibit the use of
   this option.  Some measurements of a sample implementation showed
   that on a 100 MHz R4600, generating a signature for simple ACK
   segment took an average of 0.0268 ms, while generating a signature
   for a data segment carrying 4096 bytes of data took 0.8776 ms on
   average.  These times would be applied to both the input and output
   paths, with the input path also bearing the cost of a 16-byte
   compare.

4.3  TCP Header Size

   As with other options that are added to every segment, the size of
   the MD5 option must be factored into the MSS offered to the other

Heffernan                 Expires June 1, 1998                  [Page 3]

INTERNET-DRAFT          TCP MD5 Signature Option        December 1, 1997

   side during connection negotiation.  Specifically, the size of the
   header to subtract from the MTU (whether it is the MTU of the
   outgoing interface or IP's minimal MTU of 576 bytes) is now at least
   18 bytes larger.

   The total header size is also an issue.  The TCP header specifies
   where segment data starts with a 4-bit field which gives the total
   size of the header (including options) in 32-byte words.  This means
   that the total size of the header plus option must be less than or
   equal to 60 bytes -- this leaves 40 bytes for options.

   As a concrete example, 4.4BSD defaults to sending window-scaling and
   timestamp information for connections it initiates.  The most loaded
   segment will be the initial SYN packet to start the connection.  With
   MD5 signatures, the SYN packet will contain the following:

       -- 4 bytes MSS option
       -- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD)
       -- 12 bytes for timestamp (4.4BSD pads the option as recommended
          in RFC 1323 Appendix A)
       -- 18 bytes for MD5 digest
       -- 2 bytes for end-of-option-list, to pad to a 32-bit boundary.

   This sums to 40 bytes, which just makes it.

4.4  MD5 as a Hashing Algorithm

   Since this draft was first issued (under a different title), the MD5
   algorithm has been found to be vulnerable to collision search attacks
   [Dobb], and is considered by some to be insufficiently strong for
   this type of application.

   This draft still specifies the MD5 algorithm, however, since the
   option has already been deployed operationally, and there was no
   "algorithm type" field defined to allow an upgrade using the same
   option number.  The original draft did not specify a type field since
   this would require at least one more byte, and it was felt at the
   time that taking 19 bytes for the complete option (which would
   probably be padded to 20 bytes in TCP implementations) would be too
   much of a waste of the already limited option space.

   This does not prevent the deployment of another similar option which
   uses another hashing algorithm (like SHA-1).  Also, if most
   implementations pad the 18 byte option as defined to 20 bytes anyway,
   it would be just as well to define a new option which contains an
   algorithm type field.

   This would need to be addressed in another draft, however.

Heffernan                 Expires June 1, 1998                  [Page 4]

INTERNET-DRAFT          TCP MD5 Signature Option        December 1, 1997

5.0  References

   [RFC1321] Rivest, R, "The MD5 Message-Digest Algorithm," RFC 1321,
   MIT Laboratory for Computer Science, April 1992.

   [RFC1323] Jacobson, V., Braden, R, and D. Borman, "TCP Extensions for
   High Performance", RFC 1323, LBL, USC/Information Sciences Institute,
   Cray Research, May 1992.

   [Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack", RSA
   Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
   http://www.rsa.com/rsalabs/pubs/cryptobytes.html

Author's Address

   Andy Heffernan
   cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134  USA

   Phone:  +1 408 526-8115
   Email:  [email-masked]

Heffernan                 Expires June 1, 1998                  [Page 5]


To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [jnx.ext.ietf.idr] Re: a draft that missed the deadline 
Date: Thu, 04 Dec 1997 21:47:02 -0800
From: Bruce Cole <[email-masked]>
Sender: [email-masked]

> Be that as it may, I saw several messages in September between Ran
> Atkinson and Jeff Schiller about that draft, suggesting that it might
> be resurrected for publication as an Informational RFC.  Do you know
> anything more about that?

Yes, that discussion would have been in response to the completion of
my interoperable implementation of TCP MD5.  Last I heard Jeff was
supposedly planning to revive Andy's draft.

To: Tony Li <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: third party nexthop 
Date: Tue, 02 Dec 1997 17:57:34 -0500
From: Erik Sherk <[email-masked]>
Sender: [email-masked]

> 
> Curtis,
> 
>    Didn't Barrnet have 6-8 peers with enss128 at Hayward in the old
>    NSFNET days and send tons of third party routes?  I thought for a
>    while you wrote the BGP code on the Barrnet side of this and I wrote
>    the BGP code on the NSFNET side.  (Senility?  Yours or mine? :)
> 
> Well, it's definitely senility cause I don't know of an ENSS that was ever
> at Hayward.  Stanford, yes....  ;-)

We certainly used it on ENSS136. Jeez, what does it say when I can
remember that number, but can't remember what my wife wants me to pick
up at the store tonight? Must be Senility :-)
 
> I don't dispute that the code is out there to support it.  I just don't
> know of people using it.
> 
>    Still goes on today.

Yes, we use it extensivly today, mainly in a BGP confederation context.

Erik

> Ok, I sit educated.  ;-)
> 
> Tony

Date: Tue, 2 Dec 1997 14:23:58 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: third party nexthop
Sender: [email-masked]

Curtis,

   Didn't Barrnet have 6-8 peers with enss128 at Hayward in the old
   NSFNET days and send tons of third party routes?  I thought for a
   while you wrote the BGP code on the Barrnet side of this and I wrote
   the BGP code on the NSFNET side.  (Senility?  Yours or mine? :)

Well, it's definitely senility cause I don't know of an ENSS that was ever
at Hayward.  Stanford, yes....  ;-)

I don't dispute that the code is out there to support it.  I just don't
know of people using it.

   Still goes on today.

Ok, I sit educated.  ;-)

Tony

To: Tony Li <[email-masked]>
cc: [email-masked] (Vivian_Lu), [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: third party nexthop 
Date: Tue, 02 Dec 1997 17:16:56 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Tony Li writes:
> 
> I'm not aware of anyone who actually makes use of this as the redundancy in
> this mechanism is somewhat lacking...

Tony,

Didn't Barrnet have 6-8 peers with enss128 at Hayward in the old
NSFNET days and send tons of third party routes?  I thought for a
while you wrote the BGP code on the Barrnet side of this and I wrote
the BGP code on the NSFNET side.  (Senility?  Yours or mine? :)

Still goes on today.  We have two routers at some NAPs and two or more
at some private interconnects and so do other providers.

In any case, you do need to implement third party routing and you do
need to get it right and the quoted section of the RFC is correct.

Cheers,

Curtis

To: [email-masked] (Vivian_Lu)
cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: third party nexthop 
Date: Tue, 02 Dec 1997 16:45:57 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Vivian_Lu writes:
> 
> 
> My question is when and how does this get used in the real world scenario?

Major providers at a major interconnect.

> why will there be a need of a IBGP and EBGP running on two different machines
> on the same subnet?

Redundancy.  One or more providers may have two or more routers each
on the same media.

> and how many vendors actually enforce this checking?

I don't know of any that don't enforce this.  It can be overridden for
multihop EBGP but that's a hack used more for testing and for some very
ugly hacks.

Curtis

From: [email-masked]
Date: Tue, 02 Dec 97 01:49:32 EST
To: [email-masked]
Subject: NO   MORE   BOOKSTORE  !!!!!!!!
Reply-To: [email-masked]
Comments: Authenticated sender is <somi2aol.com>
Sender: [email-masked]

!!!!!   ATTENTION ALL COLLEGE STUDENTS    !!!!!!

PROBLEM: ARE YOU SICK & TIRED OF:
                                                    
       1   Waiting hours in line to purchase your textbooks? 
       2   Paying sales tax? 
       3   Waiting hours in line to sell back your textbooks,
           only to get  50% back of the purchased value,
           or even worse if there is an overstock you get nothing? 
                                        
SOLUTION: UNIVERSITYTEXT.COM WEBSITE
      A unique service on the Internet, offered to every college
      student in the World.   Its goal is to
      provide a central used textbook database on the Internet
      for the entire  college student  community,
      so that any student may
      BUY AND SELL TEXTBOOKS DIRECTLY TO
      ONE ANOTHER WITHIN THEIR COLLEGE.

UTILIZE:  UNIVERSITYTEXT.COM TO SAVE $$$$$$$
        Don't pay 100% retail for each textbook! 
        Don't lose 50% on each textbook that you sell back! 
        Don't wait in long lines ever again to buy or sell your textbooks! 
        No sales tax! 
                     
Advertise your used textbooks to other students in your college for what 
they're worth!  It only costs a buck ($1.00 processing) per textbook to
advertise on UNIVERSITYTEXT.COM. Buy your used textbooks
by viewing other students ads in your college on
UNIVERSITYTEXT.COM     for    FREE!!!    

HOW IT WORKS:
      1)   You advertise your BOOK FOR SALE by filling out a simple form. 
             The ad  is posted in  your college database for others to view.
      2)   To  BUY BOOKS you view other students ads, and get in touch 
             with them by using the  information they provided
             (e-mail, phone, etc.)
      3)    You can then meet on campus and complete the exchange.

Students who use this service could save hundreds of dollars a year.
As an example, on the average, a student purchases 4 textbooks 
per semester and pays approximately $50.00 per book, if not more,
totaling $200.00. When purchasing from the bookstore, you would 
pay 100% of the textbooks value instead of  75% 
(the recommended buy/sell percentage from UNIVERSITYTEXT.COM), 
which would equate to a $50.00 loss! At the end of the semester, when you
would try to sell your books back to the book store, you would receive
50% back of the purchased value, resulting in an additional $100.00 loss!
Thus, totaling a loss of $150.00 or more per semester! If you're on quarter
semesters, losses could result into $2400.00 or more per college education, 
not including the sales tax that everyone pays.

We welcome each college student  to take advantage
of this innovative service of saving both TIME and MONEY.

VISIT US AT UNIVERSITYTEXT.COM 

If you have any questions regarding this website,
please e-mail us at: [email-masked] 

Date: Mon, 1 Dec 1997 23:47:03 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: a draft that missed the deadline
Sender: [email-masked]

   The idea of having an MD5 signature for each TCP segment I think was
   Tony's, related to me about 4.5 years ago.  Don't know if he was
   thinking about carrying it in an option, but that's how it turned out.

Well, if you say so.  I don't remember it but I'll take the blame if you'll
take the credit.

Tony

Date: Mon, 1 Dec 1997 20:34:59 -0800
From: Andy Heffernan <[email-masked]>
To: [email-masked]
Subject: Re: a draft that missed the deadline
Newsgroups: cisco.external.ietf.iwg
Organization: cisco Systems, Inc., San Jose, CA
Cc: [email-masked], [email-masked]
Sender: [email-masked]

In article <[email-masked]> you write:
>
>Sandy,
>
>   I am well aware of Andy Heffernan's work (which I thought you also had
>   a hand in, judging by our conversations about TCP RST's).  I did not
>   mention it because, as you said, the work had been dropped from the
>   IETF working group active consideration.
>
>Well, I don't believe that it was actively dropped so much as expired by
>entropy.

The idea of having an MD5 signature for each TCP segment I think was
Tony's, related to me about 4.5 years ago.  Don't know if he was
thinking about carrying it in an option, but that's how it turned out.

The draft has been resubmitted, with an extra paragraph or two about
the use of MD5 as the hash algorithm.  We'll see what we can do about
(finally) turning it into an RFC of some flavor.

Date: Mon, 1 Dec 97 20:30 PST
From: Randy Bush <[email-masked]>
To: Tony Li <[email-masked]>
Cc: [email-masked]
Subject: Re: a draft that missed the deadline
Sender: [email-masked]

> that there's a Best Current Practice and it's pretty much a requirement
> today and there's no current documentation of it.

there is code and a lot of us, at least the more prudent ones, are running
it.  what stands in the way of getting the document revived and out?

randy

From: Andrew Partan <[email-masked]>
Subject: Re: a draft that missed the deadline
To: [email-masked] (Tony Li)
Date: Mon, 1 Dec 1997 19:10:24 -0500 (EST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>    I am well aware of Andy Heffernan's work (which I thought you also had
>    a hand in, judging by our conversations about TCP RST's).  I did not
>    mention it because, as you said, the work had been dropped from the
>    IETF working group active consideration.

Its in active use on the Internet today.  There are at least 2
implementations of it (there may be more).  I don't know anything
about its IETF status; I just know some about what is actually
used.
	[email-masked] (Andrew Partan)

Date: Mon, 1 Dec 1997 13:21:37 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: a draft that missed the deadline
Sender: [email-masked]

Sandy,

   I am well aware of Andy Heffernan's work (which I thought you also had
   a hand in, judging by our conversations about TCP RST's).  I did not
   mention it because, as you said, the work had been dropped from the
   IETF working group active consideration.

Well, I don't believe that it was actively dropped so much as expired by
entropy.

   I thought that the reason those drafts were allowed to expire was
   because the protection provided by IPSEC is at least as good as the
   protection provided by doing MD5 protection at the TCP level.

I suspect it was apathy rather than thought.  ;-)

   Given the limited amount of
   option space in the TCP packet and the recent concerns about MD5
   potential vulnerabilities by itself (leading the IPSEC group to
   recommend the HMAC approach), the IPSEC solution might even be better.

I don't disagree, but I'll point out that there's a Best Current Practice
and it's pretty much a requirement today and there's no current
documentation of it.

In short, I would like to see it revived as a draft, if only to become an
Informational (and someday Historical?) RFC.

   Be that as it may, I saw several messages in September between Ran
   Atkinson and Jeff Schiller about that draft, suggesting that it might
   be resurrected for publication as an Informational RFC.  Do you know
   anything more about that?

That's news to me.

   On a side note, I've been trying to come up with good reasons why
   keyed crypto hash protection at the application level might still be
   useful when IPSEC is fully deployed.  Given the number of protocols
   that have defined their own protection while waiting for IPSEC, it is
   a question with some broad applicability.  One might say that
   protecting at the application level prevents other processes in the
   same host from horning in.  Can you see that as a valid concern to
   keep application level protection when IPSEC protection is available?

I don't see that as valid for connection oriented protocols.  In
particular, if a host allows an untrusted user to generate random TCP
packets, that would be an OS issue.  For UDP based protocols, yes, I think
that there might be a valid concern.  Consider the multiuser host and the
ability of an untrusted user (under some OSs) to listen to well known
ports.  Brrr.....  

   I was asked, not for a recommendation, but for a discussion of the
   possibilities and the costs.  I think that the business environment
   plays such a large part in determining what level of protection you
   need as well as how much you're willing to do to protect yourself
   that it may take a community decision to make a recommendation.

Ok, different question/different answer.  

   If the usual environment was such that valid sequences of BGP peers
   were NOT likely to be valid AS_PATH (because of peering agreements
   and their effect on the traffic that will be transited, etc.), then
   you need assurance that the *path* is valid, which can mean assurance
   that your neighbor came by the determination of the path he/she/it
   sent you honestly - which means some sort of proof that your neighbor
   based its path on information IT received from a neighbor - which
   means passing on to you some sort of token from the neighbor's neighbor.
   And so forth.

I believe that we will eventually need to do this.  Note that I'm not
convinced that we need it today, but the ability of Joe Warez to tap into
the BGP mesh and fabricate BS is just too credible for any sense of
security.

   When you say "prefix assignment" problem, you're talking about some AS
   announcing a prefix that actually belongs to someone else? especially
   when it's in the middle of someone else's CIDR block?  Unfortunately,
   asking for that sort of protection is asking for assurance that
   someone is *authorized* (not just authenticated) to speak the
   information they are providing.

Yes, yes.

   Authorization is always something that one is given by someone else.
   So authorizing the advertisement of a network implies an
   infrastructure for assigning networks to AS's.  That means, for
   example, an authenticatable token from IANA proving you are allowed to
   announce this network (maybe given to you when you acquire the
   address), or some verification from some Internet registry (which
   implies an infrastructure that would make sure the registry itself had
   the correct info and got the info to you securely, etc).

   This is more than just a protocol question.  Do you think the idr
   group (and maybe the rps working group) could take on recommending an
   infrastructure like this?

Recommending?  No, I think it's wholly beyond the capabilities of the
group.  This is not because the protocol is difficult -- that is easily
doable.  The problem is the entire security infrastructure that you
correctly allude to.

I believe that this is the first order security problem that we should be
addressing.  Just for brevity's sake, let's refer to this as the 7007
problem.  ;-)

   (I suppose you point to DNS as an example
   of a working group that set up a ownership infrastructure.)

Was the DNS group soley responsible for DNSSEC?  Or did they get help?

   Then there's the problem of aggregation of information.  If you have
   aggregated several pieces of properly authorized information, how do
   you show that you are authorized to speak the aggregate?  Include all
   the individual authorization tokens?  That would pretty much undo the
   benefits of aggregation.

Yup, a fine question.

   And de-aggregation is a problem as well.  As long as BGP contains
   features to allow de-aggregation (a necessity, I think) of the
   addresses received, there will be the possibility of mis-use.  

Well, in fact, de-aggregation didn't actually ever happen.  And I think
that's a fine thing.  Primarily it was seen as a tool to ease the
transition to BGP, but the flash cutover was so quick (thanks to the folks
on this list) that the world never really needed it.  In fact, we might
move deaggregation to a non-feature someday soon (ala OSPF TOS).

Tony

Date: Mon, 1 Dec 1997 11:35:31 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: a draft that missed the deadline
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>I was quite disappointed to see no mention of
>draft-heffernan-tcp-md5-02.txt.gz (admittedly, it has expired) or its
>methods.  You alude to the benefits, but seem completely oblivious to the
>fact that it's already in shipping code.

I am well aware of Andy Heffernan's work (which I thought you also had
a hand in, judging by our conversations about TCP RST's).  I did not
mention it because, as you said, the work had been dropped from the
IETF working group active consideration.  I thought that the reason
those drafts were allowed to expire was because the protection
provided by IPSEC is at least as good as the protection provided by
doing MD5 protection at the TCP level.  Given the limited amount of
option space in the TCP packet and the recent concerns about MD5
potential vulnerabilities by itself (leading the IPSEC group to
recommend the HMAC approach), the IPSEC solution might even be better.

Be that as it may, I saw several messages in September between Ran
Atkinson and Jeff Schiller about that draft, suggesting that it might
be resurrected for publication as an Informational RFC.  Do you know
anything more about that?

On a side note, I've been trying to come up with good reasons why
keyed crypto hash protection at the application level might still be
useful when IPSEC is fully deployed.  Given the number of protocols
that have defined their own protection while waiting for IPSEC, it is
a question with some broad applicability.  One might say that
protecting at the application level prevents other processes in the
same host from horning in.  Can you see that as a valid concern to
keep application level protection when IPSEC protection is available?

>I was also hoping for more of a recommendation for the internal sources
>solution.  The problem there is of the most theoretical interest and the
>one that we would appreciate the assistance on.

I was asked, not for a recommendation, but for a discussion of the
possibilities and the costs.  I think that the business environment
plays such a large part in determining what level of protection you
need as well as how much you're willing to do to protect yourself
that it may take a community decision to make a recommendation.

If the usual environment was such that a valid sequence of BGP peers
was almost certainly also a valid AS_PATH (i.e., the policy decisions
would let traffic through), then Brad Smith's proposal to insert link
state information is attractive.  The frequency of signatures (I think)
can be reduced and therefore the number of verifications. You do have
to check each AS_PATH against the link state information to see if it
is a valid sequence of adjacent AS's, though.

If the usual environment was such that valid sequences of BGP peers
were NOT likely to be valid AS_PATH (because of peering agreements
and their effect on the traffic that will be transited, etc.), then
you need assurance that the *path* is valid, which can mean assurance
that your neighbor came by the determination of the path he/she/it
sent you honestly - which means some sort of proof that your neighbor
based its path on information IT received from a neighbor - which
means passing on to you some sort of token from the neighbor's neighbor.
And so forth.

As I said, the Internet registries can provide some of this assurance.
They certainly collect the sort of information that would provide
assurance that the hops represented in the AS_PATH are valid.  They
might also collect the detailed information about policies that would
help determine that AS_PATHs are valid.  The business environment
sticks its nose in that as well, as the policy information needed to
determine the validity of AS_PATH might be sensitive and something the
ISPs would not want published to the world.

>Finally, I was really hoping to see more discussion of the prefix
>assignment problem.  Again, you allude to it briefly in section 3.3, but
>the authenticated delegation of prefixes is a serious problem that we could
>use help with.

When you say "prefix assignment" problem, you're talking about some AS
announcing a prefix that actually belongs to someone else? especially
when it's in the middle of someone else's CIDR block?  Unfortunately,
asking for that sort of protection is asking for assurance that
someone is *authorized* (not just authenticated) to speak the
information they are providing.

Authorization is always something that one is given by someone else.
So authorizing the advertisement of a network implies an
infrastructure for assigning networks to AS's.  That means, for
example, an authenticatable token from IANA proving you are allowed to
announce this network (maybe given to you when you acquire the
address), or some verification from some Internet registry (which
implies an infrastructure that would make sure the registry itself had
the correct info and got the info to you securely, etc).

This is more than just a protocol question.  Do you think the idr
group (and maybe the rps working group) could take on recommending an
infrastructure like this?  (I suppose you point to DNS as an example
of a working group that set up a ownership infrastructure.)

Then there's the problem of aggregation of information.  If you have
aggregated several pieces of properly authorized information, how do
you show that you are authorized to speak the aggregate?  Include all
the individual authorization tokens?  That would pretty much undo the
benefits of aggregation.

And de-aggregation is a problem as well.  As long as BGP contains
features to allow de-aggregation (a necessity, I think) of the
addresses received, there will be the possibility of mis-use.  I
actually came to a full stop in early May on this work when I realized
that the MAI-Sprint problem was a fully legal use of the protocol,
just an extremely unwise one.  Maybe the proof-of-originable-address
infrastructure could prevent AS's from announcing class-ful addresses
that they weren't directly connected to.  I think that would mean
the protocol would have to know when an address was being advertised
as a direct connection, different from the ORIGIN attribute. 

This message is long enough.  I'll quit for now.

--Sandy