Subject: Re: [Sidrops] On validating AS paths

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 1 Jul 2019 15:47:24 +0200

Hi Alexander,

On 26 Jun 2019, at 18:39, Alexander Azimov <[email-masked]> wrote:

> I assume that after talking with Job Snijders you are aware of ASPA drafts.

Yes.

> They cover the detection of anomalies (invalid ASPATHs) that are received from customers and peers + specify RPKI object exactly for customer-to-provider pairs.

Yes. Note that in my previous message I was specifically addressing validating the _entire_ path, while ASPA only concerns itself with validating the "up" part of the path, where the only valid relationships are provider-customer and sibling-sibling.

Of course once we can validate the entire path, we can by definition also validate any subset.

> And of course, a path //^\ (in your notation) received from customer or peer is invalid. But I assume that you also had this in mind.

Yes, this is a valid full path but if you get it from a peer then it's actually \//^\ (from a customer) or ^//^\ (from a peer) so that's not valid.

> What I find curious in your proposal is the goal to extend the detection of invalid paths for prefixes that are received from providers.
> I was also considering this option, but it will not work with c2p database only. The problem occurs with siblings. 

Basically, a sibling relationship occurs when there is a customer - provider relationship in both directions. (As per Gao/Rexford there is the additional constraint that these relationships have the lowest local preference, but that's probably not relevant for path validation.)

So for the "up" part of the path we can use your algorithm for validation. Then for the "down" part of the path (i.e., the part that your customers see when they get updates from you, not covered in your draft) the same procedure will work as long as we look at customer -> provider relationships rather than provider <- customer relationships. I.e.:

900 800 200 100 i

You care 800. You see a valid 200 \ 100 relationship. You know that 800 ^ 200 because you are 800.

900 sees a valid 900 / 800 relationship. 900 sees 800 ? 200 based on the C2P database as there is no C2P relationship between 800 and 200 in either direction. But as per my previous message, any path with exactly one unknown relationship between a valid up part and a valid down part is still valid so the entire path is valid.

> Take a look at the next example:
> a1 p2p a2 c2c a3 p2c a4 (p2p for peering, c2c for sibling, a4 is checking ASPATH)

Do you mean: a1 ^ a2 - a3 \ a4

Note that you are using the opposite order to how BGP AS paths are normally shown, with the origin on the right. But as valley-freeness doesn't depend on the direction, I'll ignore that here.

a1 ^ a2 - a3 \ a4 = /-^ is a valid path, there are no valleys.

> If records for a1 exists (so we know that a2 isn't in the set of providers of a1), (a2, a3) records exist, but (a3, a2) doesn't, the outcome of verification procedure at a4 will be invalid. 

So a2 / a3 but not a2 \ a3 and thus not a2 - a3.

This means the path a1 ^ a2 - a3 \ a4 is actually:

a1 ^ a2 / a3 \ a4

^/\ is not a valid path. So a3 has to register its C2P relationship with a2.

> Maybe it can be fixed by adding a sibling flag to the c2p record, but at the moment I'm not sure about security consequences.

In the draft you mention that it's important that the customer can claim the relationship and not the provider. So I would be hesitant to have a S2S relationship record is that would either be too easy to claim (if one sibling can do it) or complex to implement (only valid when both siblings claim the relationship).

> And to follow up my previous email, if we have a network with malicious intent that would hijack/disaggregate prefixes + create a 'virtual peering link' between it and victim ASN, its customers will not able to detect it anyway since it will look like a valid path: '-\'.

You mean a virtual sibling link? No, we certainly don't want that to be possible.

Greetings,

Iljitsch

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 1 Jul 2019 14:27:27 -0400

> Yes. Note that in my previous message I was specifically addressing validating the _entire_ path, while ASPA only concerns itself with validating the "up" part of the path, where the only valid rel…

isn't this the point of 'bgpsec'? meaning: "you can do this when you
see bgpsec signed paths from bgp peers"

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 1 Jul 2019 21:33:50 +0200

> see bgpsec signed paths from bgp peers"

Unless I'm missing something (I don't think so, but it's a complicated system so maybe I am), BGPsec gives you two things:

1. Signatures on all the hops in the path, so you can check that the BGP update did traverse those routers/ASes and no others

2. A signature from any given AS in the path on the next hop AS, so you can determine that the update was propagated as intended by each previous hop

These features are orthogonal to the issue of route leaks as defined as types 1 - 4 in RFC 7908: these break the valley-freeness property that we expect to see in valid paths, but as they're accidental, they don't do anything that BGPsec doesn't like.

Note that the second feature seems impressive until you realize that it's a feature of the internet that ALL BGP updates reach ALL ASes, and that the source only gets to select the next hop AS, but that any ASes after that can apply any mistaken or malicious policy that they see fit.

Of course if it turns out that some of these route leaks are NOT accidental and when we manage to stop them by validating the AS path in non-BGPsec BGP and then the culprits start creating fake AS paths to get around that validation, at that point BGPsec can fix that problem.

But as it is today BGPsec is an unimplemented fix for unimplemented problems.  :-)  :-(  :-)

Once we can validate paths then BGPsec will be of additional value, but I expect that the huge overhead that it carries will never justify the benefits. If people are leaking routes maliciously, as some people have accused China Telecom of doing [*], then path validation even on unprotected paths they'd have to inject fake paths to get through the validation to keep doing that. At that point, there's really no plausible deniability anymore.

[*] https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050&context=mca

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 1 Jul 2019 17:18:36 -0400

> 2. A signature from any given AS in the path on the next hop AS, so you can determine that the update was propagated as intended by each previous hop

yup, that's bgpsec.

> These features are orthogonal to the issue of route leaks as defined as types 1 - 4 in RFC 7908: these break the valley-freeness property that we expect to see in valid paths, but as they're accide…

ah! yes, this is the same sort of stuff sahron goldberg,. et-al
wrangled in several papers over the last 10 or so years:
  "RPKI, SIDR, BGPSEC are nice, but you STILL have to plan to do some
prefix filtering"

(note that also danny mcpherson was an 'early adoptor' of this
premise... "Hey, this won't stop leaks, so.. like... wtf dudes?"
perhaps a tad more eloquently put by danny)

> Note that the second feature seems impressive until you realize that it's a feature of the internet that ALL BGP updates reach ALL ASes, and that the source only gets to select the next hop AS, but…

"all" -  where there isn't some policy enforcing a block/etc, or where
best-path didn't cause the route to propagate. sure.

> But as it is today BGPsec is an unimplemented fix for unimplemented problems.  :-)  :-(  :-)

my guess is we don't know the shape of today's problem :( but ok.

---

From: Alexander Azimov <[email-masked]>
Date: Fri, 5 Jul 2019 00:55:20 +0300

Hi, bellow my additional comments.
Just in case - I removed from quote those parts where we are on the same
side.

a1 ^ a2 / a3 \ a4
> ^/\ is not a valid path. So a3 has to register its C2P relationship with
You can't enforce it. Sibling occurs not only between parties under single
administrative control.
And you don't want to have such kind of dependency for your security
configuration.

> Maybe it can be fixed by adding a sibling flag to the c2p record, but at
> the moment I'm not sure about security consequences.
>
>
> In the draft you mention that it's important that the customer can claim
> the relationship and not the provider. So I would be hesitant to have a S2S
> relationship record is that would either be too easy to claim (if one
> sibling can do it) or complex to implement (only valid when both siblings
> claim the relationship).
>
IMO the moment we require two (or more) independent parties synchronize
their configuration without automation - we lose.
My idea was to add one-side s2s (or c2c) to make it work. But I'm still not
sure about this.

> And to follow up my previous email, if we have a network with malicious
> intent that would hijack/disaggregate prefixes + create a 'virtual peering
> link' between it and victim ASN, its customers will not able to detect it
> anyway since it will look like a valid path: '-\'.
>
>
No. Imagine I'm an attacker (or BGP optimizer) and I want to send prefixes
with a malformed path to my customer.
To bypass filters based on your proposal I just need to have a 'virtual'
link with the originator.

If the original path was 'a1 a2 a3 attacker customer', the path 'a1
attacker customer' will be also valid. (the path is again reversed, just to
keep it same to the previous email).

So, if we are not speaking about BGPSec-like signatures, your approach will
not protect from ASPATH violation.
The thing it might bring is the detection of mistake route leaks that are
received from providers. So, it can bring benefit at the state of early
adoption.

I will try to integrate into ASPA logic. I have a feeling that it can be
done without registering siblings.

-- 
Best regards,
Alexander Azimov

---

From: Alexander Azimov <[email-masked]>
Date: Sun, 7 Jul 2019 18:34:31 +0300

Here is a sample of pseudocode:

def verify_aspath(local_role, reverse_aspath, neigbor_asn):
>     if not len(reverse_aspath) or local_role in (customer, peer, rs,
> provider) and neigbor_asn != reverse_aspath[0]:
>         return False
>
>     if local_role in (provider, peer, rs):
>         for i in range(len(reverse_aspath)):
>             if not i or reverse_aspath[i-1] == reverse_aspath[i]:
>                 continue
>
>             if verify_pair(reverse_aspath[i-1], reverse_aspath[i]) ==
> invalid:
>                 return False
>     elif local_role in (customer, rs_client):
>         going_up = True
>         for i in range(len(reverse_aspath)):
>             if not i or reverse_aspath[i-1] == reverse_aspath[i]:
>                 continue
>
>             if going_up and verify_pair(reverse_aspath[i-1],
> reverse_aspath[i]) == invalid:
>                 going_up = False
>                 continue
>
>             if not going_up and verify_pair(reverse_aspath[i],
> reverse_aspath[i-1]) == invalid:
>                 return False
>
>     return True

It's slightly simplified (I ignored AS_SETs) but it shows that it is
possible to add route leak detection for prefixes that are received from
providers without changing ASPA profile.

пт, 5 июл. 2019 г. в 00:55, Alexander Azimov <[email-masked]>:

> My idea was to add one-side s2s (or c2c) to make it work. But I'm still
> not sure about this.
>
>
> So, if we are not speaking about BGPSec-like signatures, your approach
> will not protect from ASPATH violation.

-- 
Best regards,
Alexander Azimov

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 9 Jul 2019 15:36:36 +0200

Hi Alexander,

On 4 Jul 2019, at 23:55, Alexander Azimov <[email-masked]> wrote:

> Just in case - I removed from quote those parts where we are on the same side.

:-)

> You can't enforce it. Sibling occurs not only between parties under single administrative control.
> And you don't want to have such kind of dependency for your security configuration.

Not sure what you mean...

> IMO the moment we require two (or more) independent parties synchronize their configuration without automation - we lose. 

Well, yes, life without automation is hard. But then again, not everything is about making life easy.

In this case, if two ASes disagree about their relationship, then we have a problem. The only question is how the problem manifests itself. Today, too often it manifests itself as a route leak. We want to stop that.

Assuming we can't magically make the disagreeing about the relationship disappear, this means the problem must be pushed elsewhere. I.e., rather than adopt the most optimistic interpretation (allowing all prefixes allowed by _one_ AS) we should adopt a more pessimistic interpretation (only the prefixes allowed by _both_ ASes) or maybe even the most pessimistic interpretation (no prefixes allowed through unless there is agreement).

> My idea was to add one-side s2s (or c2c) to make it work. But I'm still not sure about this.

I don't think we have to do anything special. Assume AS1 and AS2, these are the possibilities:

AS1->AS2    AS2->AS1    Relationship
 claim       claim

  C2P          -        AS1 = customer, AS2 = provider
   -          C2P       AS1 = provider, AS2 = customer
   -           -        AS1 and AS2 are peers
  C2P         C2P       AS1 and AS2 are siblings

So by overclaiming a peer can upgrade to a customer relationship or a provider to a sibling relationship.

However, this is relatively harmless as the outgoing filters that a peer uses towards a peer are the same as a customer uses towards a provider, and the same for provider to customer and sibling to sibling.

So as long as each AS independently determines its relationship with other ASes and sets up filtering accordingly, C2P overclaiming is not problematic.

Of course incorrect C2P claims by one AS combined with incorrect filters by the next AS will still result in a route leak. But at least two incorrect actions by two different organizations are now required.

As a result, it's imperative that we don't use automation to propagate the relationship information from a single mistaken source.

If fact, I would go as far as to depeer any peer who registers an incorrect C2P claim.

> No. Imagine I'm an attacker (or BGP optimizer) and I want to send prefixes with a malformed path to my customer.
> To bypass filters based on your proposal I just need to have a 'virtual' link with the originator.

Hm, that sounds like the logic that gave us SSL inspection.

It would be better to turn off path validation if you know there is going to be manipulation of the AS path.

> If the original path was 'a1 a2 a3 attacker customer', the path 'a1 attacker customer' will be also valid. (the path is again reversed, just to keep it same to the previous email).

Yes, in the sense that if the path "a1 a2 a3 attacker customer" is considered a valid path, then the mechanism I propose will also allow "a1 attacker customer".

However, I don't think that that makes a difference here, as surely customer hasn't registered attacker as a valid transit AS. If attacker is not a valid provider, then both paths above, the long one as well as the short one, will be rejected.

The more problematic situation is the one where a1 peers with attacker, and attacker now sends the AS path "a1 a2 a3 customer". RFC 4271 only suggests that an implementation MAY want to check whether the left most AS in the path matches the AS of the BGP neighbor.

Cisco does this by default, hence you need to configure "no bgp enforce-fist-as" on Cisco routers when you peer with a route server that doesn't add its own AS to the AS path. Juniper routers don't perform this check by default but can be configured to do so. Extreme doesn't have a configuration option for this so I assume they don't perform the check.

Of course when attacker sets up peering (or a customer relationship) with a1, it can claim to have AS a2 and thus circumvent the checks done by the routers.

> So, if we are not speaking about BGPSec-like signatures, your approach will not protect from ASPATH violation. 

Yes. When we have figured out how to validate paths, we still have some work to do to make sure those paths are not faked.

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 9 Jul 2019 17:14:49 +0200

There are now four drafts about AS path validation to remedy routing leaks that I'm aware of:

LDM:	draft-ietf-grow-route-leak-detection-mitigation
ASPA:	draft-ietf-sidrops-aspa-verification
ASCones:	draft-ietf-grow-rpki-as-cones
PathRPKI:	draft-van-beijnum-sidrops-pathrpki

The TL;DR on the four:

LDM

Add in-band information to BGP that signals that a peer-peer hop has been traversed to avoid having two peer-peer hops. The idea is to do this without new code, at first at least. As the checks must thus be implemented with existing policy options, those will probably be easy to implement in code on the routers later.

ASPA

Register customer-to-provider (C2P) relationships with extensions to RPKI. Based on this, check the upstream and downstream parts of the AS path, making sure there are no valleyfreeness violations and that if the customer in the relationship between two ASes has registered a set of provider ASes, the upstream AS is indeed one of the registered providers. If not, then the path is considered invalid.

The hop between the upstream and downstream parts of the path may be an unregistered hop; peer relationships are not registered and in this part of the path any relationship is a valid one anyway. If there are additional unregistered relationships in the path, validation is not possible and the path is considered valid.

ASCones

Register provider-to-customer (P2C) relationships with extensions to RPKI. Recursively collect this information to resolve all ASes that may be visible behind a given AS. Then do a reverse lookup in the ROA database to obtain all the prefixes that are authorized to be advertised by these ASes and generate a prefix filter that can be applied to a BGP neighbor.

Unclear what happens to prefixes that aren't included in the filter because of a missing AS-Cone (P2C record) or ROA.

PathRPKI

The RPKI ROA format is extended to include a set of authorized transit ASes in the upstream part of the path. Authorized ASes in the downstream part of the path are known through local configuration. For each prefix, the two halves of the path are combined into a list of ASes that may appear in the AS path.

These paths are sent to routers using an extended version of the RPKI to router protocol. Routers mark a prefix as invalid if the origin AS doesn't match as usual, and if an extended list of ASes is present, if there are ASes in the BGP AS path that are not in the filter list (or appear in the wrong order).

So let's compare.

In-band vs out-of-band

LDM is the only mechanism that works in-band. In-band is inherently less effective because the same issues that create a route leak in the first place may also send incorrect in-band information.

Deployment

LDM: although it was supposed to be easy to deploy, discussion has been going on for four years, and in my opinion, as per my earlier email about the draft, deployment issues haven't been solved at this time.

ASPA, ASCone and PathRPKI all require changes in the RIR RPKI front- and backends and the RPKI relying party software implementations.

ASPA: requires unspecified changes to the RPKI to router protocol to convey C2P records, and for routers to implement the validation logic. (Maybe this is not necessary, but this is my best guess at this time.) If so, that may take considerable time and subsequent updates to the filtering logic will be difficult because of the slow update cycle in routers. Lack of an "unknown" validation state with partial deployment may be problematic.

ASCone: generating router filters to be included in configurations is easy to deploy, but very clumsy. Not clear how reusing the RPKI to router protocol would work. Unclear what partial deployment would look like.

PathRPKI: changes to RPKI to router protocol necessary. However, the scope of these changes is small. Good partial deployment as each combination of origin AS and destination AS is immediately protected agains route leaks even if ASes in the middle don't implement PathRPKI.

Who is involved

LDM: transit ASes. Leaf ASes that don't peer have no actions.

ASPA: All ASes. Origin ASes and transit ASes that have transit ASes of their own register C2P records. All other ASes filter based on this, most notably ASes that peer.

ASCone: Transit ASes register P2C records, ASes that peer filter based on this. Leaf ASes that don't peer have no actions.

PathRPKI: origin AS registers authorized transit ASes. No specific actions for transit ASes. ASes in the downstream part of the path filter based on this.

Security

LDM: relatively low, as a malicious AS could modify the in-band information.

ASCone: middle, as ASes can incorrectly claim a P2C relationship with no obvious recourse for the AS that is incorrectly labeled as a customer.

ASPA: high, as only customers claim the customer-provider relationship.

PathRPKI: a little higher, as the upstream part of the path is solely determined by the origin AS (however, at the cost of flexibility as transit relationship changes further upstream now require work by all the ASes downstream of the change)

What now?

There are some good ideas here, but it sure looks like we haven't figured out the best way to attack this problem. Publish four RFCs, throw them to the wall, see what sticks? Hopefully we can come up with a better process than that.

Iljitsch

---

From: Brian Dickson <[email-masked]>
Date: Tue, 9 Jul 2019 10:08:19 -0700

Minor clarifications/comments inline about LDM.

On Tue, Jul 9, 2019 at 8:15 AM Iljitsch van Beijnum <iljitsch=
[email-masked]> wrote:

> Add in-band information to BGP that signals that a peer-peer hop has been
> traversed to avoid having two peer-peer hops. The idea is to do this
> without new code, at first at least. As the checks must thus be implemented
> with existing policy options, those will probably be easy to implement in
> code on the routers later.
>

LDM marks prefixes in-band, on peer-to-peer AND on transit-to-customer
(assuming at least one party is doing LDM.)
LDM checks prefixes in-band upon receipt, on peer-to-peer AND on
customer-to-transit (assuming recipient is doing LDM.)

This prevents all of the major leak paths:
transit-customer-peer
transit-customer-transit
peer-peer-transit
peer-peer-peer

The marking is propagated if large communities are being sent, so even if
intermediate networks involved don't mark or check, the leakage is still
detectable under many scenarios.

>
> ASPA
>
> Register customer-to-provider (C2P) relationships with extensions to RPKI.
> Based on this, check the upstream and downstream parts of the AS path,
> making sure there are no valleyfreeness violations and that if the customer
> in the relationship between two ASes has registered a set of provider ASes,
> the upstream AS is indeed one of the registered providers. If not, then the
> path is considered invalid.
>
> The hop between the upstream and downstream parts of the path may be an
> unregistered hop; peer relationships are not registered and in this part of
> the path any relationship is a valid one anyway. If there are additional
> unregistered relationships in the path, validation is not possible and the
> path is considered valid.
>
> ASCones
>
> Register provider-to-customer (P2C) relationships with extensions to RPKI.
> Recursively collect this information to resolve all ASes that may be
> visible behind a given AS. Then do a reverse lookup in the ROA database to
> obtain all the prefixes that are authorized to be advertised by these ASes
> and generate a prefix filter that can be applied to a BGP neighbor.
>
> Unclear what happens to prefixes that aren't included in the filter
> because of a missing AS-Cone (P2C record) or ROA.
>
> PathRPKI
>
> The RPKI ROA format is extended to include a set of authorized transit
> ASes in the upstream part of the path. Authorized ASes in the downstream
> part of the path are known through local configuration. For each prefix,
> the two halves of the path are combined into a list of ASes that may appear
> in the AS path.
>
> These paths are sent to routers using an extended version of the RPKI to
> router protocol. Routers mark a prefix as invalid if the origin AS doesn't
> match as usual, and if an extended list of ASes is present, if there are
> ASes in the BGP AS path that are not in the filter list (or appear in the
> wrong order).
>
> So let's compare.
>
> In-band vs out-of-band
>
> LDM is the only mechanism that works in-band. In-band is inherently less
> effective because the same issues that create a route leak in the first
> place may also send incorrect in-band information.
>

"send incorrect in-band information" is limited (in the latest draft) to
only "fails to send in-band information".
The only incorrect in-band information that would have any effect is if the
peer-peer marking uses the wrong ASN, at which point the recipient will
block the incoming announcements. I.e. it will treat that error as a leak.
Failure to mark, or failure to check, looks exactly the same as not
participating, and is no worse.

>
> Deployment
>
> LDM: although it was supposed to be easy to deploy, discussion has been
> going on for four years, and in my opinion, as per my earlier email about
> the draft, deployment issues haven't been solved at this time.
>

The finalized versions are being discussed among the authors and will be
discussed at the Montreal meeting. Modulo uptake by providers, I believe we
are crossing the threshold to actual deployment, at which point this is
entirely in the hands of the operators.
We can lead them to water, but cannot make them drink.

>
> ASPA, ASCone and PathRPKI all require changes in the RIR RPKI front- and
> backends and the RPKI relying party software implementations.
>
> ASPA: requires unspecified changes to the RPKI to router protocol to
> convey C2P records, and for routers to implement the validation logic.
> (Maybe this is not necessary, but this is my best guess at this time.) If
> so, that may take considerable time and subsequent updates to the filtering
> logic will be difficult because of the slow update cycle in routers. Lack
> of an "unknown" validation state with partial deployment may be problematic.
>
> ASCone: generating router filters to be included in configurations is easy
> to deploy, but very clumsy. Not clear how reusing the RPKI to router
> protocol would work. Unclear what partial deployment would look like.
>
> PathRPKI: changes to RPKI to router protocol necessary. However, the scope
> of these changes is small. Good partial deployment as each combination of
> origin AS and destination AS is immediately protected agains route leaks
> even if ASes in the middle don't implement PathRPKI.
>
> Who is involved
>

Mostly correct; we are potentially adding the ability of Leaf ASes to mark
prefixes on ingress (identical to the marking that their transit ISPs would
have marked), allowing (but not requiring) leaf ASes to allow upstreams to
detect leaks that these same leaf ASes might have caused.

>
> ASPA: All ASes. Origin ASes and transit ASes that have transit ASes of
> their own register C2P records. All other ASes filter based on this, most
> notably ASes that peer.
>
> ASCone: Transit ASes register P2C records, ASes that peer filter based on
> this. Leaf ASes that don't peer have no actions.
>
> PathRPKI: origin AS registers authorized transit ASes. No specific actions
> for transit ASes. ASes in the downstream part of the path filter based on
> this.
>
> Security
>

A malicious AS modifying the in-band information can only remove leak
marking, or add leak marking.
If they add leak marking, the only impact would be to block announcements
that would otherwise be accepted.

Removing leak marking would allow the malicious AS to leak, but potentially
be visible to third parties that are able to see the modification
(differentiate based on the ASN in the leak marking received on other
connections, vs AS path and absence of marking).
The latter would at least allow for non-repudiation (it would be
theoretically possible to identify the specific ASN).

Lack of protection on the AS-path is equally problematic WRT malicious ASes.

Brian

>
> ASCone: middle, as ASes can incorrectly claim a P2C relationship with no
> obvious recourse for the AS that is incorrectly labeled as a customer.
>
> PathRPKI: a little higher, as the upstream part of the path is solely
> determined by the origin AS (however, at the cost of flexibility as transit
> relationship changes further upstream now require work by all the ASes
> downstream of the change)
>
> What now?
>
> There are some good ideas here, but it sure looks like we haven't figured
> out the best way to attack this problem. Publish four RFCs, throw them to
> the wall, see what sticks? Hopefully we can come up with a better process
> than that.
>
> Iljitsch
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>