Subject: RE: [RPSEC] proposed message to the IESG

From: "Susan Hares" <[email-masked]>
Date: Wed, 26 Jan 2005 11:58:24 -0500

Blaine and Jeff: 

Just so it is said. 

BGP mechanisms or operational changes are in the IDR charter. 
Cross-functional items start in one working group and move to the other.

The originating working group is responsible for clearly defining the
requirements for the mechanisms. 

Sue Hares

-----Original Message-----
From: Jeffrey Haas 
Sent: Thursday, January 20, 2005 4:25 PM
To: Blaine Christian
Cc: [email-masked]; Stephen Kent
Subject: Re: [RPSEC] proposed message to the IESG

Blaine,

On Thu, Jan 20, 2005 at 03:58:53PM -0500, Blaine Christian wrote:
> 1. Draft not in the charter:  The premise for this argument appears to
be
> that by including requirements to cope with current operational
practices
> the draft falls under the wrong working group.  I read the charter and
it
> does not state that operational requirements are verboten.  The draft
seems
> to fall under the charter.

I do not pretend to speak for Yakov or Sue (who is on this list) or the
IDR working group.  IMO, defining the security requirements for BGP
is within the rpsec charter.  Defining recommended protocol or
operational
changes to BGP is also within charter.  

Defining the actual protocol level changes to BGP is at best
a cross-functional work item.  IMO, most of the work would be done in
IDR
and it would be rpsec's responsibility to say "this doesn't do what
we wanted".

> 2. BGP spec not followed: 

I'll defer this to the other parties and try to stick to specifics since
that fits the ADHD way I'm following this group at the moment.

> If so, it is
> my perception that all transitive attributes MUST be protected via the
> security mechanism.

Must they?
What is to be protected?
What does "protect" mean?

I think these two last questions form the core of our arguments.
However,
it is difficult to articulate each of these without delving into
solutions.

> My assumption, and I should be corrected if I am wrong,
> was that MD5/IPSec type mechanisms would be sufficient for attributes
that
> are usually non-transitive (communities/localpref etc...).

Communities are transitive. :-)

> Blaine

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: [email-masked]
Date: Wed, 26 Jan 2005 17:26:37 +0000

> Communities are transitive. :-)

	except in cases where multi-hop BGP is used, the "normal"
	case peering session is on a p2p link (altho p2p links these
	days are not nearly as physically protected as in the dim past)
	and so tapping the link to expose BGP  data was harder. 
	MD5 is a reasonable tool in such cases 

	also - while communities are transitive, trust is not.

--bill