Subject: Re: [RPSEC] issue: coverage

From: Sandy Murphy <[email-masked]>
Date: Thu, 10 Mar 2005 07:53:22 -0500 (EST)

>- I would expect protests at the IESG/AD level that we are excluding IPv6; my
>impresssion is that such behaviour is politically incorrect.

Hm.  You know, I don't know that the requirements as written would
not apply to IPv6 as well.  So we may be covered there, anyway.

>- I would expect operator protests at the exclusion of communities (eg RFC 3765,>RFC 1997) since I believe they are often used to effect policy of the kind that
>has been much discussed on this list.

Yep.  I believe that the requirements as written do not address protection
of communities, as it says that all other (than AS_PATH) are of local
concern only.  As I noted in the "issue: attributes" thread, this may not
be true.  And frankly, I don't quite know what to do about communities.
Some are transitive, some are mutable, those that are transitive AND
mutable would be tough to secure, etc.

--Sandy

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

---

From: Russ White <[email-masked]>
Date: Thu, 10 Mar 2005 13:27:17 -0500 (Eastern Standard Time)

> Hm.  You know, I don't know that the requirements as written would not 
> apply to IPv6 as well.  So we may be covered there, anyway.
>
>> - I would expect operator protests at the exclusion of communities (eg 
>> RFC 3765,>RFC 1997) since I believe they are often used to effect policy 
>> of the kind that has been much discussed on this list.
>
> Yep.  I believe that the requirements as written do not address 
> protection of communities, as it says that all other (than AS_PATH) are 
> of local concern only.  As I noted in the "issue: attributes" thread, 
> this may not be true.  And frankly, I don't quite know what to do about 
> communities. Some are transitive, some are mutable, those that are 
> transitive AND mutable would be tough to secure, etc.

It's actually worse than this, I'm afraid.... :-(

So, I was thinking about the problems you raised in Minneapolis, and 
specifically communities and the next hop. I don't actually how you could 
go about protecting either of these. I'll try and deal with the next hop 
problem in another email, since this one is too long already for most 
people to read! :-)

Suppose you take the simple case: NO_EXPORT, in this little network:

B---C---D
|   |
A---A'

Now, suppose:

-- A advertises some route to B.

-- B and C are under contract to A to transit traffic from A to A', but A 
doesn't even want D to know about this relationship, for whatever reason.

Now, suppose A marks the route it advertises to B with a community so B 
marks the route NO_EXPORT towards C. But, through some problem, or 
malicious intent, C actually advertises the route to D.

Now, suppose we postulate some way to "secure" communities so C actually 
can't strip the NO_EXPORT community off. What should D take from receiving 
an update on which B has marked NO_EXPORT? That it shouldn't have received 
the update, and should therefore discard it? Isn't that a bit like the 
useless signatures on emails saying: "If you don't think you should have 
received this information, please discard it without receiving it," which 
happens to be conveniently placed at the end of the email??

Essentially, all of A's trust is in B and C to do the right thing. The 
actual routing information isn't encrypted (and couldn't be, in order to be 
useful), so there's no way to prevent someone from gaining knowledge of the 
actual available routes through just about any means. BGP isn't designed to 
provide secrecy of routing information, just to provide a set of loop free 
paths through the network, of which one is chosen for local policy 
reasons.... The enforcement falls to A, through it's contract with B and C, 
if it even discovers the problem existed in the first place.

Another, even simpler, problem. RFC1998 provides a way for an AS to modify 
a peer's local preference through the use of communities. Now, suppose A 
and B are peers that have agreed, by contract, to honor these sorts of 
communities. A sends B some route with a community modifying B's local 
preference. B now needs to not only know A actually injected this 
information, but also it must be able to strip this information off the 
route, so those communities aren't passed on to its peers.... This is a 
very big tangle.... RFC3765, concepts of AS Path hop counts, and other 
things, all add to this, making it even more complicated to sort out what 
should be done here.

Another part of the big tangle with policy is that we are diving into the 
traffic flow problem, again. A routing system provides loop free paths, and 
doesn't gaurentee traffic sent to the next hop advertising a given loop 
free path will actually follow the loop free path advertised. Once you dive 
into policy, you open up entire vistas of traffic flow problems I'm not 
certain we want to get in to (?).

The simplest thing here might be to consider adding a bit more on policy, 
but severely limiting the discussion to some very basic considerations. For 
instance, it might be useful to state:

-- Any proposed solution should allow an operator to express a specific 
autonomous system is not to be transited when forwarding traffic to a 
specific destination. This requirement is made with the assumption that 
there is no viable way to prove traffic will, or will not, flow along a 
specific path in an internetwork, but rather is an expression of common 
policy mechanisms in use today.

There are a number of ways you could provide for this requirement, if the 
system designer chose to do so. And, it would avoid all the pitfalls of 
actually trying to "secure" communities, by stating what the communities 
tend to try and get at in terms of policy.

Thoughts?

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: "Tom Petch" <[email-masked]>
Date: Thu, 10 Mar 2005 21:40:15 +0100

What I am skirting around is that while BGP for IPv6 is similar in principle to
that for IPv4, it is not the same.  Perforce, it brings in Multi-Protocol and
Capabilities, it brings in different packet formats, extra attributes, some new
(still being discussed) concepts (address architecture).  So including it (but
not some of the other BGP options) means on the one hand, being precise about
just which pieces of eg Multi-Protocol are included and on the other, making
sure that all the wording covers two different sets of technical details. (As
yet, I have put off reading the document with an IPv6 mindset to see if
changes would be needed - there may be no changes but I think we would have to
keep on remembering IPv6 is different in detail)).

Can be done, but more easily done if we agree to do it from the start rather
than try to retrofit it later.

Tom Petch

----- Original Message -----
From: "Sandy Murphy" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, March 10, 2005 1:53 PM
Subject: Re: [RPSEC] issue: coverage

> >- I would expect operator protests at the exclusion of communities (eg RFC
3765,>RFC 1997) since I believe they are often used to effect policy of the kind
that

---

From: Russ White <[email-masked]>
Date: Thu, 10 Mar 2005 17:52:33 -0500 (Eastern Standard Time)

> What I am skirting around is that while BGP for IPv6 is similar in 
> principle to that for IPv4, it is not the same.  Perforce, it brings in 
> Multi-Protocol

That would be AFI/SAFI stuff, and should already be covered under what 
we're doing.... (?)

> and Capabilities,

Capabilities are between peers, and would be covered under any given system 
designed to protect peering sessions, I think.

> it brings in different packet formats,

Packet formats are probably outside our scope....

> extra attributes,

Attributes are already under discussion. Can you tell us what new ones 
would be added? I've not seen any of the drafts, etc.

> some new (still being discussed) concepts (address architecture).

I'm not certain address architecture is relevant here, either.... (?)

> So including it (but not some of the other BGP options) means on the one 
> hand, being precise about just which pieces of eg Multi-Protocol are 
> included and on the other, making sure that all the wording covers two 
> different sets of technical details. (As yet, I have put off reading the 
> document with an IPv6 mindset to see if changes would be needed - there 
> may be no changes but I think we would have to keep on remembering IPv6 
> is different in detail)).

It would be useful to know what changes you think would be required...

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Mar 2005 22:15:13 -0500

At 1:27 PM -0500 3/10/05, Russ White wrote:
>>>- I would expect operator protests at the exclusion of communities 
>>>(eg RFC 3765,>RFC 1997) since I believe they are often used to 
>>>effect policy of the kind that has been much discussed on this 
>>>list.
>>
>>protection of communities, as it says that all other (than AS_PATH) 
>>are of local concern only.  As I noted in the "issue: attributes" 
>>thread, this may not be true.  And frankly, I don't quite know what 
>>to do about communities. Some are transitive, some are mutable, 
>>those that are transitive AND mutable would be tough to secure, etc.
>
>specifically communities and the next hop. I don't actually how you 
>could go about protecting either of these. I'll try and deal with 
>the next hop problem in another email, since this one is too long 
>already for most people to read! :-)
>
>-- B and C are under contract to A to transit traffic from A to A', 
>but A doesn't even want D to know about this relationship, for 
>whatever reason.
>
>Now, suppose A marks the route it advertises to B with a community 
>so B marks the route NO_EXPORT towards C. But, through some problem, 
>or malicious intent, C actually advertises the route to D.
>
>Now, suppose we postulate some way to "secure" communities so C 
>actually can't strip the NO_EXPORT community off. What should D take 
>from receiving an update on which B has marked NO_EXPORT? That it 
>shouldn't have received the update, and should therefore discard it? 
>Isn't that a bit like the useless signatures on emails saying: "If 
>you don't think you should have received this information, please 
>discard it without receiving it," which happens to be conveniently 
>placed at the end of the email??

No, it isn't analogous.  if one believes the goal of securing BGP is 
to provide each AS with info to enable the AS to determine if a 
received advertisement is legitimate, then the facility to which you 
allude does that.  If D chooses to ignore the fact that it received 
an advertisement that was not destined for it, then what's the 
downside for anyone but D? It could always try to forward traffic 
that it was not solicited to forward, whether it receives an 
advertisement or not. The fact that it received an advertisement that 
it knows it was not supposed to receive allows D to make the right 
choice, i.e., ignore the advertisement, but does not compel D to do 
so.  We can't compel any AS to do anything,

>
>Essentially, all of A's trust is in B and C to do the right thing. 
>The actual routing information isn't encrypted (and couldn't be, in 
>order to be useful), so there's no way to prevent someone from 
>gaining knowledge of the actual available routes through just about 
>any means. BGP isn't designed to provide secrecy of routing 
>information, just to provide a set of loop free paths through the 
>network, of which one is chosen for local policy reasons.... The 
>enforcement falls to A, through it's contract with B and C, if it 
>even discovers the problem existed in the first place.

as noted above, this is not about preventing D from knowing anything. 
It is about giving D authentic info to enable it to make the right 
decision. Giving D the right info allows it to avoid making a 
mistake, as a result of an error or malicious intent by B.

Steve

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 11 Mar 2005 10:18:14 +0100

I am nervous about being too specific about IPv6 because it is an area where I
lurk rather than work:-) but as I see it:-

RFC2858 defines Multiprotocol; from 2000, I see no activity to update it nor any
need (unless IPv6 want to add anycast).  It defines attributes 14 and 15 for
other protocols NLRI, reachable and unreachable respectively

RFC2545 defines IPv6 use thereof; from 1999, again I see no activity to update
it but IPv6 has changed a lot since then (address architecture, role of routers)
so it will need an update but only when IPv6 settles down again.  As it stands,
it preserves a 32 bit router id, allows IPv4 or IPv6 transport (think transport
level security and that the TCP IP address can be IPv6 while router id is IPv4),
uses attributes 14 and 15 and allows multiple next hops (link
local, global unicast).  As I said, different in technical detail.

I know of no I-Ds in this area (I am on ipv6 and idr lists).

So any reference to attributes or next hops sets my IPv6 antenna twitching.

Tom Petch

---

From: Francis Dupont <[email-masked]>
Date: Fri, 11 Mar 2005 16:45:00 +0100

In your previous mail you wrote:

   RFC2858 defines Multiprotocol

=> note this is heavily used and in general not for IPv6 (:-).
   
   RFC2545 defines IPv6 use thereof

=> there were some proposals for link-local addresses only in special cases
but IMHO in the context of RPSEC global addresses are required... So
this IPv6 feature (narrow scope addresses) can be ignored and general
considerations for IPv4 apply to IPv6 directly.

=> I believe the proposals were phased out some years ago and as
interconnection points (GIXs) can get dedicated global prefixes
the main reason of these proposals no more exists too...

=> as far as I know (and as one of the RFC 2545 authors I should be informed)
there is no planned change to RFC 2545 for its progress to DS.

Regards

[email-masked]

PS: BTW to make specifications applicable to IPv4 and IPv6 is a good idea
and in this case I can't see a reason to drop/forget IPv6...