Subject: [GROW] last call for draft-ietf-grow-unique-origin-as-00

From: "Peter Schoenmaker" <[email-masked]>
Date: Fri, 17 Dec 2010 12:54:55 +0800

Hi,

I would like to issue last call for draft-ietf-grow-unique-origin-as-00.  We
will close last call Jan 2nd 2011.

Please review the draft and provide any last comments.

Thanks

Peter

---

From: Terry Manderson <[email-masked]>
Date: Sun, 19 Dec 2010 19:25:18 -0800

I've read draft-ietf-grow-unique-origin-as-00 and I think it serves as a
suitable and stable recommendation for anycasted services, esp those we tend
to consider of high importance.

While reading the document no flaws of reason jumped out at me -
So, I support the last call.

Cheers
Terry

On 17/12/10 2:54 PM, "Peter Schoenmaker" <[email-masked]> wrote:

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Shane Amante <[email-masked]>
Date: Sun, 19 Dec 2010 23:06:40 -0700

Hi,

> Please review the draft and provide any last comments.

I've reviewed draft-ietf-grow-unique-origin-as-00 and think its recommendations are sound, (and long overdue).  I did not find any technical concerns with the draft and support publishing it as a RFC.

-shane

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 20 Dec 2010 07:14:55 +0100

Hi Peter. WG,

I have read the draft and I like it. I support we go forward with it as is.

Many thx,
R.

---

From: Roland Dobbins <[email-masked]>
Date: Mon, 20 Dec 2010 14:52:47 +0700

> I have read the draft and I like it. I support we go forward with it as is.

I've read and reviewed it, and concur in moving forward.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 20 Dec 2010 14:08:43 -0500

> will close last call Jan 2nd 2011.

Read it and support (and apologies, I didn't notice this thread when I sent out mail a short while ago, saying basically the same thing...)

W

---

From: Matsuzaki Yoshinobu <[email-masked]>
Date: Tue, 21 Dec 2010 09:49:13 +0900 (JST)

Hi,

> will close last call Jan 2nd 2011.

I have reviewed it and think it's a good idea.

And some comments for [4. Addtional Reccomendations]

network operators need official information about the anycasted
network configuration such as a list of origin ASNs so that ops can
avoid a rogue anycast node.  An AS-SET in the IRRs or a web-site would
be fine.

A discrete set of peering ASNs for each anycast node is also helpful
for downstream ASNs that receive a prefix of the anycasted node via
their upstreams (sometimes peering ASNs of the anycasted node).  And
researchers who get BGP information from these downstreams are also
happy with these information because they do not need an assumption of
'upstream-downstream' relationship.  But this probably costs too much
for ops of the anycasted services. :(
-----
Matsuzaki Yoshinobu <[email-masked]>
 - IIJ/AS2497  INOC-DBA: 2497*629

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 21 Dec 2010 15:59:01 +0100

Hi,

I have read this document and i believe this is a useful thing to have 
and it ready for publication.
I have some comments. I am far from an expert on this area, so consider 
these comments as coming from a somehow informed outsider.
My more general comment, is that i understand this mechanism is very 
useful to deal with operational mistakes rather than as a security tools 
to deal with attackers (especially if not deployed with RPKI). If that 
is the case, it should be clarified in the document as per my comments 
below. If that is not the case, i would appreciate some enlightenment.

Some comments:

The boiler plate, especially the name of the authors seems not properly 
aligned.

Section 1, terminology, the terms are not in correct alphabetical order

In section 3 it reads:

    Some examples of such security and operational
    issues include BGP route leaks affecting the anycasted service, rogue
    anycast nodes appearing for the service, or the emergence of other
    aberrant behavior in either the routing system, the forward query
    datapath, or query response datapath.

So, I fully understand that using unique origin AS will help debugging 
operational mistakes, but i am not sure i understand why this is a 
security feature. I mean, if an atttacker wants to inject the anycast 
prefix, it could even use one of the appropriate AS numbers as origin 
and with this new practice, it could even issue it with its own AS 
number and would be still be ok as different AS origins will be 
acceptable (of course, this would make it traceable, but still). So 
bottom line is, i don't understand why this is a security tool.

Then the same section reads:

    Additionally, while it goes without saying that anycasted services
    should always strive for exact synchronization across all instances
    of an anycasted service address, if local policies or data plane
    response manipulation techniques were to "influence" responses within
    a given region in such a way that those response are no longer
    authentic or that they diverge from what other nodes within an
    anycasted service were providing, then it should be an absolute
    necessity that those modified resources only be utilized by service
    consumers within that region or influencer's jurisdiction.

I agree with the statement, but maybe it would be worth stating more 
explicitly how this relates to the proposal. I guess you are envisioning 
to filter routes of anycasted prefixes based on the origin, sicne you 
know that certain origins are being "creative" in the treatment of their 
replies?

In section 3 it reads:

    Discrete origin ASNs per node provide a discriminator in the routing
    system that would enable detection of leaked or hijacked instances

Again, i am not sure how this helps with hijacked prefixes as the 
hijacker should be able to also fake the origin AS, right?

Later on, in section

5.  Security Considerations

    The recommendations made in this memo aim to provide more flexibility
    for network operators hoping to better monitor and prevent issues
    related to globally anycasted critical infrastructure resources.
    Anycast itself provides considerable benefit in the face of certain
    attacks, yet if a given instance of a service can appear at many
    points in the routing system and legitimate instances are difficult
    to distinguish from malicious ones, then anycast expands the
    service's attack surface rather than reducing it.

How come that an anycast service expands the surface of an attack? I 
would actually say the opposite, the surface of the attack diminishes as 
there are more anycast servers deployed, as each server will serve a 
smallr surface, what am i missing?

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 22 Dec 2010 02:53:11 +0700

On Dec 21, 2010, at 9:59 PM, marcelo bagnulo braun wrote:

> How come that an anycast service expands the surface of an attack? I would actually say the opposite, the surface of the attack diminishes as there are more anycast servers deployed, as each server will serve a smallr surface, what am i missing?

The confusion which can arise in discriminating legitimate instances vs. illegitimate instances can have this effect, as it becomes difficult for potential consumers of the services in question to differentiate between the two.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 21 Dec 2010 21:17:45 +0100

> The confusion which can arise in discriminating legitimate instances vs. illegitimate instances can have this effect, as it becomes difficult for potential consumers of the services in question to…

I understand that, but this is the same with a unicast prefix, right? 
and with a unicast prefix the situation is worse AFAICT since the 
unicast prefix is injected from only one origin, making the parts of the 
network taking the rogue announce for valid likely to be higher, than in 
the case of the anycast, where there are several legitimate origins.

My question is why the surface is expanded in the anycast case.

So, i am still not getting it, sorry.

Regards, marcelo

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 22 Dec 2010 03:22:09 +0700

On Dec 22, 2010, at 3:17 AM, marcelo bagnulo braun wrote:

> making the parts of the network taking the rogue announce for valid likely to be higher, than in the case of the anycast, where there are several legitimate origins.

No, because *upon investigation*, it's generally considerably easier to determine which announcements are legitimate and which aren't for a given prefix which isn't anycasted vs. doing so for one which is anycasted.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 21 Dec 2010 21:41:15 +0100

> No, because *upon investigation*, it's generally considerably easier to determine which announcements are legitimate and which aren't for a given prefix which isn't anycasted vs. doing so for one w…

Right, so basically you are saying is that if there is a unicast 
announcement that should come from a single origin, it is easier to 
distinguish the rogue announcements than in the case of an anycast 
announcement, where it can come from multiple origins?

If that is the case, i can see that.
Now that doesn't imply afaict that the surface of the attack will be 
bigger, just that it is harder to identify.
Second, it is not obvious to me why having different origins for each 
anycast location makes this situation any easier in the case of a 
malicious attacker (Who is could potentially include a false origin in 
its announcement)

Regards, marcelo

---

From: Roland Dobbins <[email-masked]>
Date: Wed, 22 Dec 2010 03:46:29 +0700

On Dec 22, 2010, at 3:41 AM, marcelo bagnulo braun wrote:

> Now that doesn't imply afaict that the surface of the attack will be bigger, just that it is harder to identify.

Disagree.  Confusion in and of itself represents a broadening of the attack surface.

> Second, it is not obvious to me why having different origins for each anycast location makes this situation any easier in the case of a malicious attacker (Who is could potentially include a false origin in its announcement)

At the moment, there are out-of-band mechanisms which in many (not all) instances can be utilized to sort the sheep from the goats.  Obviously, technological - and therefore more automagic - mechanisms for doing so are preferred, and there is considerable activity in that regard (i.e., rPKI).

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 21 Dec 2010 22:18:37 +0100

> Disagree.  Confusion in and of itself represents a broadening of the attack surface.

mmm, maybe we are having a terminology issue here, i was using surface 
== Catchment

what do you mean by surface?
> At the moment, there are out-of-band mechanisms which in many (not all) instances can be utilized to sort the sheep from the goats.  Obviously, technological - and therefore more automagic - mechan…
right, i can see that this _in conjunction_ with RPKI helps to deal with 
this. So, i see this an an enabler, not as a solution per se (i.e. 
without RPKI, the attacker can include a false origin and get away with it)

Regards, marcelo

---

From: Gaurab Raj Upadhaya <[email-masked]>
Date: Wed, 22 Dec 2010 15:14:25 +0000

Hi,

While I have ongoing discussions with the Danny on a few topics, I
believe that this document should proceed ahead to WGLC.

- -gaurab

> Please review the draft and provide any last comments.

- -- 

http://www.gaurab.org.np/

---

From: Joe Abley <[email-masked]>
Date: Wed, 22 Dec 2010 11:13:45 -0500

> Please review the draft and provide any last comments.

summary

I have reviewed the document and have a couple of comments. I don't have any great disagreement with the conclusion, but I don't feel that the document as written provides a clear path of logic to support it. I don't object to its publication as-is, but I feel that it could be improved.

substantive(ish)

Section 2 includes the text:

   Service level query capabilities may or may not provide a mechanism
   to identify which anycast node responded to a particular query,
   although this is likely both service (e.g., DNS or NTP) and
   implementation dependent.  For example, NSD, Unbound, and BIND all
   provide 'hostname.bind or hostname.id' [HNAME] query support that
   enables service-level identification of a given server.

NSD, unbound and BIND deserve references, I think (or should be generalised to "several prominent authority-only and resolver implementations").

HOSTNAME.BIND and ID.SERVER queries use the CHAOS class and the TXT RRType, not HNAME (I appreciate HNAME is just an anchor for an eref, but it's also an RRType, so there is potential for confusion). There is no deployed "HOSTNAME.ID" to my knowledge. A reference to RFC 5001 seems like it ought to be included.

Section 3 (the meat of the document) recommends that individual anycast nodes each originate their service prefixes from a different ASN (i.e. one ASN per anycast node, for the same service). The rationale given is, in my opinion, still weak (which is not to say it's a bad idea -- I just don't see a logical path towards the conclusion).

The operator of a service distributed using anycast might well use one of several available alerting systems to notify them if a service prefix is originated by an unusual AS number. It's not clear to me that in principle this is any easier than checking adjacencies to a single service-specific (i.e. not node-specific) origin AS. Both require ongoing maintenance (updating the list of legitimate origin ASes vs. updating the list of adjacencies). Whilst one might be less work than the other, I don't think it's the universal case that a consistent origin AS is easier, better or more practical. This depends on the deployment strategy for individual services.

I also don't understand the RPKI-related justification, perhaps because I'm insufficiently familiar with the mechanics of deploying it. Under what circumstances would it be difficult to identify who holds the key for a ROA in the case that a service-specific origin AS is used? The only example I can think of is the unusual case where responsibility for operating a service is distributed amongst many entities, such as with the AS112 project. This seems like a corner case.

The resource consumption issue is mentioned but largely dismissed because, with 32 bit AS numbers, we have lots of room and so why worry. While I appreciate that the document mainly discusses critical infrastructure (which is not defined, but the implication is presumably that the number of services distributed using anycast is fairly low) does this assessment sound as convincing for a service deployed using five hundred nodes deployed within ISPs as it does for service deployed using 30 nodes deployed at peering points?

In section 5 the document promotes the use of node-specific origin ASes for the benefit of network operators; the implication seems to be that the network operators concerned are not those responsible for operating the service. I don't the benefits to that community are very well explained in the document. What specifically does a node-specific origin AS allow an operator to do that they can't do with a service-specific origin AS? Again, I'm not arguing with the conclusion, just suggesting that the document does not lead the reader to it in a very satisfying fashion. I appreciate there's a link to a Renesys blog post buried in there, but I think the reasoning that supports the conclusion belongs in the document, not in an external reference (and I don't think that particular blog post describes the benefits of per-node origin ASes very clearly).

Section 8 actually contains no actions for the IANA, and (procedurally) I think it'd be kind to the IANA staff who have to process these documents if it simply said so. References to RIR policy in that section seem to lack teeth (there's nothing the IANA can do about assignment policy developed by individual RIR constituents). RFC 2434 might be a useful reference.

editorial

The document makes many varied uses of the stem "anycast", e.g. anycasted, anycasting. Anycasting has some heritage (e.g. the title of RFC1546). In 4786 we tried to use just "anycast", and use it as a noun. I have a personal preference for that approach, but quite possibly I'm the only one. I thought I'd mention it, anyway :-)

Joe

---

From: John Kristoff <[email-masked]>
Date: Wed, 22 Dec 2010 16:52:44 -0600

On Fri, 17 Dec 2010 12:54:55 +0800

> Please review the draft and provide any last comments.

My thanks to Danny for prodding me to review it and comment.

There are a handful of spelling mistakes and some words that are
if not found in the OED, are at least uncommon (e.g. influencer's).

Some sentences are also quite lengthy and come across awkward, at
least to me.  For instance,

   Tools such as traceroute are also used to determine which
   location a given query is being routed to, although it may not
   reveal local-scope anycast instances, or if there are multiple
   servers within a given anycast node, which of the servers responded
   to a given query, in particular when multiple servers within an
   anycast node are connected to a single IP router.

could perhaps be rewritten as:

   Tools such as traceroute are also used to help determine which
   location a given query is being routed to.  However, they may not
   reveal local-scope anycast instances, if there are multiple
   servers within a given anycast node or which of the servers responded
   to a given query.

This sentence:

   This detection model would need to be expanded to account for unique
   origin ASNs per node if a given service operators chooses to employ
   such as a model, and given that AS paths are trivial to manipulate,
   the above technique would only assist in the event of unintentional
   configuration errors that reoriginate the route (e.g., it doesn't
   even detect leaks that preserve the initial path elements).

could perhaps be rewritten as:

   This detection model would need to be expanded to account for unique
   origin ASNs per node.  Given that AS paths may be manipulated,
   the above technique would only assist in the event of unintentional
   configuration errors that re-originate the route.  That is, the
   technique doesn't detect leaks that preserve the initial path
   elements.

The abstract states this is for "critical" infrastructure and only
eludes to what that is by later mentioning DNS root and TLD servers as
examples.  Perhaps either make this explicitly for root and TLD servers,
deal with what critical means or just make this is a generally accepted
practice.

That said, is there any current deployment of this technique?  I'd be
interested in reviewing any papers or case studies.  If not, I think it
would be prudent to have some before publication.  I want to make sure
the following paragraph is justified:

  Furthermore, inconsistent origin AS announcements associated with
  anycasted services for critical infrastructure SHOULD NOT be deemed
  undesirable by routing system reporting functions, but should instead
  be embraced in order to better identify the connectedness and
  footprint of a given anycasted service.

This document is making the case for this technique around management
and policy improvements, but I have some questions with how complete
the arguments are.

First, there is no discussion of BGP attributes, particular communities,
which would seem to be a viable policy alternative to unique origin
ASNs.

Second, the document isn't convincing when it claims unique origin ASNs
"would enable detection of leaked or hijacked instances more quickly".
Adding more origin ASNs would just seem to complicate matters, because
now you not only need to know the path, but also which origin ASN
goes with each path.  It may also actually broaden the attack surface.

Examples might help me better understand what I'm missing.

I think the following statement is irrelevant and best removed:

  Additionally, critical infrastructure employment of 32-bit ASNs for
  new nodes might well help to foster adoption of native 32-bit ASN
  support by network operators.

The discussion about potential benefits for RPKI is interesting, but
seems to be putting the cart before the horse.  I'm not up on the SIDR
work, but if along the lines of my earlier comment, communities along
with the announced prefix were validated, would that help?

John

---

From: Arturo Servin <[email-masked]>
Date: Wed, 22 Dec 2010 21:12:11 -0200

I've reviewed draft-ietf-grow-unique-origin-as-00 and think it presents an interesting proposal.

	My only concern is the explosion of requests asking for 2 bytes  (now scarce) and claiming that they are for critical infrastructure. I am not sure if the draft should mention that  4-bytes ASN should be preferred.

	Other observations are:

	- As previously commented, I think the reference to RIR policies should not be in "IANA Considerations". Nevertheless  I find important to mention that RIR policies play an important role in how ASNs are allocated. 

	- I do not see the relevance to use "[RENESYS-BLOG]" as a reference. May be I am missing the argument.

Regards,
-as