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

[<[e-mail]>]

Hi all,

> The authors have requested IDR adopt draft-vandevelde-idr-remote-next-
> 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:[e-mail]] On Behalf Of John Scudder > Sent: Tuesday, July 22, 2014 3:43 PM
> 
> 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
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr

_________________________________________________________________________________________________________________________

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.