Subject: re: [Idr] comment on draft-ietf-idr-as4bytes-10.txt

From: Geoff Huston <[email-masked]>
Date: Tue, 23 Aug 2005 10:12:58 +1000

Paul wrote

 > I am curious why you chose to overload the syntax of the
 > existing AS_PATH attribute according to whether two peers are or > are 
not 4byte ASN capable?
 >
 > My primary concern of this aspect of the draft is that it will
 > become impossible to parse AS_PATH without external reference.
 > This would have implications for protocol analysers which are
 > asked to observe a BGP session in mid-flow (they'll have no way
 > of parsing AS_PATH) and also for 'old' analysers which are asked
 > to observe a session between new peers (at best, such an
 > analyser would produce syntactically incorrect results), as well
 > as implications for modularity of code in BGP implementations.
 >
 > Would it maybe be better to leave the syntax of AS_PATH alone
 > and simply mandate NEW_AS_PATH be used for 4byte ASN and AS_PATH
 > for 2byte (you could even make AS_PATH optional and NEW_AS_PATH > 
well-known between new speakers, so that AS_PATH slowly dies out
 > during the transition period)?

So lets understand precisely what is going on here:

1 - there is no problem identified in this posting when looking at the 
situation of a BGP peering session. The BGP speaker knows its own state 
(NEW or OLD) and establishes the state of its peer at the time of the OPEN, 
and this information is used to guide what the BGP speaker will place in 
the AS_PATH and how it will interpret what is in the received AS_PATH. So 
if you are implementing the 4 byte draft as a BGP speaker than this posting 
does not identify any issues associated with the specification itself. At 
all times the BGP speaker can deterministically interpret the AS-PATH 
attribute.

2 - If a BGP speaker outputs an update log or a dump, then there is still 
no problem here - the BGP speaker presumably has an internal representation 
of AS's that are either 2-byte (OLD) or 4-byte) NEW (although thats an 
implementation detail beyond the scope of the specification) and presumably 
will consistently report according to the internal format. Again as far as 
I can see this posting does not identify any issues associated with the 
specification itself.

3 - So what I see is that a) if you chose NOT to encrypt your BGP session 
and b) if you allow eavesdroppers into the BGP session and c) the 
eavesdropper is not able to capture the entire BGP session, then Paul is 
observing that there is  the potential for confusion on the part of the 
eavesdropper when interpreting the BGP update conversation as the update 
does not contain enough information to decode the AS PATH as either a 
sequence of 2 byte or a sequence of 4 byte values. Paul has then proposed 
changes to the draft in the light of this

I would question the underlying premises of this motivation for this change 
- under what circumstances would I be deploying BGP eavesdroppers, as 
distinct from getting the BGP speakers themselves to provide the session 
information I'm after? And if its my eavesdropper then surely I can 
configure the eavesdropper to let it know how to interpret what its seeing. 
Or maybe set up a common community attribute to trigger my eavesdropper to 
interpret the AS_PATH a certain way? So as I see it what Paul is advocating 
is making interpretation of BGP sessions on the wire easier for third party 
eaverdroppers to perform in a 2byte / 4byte world.  The question in my mind 
in thinking about this motivation is why would I necessarily want to make 
eavesdropping on the wire by third parties easier to undertake?

In other words what Paul interprets as a problem in the specification that 
merits some form of correction I would interpret as a positive attribute of 
the specification and I would advocate leaving it as is.

By the way I am _really_ pleased to learn of work on an implementation of 
this spec in another BGP implementation - this is very heartening to hear!

regards,

    Geoff  Huston

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

---

From: Paul Jakma <[email-masked]>
Date: Tue, 23 Aug 2005 02:02:33 +0100 (IST)

On Tue, 23 Aug 2005, Geoff Huston wrote:

> / 4byte world.  The question in my mind in thinking about this 
> motivation is why would I necessarily want to make eavesdropping on 
> the wire by third parties easier to undertake?

First let me note that most BGP speakers which secure their sessions 
do so to /authenticate/ the sessions, they typically do not 
additionally encrypt the data for confidentiality (ie a 'secured' BGP 
session is still monitorable, nearly always).

Reasons to want to observe a BGP stream:

- unintrusive collection of statistics
- IDS
- operational debugging

I might be strange, but fact that many switches offer 'port mirror' 
capabilities makes me think I might not be /that/ strange in this 
respect generally, don't know about BGP though.

> In other words what Paul interprets as a problem in the 
> specification that merits some form of correction I would interpret 
> as a positive attribute of the specification and I would advocate 
> leaving it as is.

There is no positive attribute though. BGP sessions typically want 
authentication, not confidentiality - your point doesn't apply.

Also, you gave a presentation at GRO on need for BGP security 
(path/prefix attestation of some kind particularly).

However, with the current draft, it may defeat any kind of mechanism 
that attempts to provide signatures of an AS_PATH. The current draft 
provides for the AS_PATH to be rewritten when:

- A NEW speaker passes a route with an OLD path to a NEW speaker

- A NEW speaker must send a route with a 4-octet AS_PATH to an OLD
   speaker

This affects the transition period, even if no ASN's are using 
4-octet numbers yet.

So any mechanisms that want to get involved in signing AS_PATH's are 
going to have learn about when an AS_PATH is not what an AS_PATH used 
to be (and when an AS_PATH that isn't then becomes what it was, and 
so on).

> By the way I am _really_ pleased to learn of work on an 
> implementation of this spec in another BGP implementation - this is 
> very heartening to hear!

I intend to complete implementation of 4bytes-ASN, however I think 
it's a shame we have to leave this nit in the draft.

Note that I also think the way this draft is currently is not 
conducive to implementation. Eg, our (Quagga) current aspath 
constructing/deconstructing/updating/checking code has 0 notion of 
what a peer is:

 	$ grep 'struct peer' bgp_aspath.c
 	$

Sadly, that nice modularity (ok, it's not the cleanest code, but at 
least it /was/ modular), may have to disappear to some extent.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
It is the wisdom of crocodiles, that shed tears when they would devour.
 		-- Francis Bacon

---

From: Paul Jakma <[email-masked]>
Date: Tue, 23 Aug 2005 02:25:00 +0100 (IST)

On Tue, 23 Aug 2005, Geoff Huston wrote:

> merits some form of correction I would interpret as a positive 
> attribute of the specification and I would advocate leaving it as 
> is.

Straw poll:

On the question of the current as4bytes IDR working document 
specifying that the syntax an existing well-known attribute be 
overriden by an OPEN capability:

- anyone in favour of leaving the draft as is in this respect?

(Enke, Geoff, ....?)

- anyone in favour of changing the draft to use the new attribute
   (NEW_AS_PATH) which is specified by the draft?

(paul, ....?)

I've floated my balloon, if it goes nowhere, or in wrong direction 
I'll leave it go :)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
PnPBIOS is a PC specific affliction. Other platforms have more elegantly
designed but even buggier solutions

 	- Alan Cox on linux-kernel

---

From: Geoff Huston <[email-masked]>
Date: Tue, 23 Aug 2005 12:04:52 +1000

>However, with the current draft, it may defeat any kind of mechanism that 
>attempts to provide signatures of an AS_PATH. The current draft provides 
>for the AS_PATH to be rewritten when:
>

But section 5.1 of the draft says that the NEW speaker MUST pass AS_PATH to 
the NEW peer as
4-bytes - I'm not sure I understand the reference to "OLD path" in this 
context, so I may need some help here in picking up your point.

>- A NEW speaker must send a route with a 4-octet AS_PATH to an OLD

As the draft points out there are two cases here - "mappable" AS numbers, 
where the
4-byte AS value can be converted to a 2-byte by stripping off the high 
order 16 butes and
the "un-mappable" AS numbers - where the transition 2-Byte AS value is 
placed in the AS-PATH and the original 4-byte value is used in NEW_AS_PATH. 
Again I'm not sure I follow your line of argument here.

>This affects the transition period, even if no ASN's are using 4-octet 
>numbers yet.
>
>So any mechanisms that want to get involved in signing AS_PATH's are going 
>to have learn about when an AS_PATH is not what an AS_PATH used to be (and 
>when an AS_PATH that isn't then becomes what it was, and so on).

As I've noted above, I'm not precisely sure what point you are driving at 
here (that may be my fault - sorry) - if your point is that singing the AS 
Path is a topic that is being actively studied now and this is one more 
addition to their agenda for consideration, then I'd agree, as would the 
RPSEC working group I guess. If you are saying that there is a solution out 
there for signing AS paths and this disrupts such a solution then I'm not 
sure I follow you, as I'm not sure that I see such AS Path signing 
solutions in place as yet.

If you are addressing the actual resource certificates then its my (crude) 
understanding that the mappable AS would be described as 2 octet values and 
the remainder of the 4-byte AS set would be described as 4 octet values. 
Again I'm pretty sure that I'm not of the same page as you here, and I 
don't understand your point - sorry.

regards,

    Geoff

---

From: Paul Jakma <[email-masked]>
Date: Tue, 23 Aug 2005 03:35:56 +0100 (IST)

> But section 5.1 of the draft says that the NEW speaker MUST pass 
> AS_PATH to the NEW peer as 4-bytes - I'm not sure I understand the 
> reference to "OLD path" in this context, so I may need some help 
> here in picking up your point.

The draft provides for AS_PATH being rewritten. In the above, the 
'OLD' path would come from an OLD speaker with a 2-octet AS_PATH. 
That would, when sent to a NEW peer, be rewritten into a 4-octet 
AS_PATH.

That potentially could invalidate any signatures made directly of 
information in the AS_PATH.

> As I've noted above, I'm not precisely sure what point you are 
> driving at here (that may be my fault - sorry)

Probably mine. ;) Hopefully above makes it clearer.

> - if your point is that singing the AS Path is a topic that is 
> being actively studied now and this is one more addition to their 
> agenda for consideration, then I'd agree, as would the RPSEC 
> working group I guess.

Right.

However, thinking again, An obvious way to deal with it would be for 
any such solution to not sign segment data directly, but sign an 
abstracted version of path-derived data that could be reconstructed 
from AS_PATH.

> If you are saying that there is a solution out there for signing AS 
> paths and this disrupts such a solution then I'm not sure I follow 
> you, as I'm not sure that I see such AS Path signing solutions in 
> place as yet.

Ah, no. I wasn't trying to suggest a solution existed yet ;). Sorry. 
:)

> If you are addressing the actual resource certificates then its my 
> (crude) understanding that the mappable AS would be described as 2 
> octet values and the remainder of the 4-byte AS set would be 
> described as 4 octet values.

Ok, that'd work fine likely. And my concern is withdrawn.

> Again I'm pretty sure that I'm not of the same page as you here, 
> and I don't understand your point - sorry.

Given your paragraph immediately previous, it's therefore likely not 
a problem at all - never mind.

Which leaves the BGP analyser/observer issue as only significant 
practical issue against the draft (I think even the drafts authors 
have conceded btw that it's a minus point. Not a plus point: 
ambiguity != security ;). However the authors obviously do not agree 
with me that the extent of this issue is worth worrying about.).

I'd like to have the draft changed. IMHO, there isn't really that 
much of an installed base or even implementation to justify leaving 
this nit in the draft.

But that's my opinion, I'll rest my case.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Hate the sin and love the sinner.
 		-- Mahatma Gandhi

---

From: Tulip Rasputin <[email-masked]>
Date: Tue, 23 Aug 2005 01:05:15 -0400 (EDT)

I am concerned for the applications that are asked to observe a BGP stream mid flow.

It would suffice if there are ways with which such applications could, by looking at the update
messages determine, the kind of ASN(s) used in the sessions or carried in the path attributes
without having parsed the OPEN message.

> - anyone in favour of leaving the draft as is in this respect?

The above point leaves me a little uncomfortable.

>    (NEW_AS_PATH) which is specified by the draft?

With this proposal, such proposals would atleast parse the AS_PATH attribute. This would not yield
correct results but would atleast give some meaningful result.

- Tulip

		
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca

---

From: Tulip Rasputin <[email-masked]>
Date: Tue, 23 Aug 2005 01:43:42 -0400 (EDT)

> 
> With this proposal, such proposals 
                           ^^^^^^^^^
I meant "applications"

> would atleast parse the AS_PATH attribute. This would not
> yield

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 23 Aug 2005 07:47:50 -0700

Paul,

[clipped...]

> with me that the extent of this issue is worth worrying about.).

On the subject of the BGP analyser/observer issue we need to
look at two aspects of this issue:

1. Is it possible to parse the BGP stream into messages/attributes
without capturing the OPEN message by the analyser/observer ?

2. If the answer to 1 is "yes", then is it possible to understanding
the information of these messages/attributes without capturing the
OPEN message (and specifically the Capability Advertisement part
of it) by the analyser/observer ?

Yakov.

---

From: Paul Jakma <[email-masked]>
Date: Tue, 23 Aug 2005 16:24:06 +0100 (IST)

> without capturing the OPEN message by the analyser/observer ?

Into messages and attributes, yes.

> of it) by the analyser/observer ?

For the AS_PATH: deterministically/reliably, no.

A hopefully fair analysis:

In practice, in bulk of cases it likely would be posssible to figure 
out which encoding is used; parsing with either 2 or 4 octet encoding 
would quickly show one encoding to be implausible (eg a byte which 
should be length but which claims a segment extends past end of the 
data, or because you encounter 0x00 0x00 - which could only be valid 
for a 4-octet encoded AS_PATH, and will be common during the 
transition period. One hopes OLD speakers quickly would be deprecated 
once the first 4-octet ASN is used. Though, you have a very long 
comfort 'zone', at least for as long as ASN-1 is not reused by Level3 
or whoever owns it now.).

However, there will be AS_PATHs which will, syntactically, seem 
plausible for either encoding. Those will require further inspection 
(eg by checking which ASNs actually are assigned by IANA or even 
RIRs).

Further, you won't be able to discriminate easily between whether an 
AS_PATH is incorrectly generated or corrupted and case of having used 
wrong ASN octet size to parse it.

(Geoff, I guess, would be quick to point out that this would not be a 
problem for the BGP speakers concerned - they know their state.)

If we could reclaim ASN 1 (Level-3 stopped using it I think) and 
reserve it, and hence guarantee the byte sequences "0x00 0x01" and 
"0x00 0x00" would /reliably/ indicate 4-byte encoding, then we could 
(i think) reliably distinguish between encodings, until the first 
"0x00 0x02 .. .." ASN is handed out - which wouldn't be for 20+ 
years, one would imagine.

So there's another possible solution if you really don't want to 
change the draft, but do want to preserve ability to parse AS_PATH 
without additional context:

Reclaim and reserve ASN 1.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Somewhere, just out of sight, the unicorns are gathering.

---

From: Paul Jakma <[email-masked]>
Date: Tue, 23 Aug 2005 16:35:38 +0100 (IST)

> Reclaim and reserve ASN 1.

This would allow only updated analysers to work reliably, but I'd 
settle for that.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
One way to stop a runaway horse is to bet on him.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 23 Aug 2005 09:13:21 -0700

Paul,

> For the AS_PATH: deterministically/reliably, no.

Is it "no" just for the AS_PATH attribute, or for other attributes
as well ? In other words, does the issue you brining up specific
to the AS_PATH attribute, or not ?

Yakov.

---

From: Paul Jakma <[email-masked]>
Date: Tue, 23 Aug 2005 17:18:43 +0100 (IST)

On Tue, 23 Aug 2005, Yakov Rekhter wrote:

> as well ? In other words, does the issue you brining up specific to 
> the AS_PATH attribute, or not ?

It is "no" only for AS_PATH. The issue is specific to the proposed 
changes to AS_PATH.

AGGREGATOR is overloaded too in the draft, but can easily be 
differentiated based on the attribute length.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Meekness is uncommon patience in planning a worthwhile revenge.

---

From: Enke Chen <[email-masked]>
Date: Tue, 23 Aug 2005 16:21:58 -0700

Hi, Paul:

[snip]

> transition period.

The numbers 0x00 0x00 will be common even after the transition as the 
existing 2-byte AS number will be encoded as 0:xx where the first two 
bytes are zero.

> One hopes OLD speakers quickly would be deprecated once the first 
> 4-octet ASN is used. Though, you have a very long comfort 'zone', at 
> least for as long as ASN-1 is not reused by Level3 or whoever owns it 
> now.).
> (eg by checking which ASNs actually are assigned by IANA or even RIRs).
>
> "0x00 0x02 .. .." ASN is handed out - which wouldn't be for 20+ years, 
> one would imagine.

I just checked Dave Meyer's route-view. AS 1 is still in the routing table.

However, one interesting stats from that route-view: it seems that 99.9% 
of the as-path entries consists of just AS_SEQUENCE. For these as-path 
entries, we can easily tell 2-byte vs 4-byte from the attribute length 
and seglen (which is the number of AS numbers):

attribute_len = segtype (1 byte) + seglen (1 byte) + as_count * AS_SIZE

where as_count is the value in seglen field.

This equation can only be true with AS_SIZE = 2, or 4, but not both.

So there are several options for these "standalone" tools:

1) A user configurable knob: 100% accuracy.

2) Use the attribute length and seglen: >99.9% accuracy.

3) Use the existence of "0x00 0x00": 100% accuracy when mappable AS exists.

4) Combine #2 and #3.

5) Combine #2 and #3, and then #1 as last resort.

Do we still need more options :-)

Regards,

-- Enke

---

From: Paul Jakma <[email-masked]>
Date: Wed, 24 Aug 2005 01:01:49 +0100 (IST)

On Tue, 23 Aug 2005, Enke Chen wrote:

> The numbers 0x00 0x00 will be common even after the transition as 
> the existing 2-byte AS number will be encoded as 0:xx where the 
> first two bytes are zero.

Yep - 0x00 0x00 will be very common and an immediate indicator of '4 
byte' encoding, if found on a 2 octet boundary (it's not a valid AS 
segment header, nor is 0x00 0x01). 0 is not a valid ASN I'm 
reasonably sure (though, havn't checked), so can't be 2-octet.

Course, latching on 0x00 0x00 will not work for AS-Path's which 
contain only 'new' ASNs, Hence we'd need 0x00 0x01 to be reserved in 
2-octet space.

> I just checked Dave Meyer's route-view. AS 1 is still in the routing table.

Ah, oh dear. Who originates it and what? Level3 had deprecated it a 
good while ago I thought, and were slowly decommisioning it.

> However, one interesting stats from that route-view: it seems that 
> 99.9% of the as-path entries consists of just AS_SEQUENCE. For 
> these as-path entries, we can easily tell 2-byte vs 4-byte from the 
> attribute length and seglen (which is the number of AS numbers):

Sadly, not quite.

> where as_count is the value in seglen field.

This assumes there is only one segment though, Eg, try:

0x02 0x03 0x00 0x19 0x01 0x56 0x00 0x0c 0x02 0x02 0x00 0x41 0xc9 0x89

Is that a single AS_SEQUENCE segment with 3 4-octet ASN's, or is it 
two 2-octet segments after each other, first with 3 ASN's, the second 
with two?

> This equation can only be true with AS_SIZE = 2, or 4, but not both.

How did you get the data from route-view? You need to look at the raw 
data to be sure that 99.9% of paths consist of /one/ AS_SEQUENCE ;). 
(I'll admit such constructions would be highly odd and unusual though 
- but I have no figures).

Also, route-views can be an odd view of the internet. The oddness may 
be hidden from it, or simply swamped by many many multiple copies of 
more 'normal' AS_PATHs.

> 2) Use the attribute length and seglen: >99.9% accuracy.

If you assume single segments are 99.9%, sure - and then that is (i 
/think/) 99.9*99.9 = 98.9% probability.

Each seperate corner case lowers the probability.

> 3) Use the existence of "0x00 0x00": 100% accuracy when mappable AS exists.

When, yes.

> Do we still need more options :-)

It's a lot of heuristics to put together when the draft really just 
could say:

 	If (attribute code == NEW_AS_PATH)
             || (attribute code == NEW_AGGREGATOR)
 	  sizeof (ASN): 4 octets
         else
 	  sizeof (ASN): 2 octets

And we'd be covered 100% without resorting to 99% heuristics.

But hey. ;)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Moderation is a fatal thing.  Nothing succeeds like excess.
 		-- Oscar Wilde

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 24 Aug 2005 01:23:09 -0400

> - anyone in favour of leaving the draft as is in this respect?

Yes.  Leave as is.  Geoff is right.  As a provider I only had a need
to snoop on a BGP session when the BGP implementation was broken and I
was also the one maintaining the code back when we were still running
BGP2 and BGP3 code.  And we did about as much statistics collection of
BGP and other stats collection based on traffic sampling as anyone.

> I've floated my balloon, if it goes nowhere, or in wrong direction 

Curtis

---

From: Paul Jakma <[email-masked]>
Date: Fri, 26 Aug 2005 17:32:38 +0100 (IST)

On Tue, 23 Aug 2005, Paul Jakma wrote:

> "0x00 0x00"

Actually given AS1 isn't possible: any existing unused AS number will 
do, eg, AS_TRANS ;). Just have IANA assign 4-octets ASNs from the 
23456:x block at first.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Q:	What's a light-year?
A:	One-third less calories than a regular year.