Subject: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06

From: John Scudder <[email-masked]>
Date: Tue, 22 Jul 2014 15:43:28 -0400

Folks,

The authors have requested IDR adopt draft-vandevelde-idr-remote-next-hop-06 as a working group document. 

http://datatracker.ietf.org/doc/draft-vandevelde-idr-remote-next-hop/

Please send any comments to the list by August 8. 

In addition to commenting on adoption of the work, you may want to comment on whether the draft is mature enough for us to consider early allocation of the path attribute code point. As a reminder, RFC 7120 requires that for early allocation, "the specifications of these code points must be stable". (Section 2.c.) The chairs and ADs also have to "judge that there is sufficient interest in the community for early (pre-RFC) implementation and deployment". (Section 2.d.)

It's fine to be in favor of WG adoption but opposed to early allocation at this time, or in favor of both, or against both. Being against adoption but in favor of allocation would be a bit weird. :-) 

Thanks,

--John

---

From: Sachin K <[email-masked]>
Date: Tue, 22 Jul 2014 13:28:04 -0700

Support.

-Sachin Karisiddappa

On Tue, Jul 22, 2014 at 12:43 PM, John Scudder <[email-masked]> wrote:

> Folks,
>
> The authors have requested IDR adopt
> draft-vandevelde-idr-remote-next-hop-06 as a working group document.
>
> In addition to commenting on adoption of the work, you may want to comment
> on whether the draft is mature enough for us to consider early allocation
> of the path attribute code point. As a reminder, RFC 7120 requires that for
> early allocation, "the specifications of these code points must be stable".
> (Section 2.c.) The chairs and ADs also have to "judge that there is
> sufficient interest in the community for early (pre-RFC) implementation and
> deployment". (Section 2.d.)
>
> It's fine to be in favor of WG adoption but opposed to early allocation at
> this time, or in favor of both, or against both. Being against adoption but
> in favor of allocation would be a bit weird. :-)
>
> Thanks,
>
> --John
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Anoop Kapoor (ankapoor)" <[email-masked]>
Date: Tue, 22 Jul 2014 20:32:57 +0000

support

On 7/22/14 12:43 PM, "John Scudder" <[email-masked]> wrote:

>In addition to commenting on adoption of the work, you may want to
>comment on whether the draft is mature enough for us to consider early
>allocation of the path attribute code point. As a reminder, RFC 7120
>requires that for early allocation, "the specifications of these code
>points must be stable". (Section 2.c.) The chairs and ADs also have to
>"judge that there is sufficient interest in the community for early
>(pre-RFC) implementation and deployment". (Section 2.d.)
>
>It's fine to be in favor of WG adoption but opposed to early allocation
>at this time, or in favor of both, or against both. Being against
>adoption but in favor of allocation would be a bit weird. :-)
>
>Thanks,
>
>--John
>

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 22 Jul 2014 20:48:09 +0000

Support

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 22 Jul 2014 16:56:13 -0400

Let me add that a simple "support" will be deemed to mean "support WG adoption".

--John

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 22 Jul 2014 23:07:35 +0200

Support (as co-author)

On Tue, Jul 22, 2014 at 10:56 PM, John G. Scudder <[email-masked]> wrote:

> at this time, or in favor of both, or against both. Being against adoption
> but in favor of allocation would be a bit weird. :-)
> >
> > Thanks,
> >
> > --John
> >

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Tue, 22 Jul 2014 21:12:56 +0000

Support (as co-author)

G/

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of John Scudder
Sent: 22 July 2014 15:43
To: idr@ietf. org
Subject: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06

Folks,

Thanks,

--John

---

From: Jon Mitchell <[email-masked]>
Date: Tue, 22 Jul 2014 17:31:05 -0400

> It's fine to be in favor of WG adoption but opposed to early allocation at this time, or in favor of both, or against both. Being against adoption but in favor of allocation would be a bit weird. :…

Support for adoption.

-Jon

---

From: KK Chittimaneni <[email-masked]>
Date: Tue, 22 Jul 2014 15:00:22 -0700

Support for adoption.

---

From: "Bertrand Duvivier (bduvivie)" <[email-masked]>
Date: Tue, 22 Jul 2014 22:01:34 +0000

Support

Best Regards Bertrand Duvivier
NOSTG Product Manager

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Wim)
Sent: mardi 22 juillet 2014 22:48
To: John Scudder; idr@ietf. org
Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06

Support

---

From: "Bertrand Duvivier (bduvivie)" <[email-masked]>
Date: Tue, 22 Jul 2014 22:09:16 +0000

Support for adoption

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Henderickx, Wim (Wim)
Sent: mardi 22 juillet 2014 22:48
To: John Scudder; idr@ietf. org
Subject: Re: [Idr] WG adoption requested for draft-vandevelde-idr-remote-next-hop-06

Support

---

From: Balaji Pitta venkatachalapathy <[email-masked]>
Date: Tue, 22 Jul 2014 15:16:46 -0700

Support for adoption.

Balaji

> From: [email-masked]
> To: [email-masked]; [email-masked]; [email-masked]
> Date: Tue, 22 Jul 2014 22:09:16 +0000

---

From: Hideaki HAYASHI <[email-masked]>
Date: Wed, 23 Jul 2014 10:31:08 +0900

support.

-- hideaki

---

From: Shishio Tsuchiya <[email-masked]>
Date: Wed, 23 Jul 2014 10:33:48 +0900

Support as adoption

---

From: Thomas Mangin <[email-masked]>
Date: Wed, 23 Jul 2014 08:42:53 +0100

support.

Thomas

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 23 Jul 2014 10:40:44 -0400

Support.

cheers,
--satoru

---

From: Randy Bush <[email-masked]>
Date: Thu, 24 Jul 2014 09:00:26 -0400

i am an author, so it would be inappropriate for me to support.  but,
as i have been known to occasionally oppose drafts for which i am an
author, i should say i do not oppose adoption od this draft.  :)

randy

---

From: Satoshi Usui <[email-masked]>
Date: Thu, 24 Jul 2014 16:47:04 -0400

I'm in favor of both, WG adoption and early allocation of the the code point.

Satoshi

---

From: <[email-masked]>
Date: Mon, 28 Jul 2014 09:55:25 +0000

Hi all,

> hop-06 as a working group document.

I'm afraid that, as per my current understanding of the draft, I do not think that this version of the draft is ready for WG adoption.
I don't think that the document is mature enough for early allocation.

Please find below some more detailed comments.

Regards,
Bruno

1) Major
My understanding is that this attribute can be attached to any NLRI of AFI/SAFI, including ones used in the Internet and VPN. I think that this document should document what are the potential (negative) impacts of attaching this attribute to such route, either by an originator or by someone in transit. In particular in term of security and routing consistency. (Yes, I've read the security section, more on this latter).
In particular for Internet routing, it looks like this open the possibility for the forwarding path to be (arbitrary?) different from the control plane path (AS PATH).
- If so, how do you detect loops? (as the AS PATH won't help). In some part of the document, you are referring to checking PATH. Do you mean the PATH of the NLRI having this attribute, or the PATH of the NLRI used to route toward the remote_next-hop, or both? Do you check that both originator ASes are the same, or it does not matter?
- what about routing policy violation? e.g. peer A advertise a route to peer B and so pretend that it will route the traffic toward that destination. While it could attach a remote NH pointing to a transit provider of B. Hence B believes the NRLI routes to a peer while in fact it route to a transit.

For VPN/labelled routes, the "attached" label is local to the BGP NH. Now if someone attaches a remote NH attribute, what happen exactly? The label traffic is sent to the remote NH? Seems to open the ability for VPN breach (especially for AS using 6PE as Internet routes are labeled and could possibly redirect to an IPv6 VPN).

1.2) security consideration
"This technology could be used as technology as man in the middle  attack, however with existing RPKI validation for BGP that risk is   reduced."
What do you mean by "existing"? Do you mean that a full deployement of RPKI validation must be performed before deploying remote NH? Or if partial deployment is enough, how partial? Do you mean origin validation or as path validation or route leaking detection...?

"   The distribution of Tunnel end-point address information can result
   in potential DoS attacks if the information is sent by malicious
   organisations.  Therefore is it strongly recommended to install
   traffic filters, IDSs and IPSs at the perimeter of the tunneled
   network infrastructure."
Could you please elaborate on what you mean with "perimeter of the tunneled network infrastructure"? In particular in the case where such RNH attribute is attached to an Internet or VPN route?

"It is possible to inject a rogue BGP Remote-Next-Hop attribute to an
   NLRI resulting in Monkey-In-The-Middle attack (MITM).  To avoid this
   type of MITM attack, it is strongly recommended to use a technology a
   mechanism to verify that for NLRI it is the expected BGP Remote-Next-
   Hop. We anticipate that this can be done with an expansion of RPKI-
   Based origin validation, see [I-D.ietf-sidr-pfx-validate]."
I read that Remote NH MUST NOT be used unless the expansion of RPKI is specified, implemented and deployed. The draft is more than 2 years old and I don't see a pointer toward this extension. What is the status? How am I suppose to have an opinion of how effective is the security couter measure?

   "This does not avoid the fact that rogue AS numbers may be inserted or
   injected into the AS-Path.  To achieve protection against that threat
   BGP Path Validation should be used, see
   [I-D.ietf-sidr-bgpsec-overview]."
Do you mean that a full deployement of BGP sec must be performed before deploying remote NH? Or if partial deployment is enough, how partial? Do you mean as path validation or route leaking detection...?

"This proposal may introduce privacy issues, however with BGP security
   mechanisms in place they should be prevented."
Can you elaborate on those privacy issues, what BGP security mechanism you are referring to, and how do the address the privacy issues.

Bottom line: I think the security section needs more work and discussion on the mailing list. I'm not convinced that remote NH is deployable (unless in private closed controlled environment. In which case, I would call for a non transitive attribute, attribute filtering by default (inband & outband))

2) Medium
2.1) IPv6 dual homing
- The description of the solution lacks details. Could you possibly add a network topology, with the involved routes? In particular how does the provider learn the backup/alternate route. (advertising it in the Internet is the most simple but would require de-aggregating the prefix which contradicts the goal; alternatively advertising directly between ASBR remove the need for Remote Next Hop).
- Many IETF solutions have been proposed for IPv6 multi-homing. It would be interesting to cite them and state why this proposition is better. (I guess that LISP may be applicable if so it may be interesting to present your comparison with LISP in the LISP WG).
- "[In the Internet] Each AS prefers to only announce a superset of all its assigned IPv6 prefixes, unlike IPv4 where the AS announced the end-users assigned prefix"
  - On my side, I don't see much difference between IPv4 and IPv6. 
  - "prefers" is a debatable choice of word (as some/most ASes don't care that much; and what would be their incentive for this preference?).

2.2 & 2.3)
I'm not familiar with the use case but its scope seems to be within a Service Provider. In such context, wouldn't be possible to use the normal BGP Next Hop?

2.2) section 6
This section proposes a BGP extension, but does not specify it. How is the WG supposed to have an opinion on it? Seems a kind of blank check. Seems related to security so looks important to me.

2.3) inter WG coordination
"The BGP Remote-Next-Hop extension allows signaling tunnel
   encapsulations needed to build and dynamically create an overlay
   tunneled network with traffic isolation and virtual private networks"

In short: Remote Next-Hop is a BGP based IP VPN solution.
Shouldn't the L3 VPN be involved in WG adoption? Has it been presented in L3 VPN? (haven't seen it in the agenda of the 4 latest meeting.) What has been their feedback?
Shouldn't we delay adoption until the new BESS WG is formed? " BGP Enabled ServiceS (L3VPN, L2VPN, NVO3)" 

2.4) transitive attribute
"This document defines a new BGP transitive attribute"
Does it really have to be transitive? At this point, it's not clear from the use cases. A non transitive attribute would be easier to deal with from a security standpoint.

3) Low
3.1) could you please add a section about error handling? (what is an error, how it must be handled) Indeed, this is not a simple attribute hence the case of error may not be simple either.

3.2) MPLSoUDP
What about adding the tunnel type MPLS over UDP?

> From: Idr [mailto:[email-masked]] On Behalf Of John Scudder > Sent: Tuesday, July 22, 2014 3:43 PM
> 
> Folks,
> 
> allocation of the path attribute code point. As a reminder, RFC 7120 requires
> that for early allocation, "the specifications of these code points must be
> stable". (Section 2.c.) The chairs and ADs also have to "judge that there is
> It's fine to be in favor of WG adoption but opposed to early allocation at this
> time, or in favor of both, or against both. Being against adoption but in favor
> of allocation would be a bit weird. :-)
> 
> Thanks,
> 
> --John
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 28 Jul 2014 16:42:57 -0400

> Please find below some more detailed comments.

[Many fine points elided.]

I share similar reservations with Bruno.  I don't think the draft is clear
enough for me to feel comfortable with adopting this draft yet.  I am even
less comfortable requesting early code point assignment. 

I'd like to see the following general points addressed prior to adding my
support:

- Cover the use cases of how the remote NHs are used by BGP
- What is the interaction with the actual nexthop attribute?
- This is optional-transitive.  What procedure is used to avoid leaking this
  information further than desired?
- How does this interact with the encaps safi draft? 
- Third-party nexthops are already painful with respect to reachability
  blackholes.  What mechanisms are intended, if any, to mitigate that?
- Similarly, what sort of IGP distance validation is expected for this in
  BGP tie-breaking?  None and leave it to the regular nexthop?  Does that
  even make sense?

- And please don't leave a big TBD in the community section when it seems
  very likely you have a Nifty Idea about what to do here. :-)

I'm exceedingly sensitive to early assignment without some plan for how to
handle versioning as the draft is developed and deployed in early stages.
Please also give a plan on how to handle such versioning issues.

For what it's worth, this does appear it will be useful.  I'm looking
forward to seeing the next version.

-- Jeff

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 29 Jul 2014 06:43:37 +0000

I have the same reservation as Bruno, Yakov and Jeff.

Besides the comments made by Bruno, Yakov and Jeff, I hope the authors could consider the following comments (http://www.ietf.org/mail-archive/web/idr/current/msg13444.html) as well.

Best regards,
Xiaohu

> From: Idr [mailto:[email-masked]] On Behalf Of Jeffrey Haas
> Sent: Tuesday, July 29, 2014 4:43 AM
> To: [email-masked]
> Cc: idr@ietf. org
> > I'm afraid that, as per my current understanding of the draft, I do not think
> that this version of the draft is ready for WG adoption.
> I share similar reservations with Bruno.  I don't think the draft is clear enough
> for me to feel comfortable with adopting this draft yet.  I am even less
> comfortable requesting early code point assignment.
> 
> For what it's worth, this does appear it will be useful.  I'm looking forward to
> seeing the next version.
> 
> -- Jeff
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 29 Jul 2014 14:18:44 -0400

>   blackholes.  What mechanisms are intended, if any, to mitigate that?

As a clarification, this was about how a remote nexthop has similar
reachability issues to third party nexthops.

>   very likely you have a Nifty Idea about what to do here. :-)

I had a long conversation with Keyur about the above concerns.  While after
that conversation I'm a lot more comfortable knowing what the feature is
going to be *for*, that's not how the draft is currently written.  As we
discussed, I'd like to see the next rev before addming my support for the
draft.

The security issues are still spooky but in the expected use cases probably
managable.

-- Jeff

---

From: Eric Rosen <[email-masked]>
Date: Thu, 31 Jul 2014 14:32:13 -0400

I do not support adoption of this draft in its current form.

My comments fall roughly into three categories: (a) the comparison with RFC
5512 is based on a number of apparent misunderstandings of that RFC, (b) the
description of the use cases is inadequate, and (c) the proposed mechanisms
themselves are questionable in some respects and severely underspecified in
others.

The draft states:

        The Tunnel Encapsulation attribute [RFC5512] is based on the
        principle that the tunnel end-point is the BGP speaker
        originating the update

While that is the use case that was envisioned when RFC 5512 was written, I
don't see anything in that document that prevents a BGP speaker from
originating an Encapsulation-SAFI update whose NLRI identifies a different
endpoint.

The draft further states:

        It is also assumed [by RFC 5512] that there is only a single
        tunnel between endpoints.

That is certainly not the case.

RFC 5512 defines a Tunnel Encapsulation attribute consisting of a set of
TLVs.  Each TLV identifies a tunnel type.  If there are multiple tunnels,
the attribute contains multiple TLVs.  There is nothing to prevent the
attribute from contains multiple TLVs identifying the same tunnel type, but
specifying different encapsulation information for each tunnel.  Thus not
only are multiple tunnels allowed between a pair of endpoints, but it is
even allowable to have multiple tunnels of the same type between a pair of
endpoints.  Further, each tunnel can be assigned a "color", and an individual
prefix can be matched to a particular tunnel by means of the color extended
community.

This method was chosen in order to avoid the need to send the encaps
information with each and every prefix that is to travel through the
tunnel.  Rather, it is sent only once per endpoint.  Also, with the RFC 5512
mechanisms, there is no need to modify any of the existing BGP procedures in
which the "next hop" is used, as each prefix still has just one next hop.  

With regard to the "IPv6 multi-homing use case", I just can't figure out how
the remote-next-hop attribute is supposed to be used to handle this case.
(I believe Bruno and Yakov have made the same point.)  With regard to the
other use cases, all the draft really says is "maybe this attribute would be
useful in these cases".  It does not provide anything like enough detail to
convince anyone that the attribute is a good solution for those use cases,
or that it is better than various alternatives.  When you read a section on
use cases, you should at least be able to come away with an idea of how the
proposed mechanism is intended to be used in those cases ;-) and why it is
better than some obvious alternatives.

Sections 5.6 and 5.7 appear in the "use cases" section, but do not seem to
be about use cases at all.

One can also ask many questions about the proposed attribute itself, and
about the related procedures.  (See, e.g., Bruno's and Jeff's messages in
this thread.)  Actually, the draft doesn't say much about procedures at
all. The overall problem is that each update now specifies not one, but two
next hops for each prefix, and this gives rise to a number of questions that
are not addressed in the draft.  Here are a few questions that come to mind
immediately:

- Why exactly is it necessary to have both a "next hop" and a "remote next
  hop"?

- BGP will not install a route if the next hop is not resolvable.  But there
  is nothing in the draft that says not to install a route if the remote
  next hop is not resolvable.  I don't really get this; do we really want to
  select a particular route if its next hop is resolvable but its remote
  next hop isn't?  (Especially since the data is supposed to go to the
  remote next hop.)

- Can we get into a situation where two routes have the same next hop but
  different remote next hops?  If we reach the decision process tie-breaker
  step that chooses the route with the closest next hop, we might end up
  choosing the route that does not have the closest remote next hop.  Since
  the remote next hop is where we want to send the data, does this make
  sense?

- Suppose a given route does not have a remote next hop, but when we do
  recursive resolution of the next hop we encounter a route that does have a
  remote next hop.  Are we supposed to use that remote next hop?

- When a remote next hop attribute is attached to a labeled address, do we
  assume that the label has been assigned by the remote next hop, or by the
  next hop?  If a BGP speaker changes the next hop but not the remote next
  hop, does it have to assign a new label?

- Is it even valid to change the next hop without changing or removing the
  remote next hop attribute?

- Since the remote next hop attribute is a transitive attribute, it can
  easily be leaked outside of the administrative domain to which it
  applies.  This could result in all kinds of strange effects on the routing
  upstream.  (One might point out that in the RFC 5512 model, it is less
  likely that information leaks out, since the encapsulation-SAFI would have
  to be explicitly enabled.) 

- Applicability of the remote next hop attribute is not restricted to any
  particular set of address families, but it is not obvious what if anything
  it might mean to attach the attribute to address families other than the
  unicast routing address families.

- The attribute as defined contains an AS number, but there are no
  procedures specified that make use of the AS number.

- The address family of the tunnel endpoint needs to be inferred from its
  length; it might be better to explicitly encode the address family.  

I think this draft needs both additional justification and additional detail
before it can be adopted.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 31 Jul 2014 21:00:04 +0200

Hi Eric,

Let me make one point which in fact was the reason why my former work on
remote next hop ended up merged here.

RFC5512 is fine as it is for number of applications and I do agree with
most of your observations made.

However RFC5512 the way it is written today unfortunately does not provide
a mechanism to encode the remote next hop (tunnel termination dst) without
new SAFI. That as you must very well be aware has huge deployment problem
if your information should cross N domains - which btw may have no interest
what so ever to support such SAFI.

Therefor I would like to highlight that while there are other forms such
information can be exchanged (maybe even more preferable then sending it
within BGP) spawning a new SAFI for that is unfortunately not one of them :(

Historically BGPv4 Tunnel Encapsulation Attribute
draft-kapoor-nalawade-idr-bgp-ssa-02.txt written by Ruchi & Gargi got
replaced by RFC5512 since exactly instead of using attribute within current
address families we have all decided that for applications at hand at that
time having independent SAFI is a better choice.

To conclude I would not object if we would respin RFC5512 and state that
the attribute can be used standalone as well as we add few more
encapsulations to it :)

Cheers,
R.