Subject: 1st draft of notes

From: [email-masked]
Date: Wed, 17 Dec 1997 17:00:39 -0500 (EST)

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.

---

From: Quaizar Vohra <[email-masked]>
Date: Wed, 17 Dec 1997 15:07:15 -0800 (PST)

> 	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: Paul Traina <[email-masked]>
Date: Wed, 17 Dec 1997 16:26:13 -0800

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: Paul Traina <[email-masked]>
Date: Thu, 18 Dec 1997 12:21:23 -0800

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)

Thanks

Quaizar

---

From: Quaizar Vohra <[email-masked]>
Date: Thu, 18 Dec 1997 12:45:54 -0800 (PST)

> 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

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 18 Dec 1997 17:15:21 -0500

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

> enable, disable or reset peering on a per AF basis. 

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: Paul Traina <[email-masked]>
Date: Thu, 18 Dec 1997 16:08:23 -0800

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.