Mailing List Archive

All, please be assured that, thanks to all PRs, cases, etc, it’s on our (Junipers) Radar and we are looking into it.

Cheers,
Melchior

> Op 1 okt. 2019 om 18:20 heeft Weber, Markus <Markus.Weber@kpn.de> het volgende geschreven:
>
> Dear all,
>
> Juniper seems to implement by now just RFC6483 behaviour for ROV
> (that is, if there's an AS_SET in the path, the origin AS can't
> be determined and as such validation result is always unknown).
> Checked on 16.1R7-S5/17.3R3-S5/18.2R3-S1.
>
> RFC6907 (7.1.8-7.1.12 - considering RFC6472) clarifies this: If
> there's a covering ROA and the announcement contains an AS_SET,
> it should be considered invalid (no matter if there's a ROA for
> e.g. a member of the AS_SET (apparently IOS XR behaviour)).
> Otherwise it's unknown (if there's an AS_SET).
>
> Our case was closed with "At this point, there isn't a plan on
> supporting RFC6907". We try to get this registered as EH request,
> but it can't harm if more people request this and get some higher
> attention from Juniper on this.
>
> What's the point? Are you doing this rPKI validation thing? Are
> you seeing & accepting for example 194.45.182.0/24 and / or
> 194.45.183.0/24? You shouldn't ... luckily these are just test
> prefixes ...
>
> ROAs 194.45.182.0/23-23,286
> ROA: 194.45.183.0/24-24,12469
>
> 194.45.182.0/24: .* 286 2858 {517}
> 194.45.183.0/24: .* 286 2858 {517 12469}
>
>
> Thanks for your time reaching out to your Juniper SE / AM.
> Markus
>
> --
> AS286 - for the time being
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Tue, Oct 01, 2019 at 10:50:29PM +0200, Melchior Aelmans wrote:
> All, please be assured that, thanks to all PRs, cases, etc, it’s on
> our (Junipers) Radar and we are looking into it.

I think we'll also all agree that no fallback to the old behavior is
needed, as the old behavior is not useful.

Kind regards,

Job
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Job,

> Op 1 okt. 2019 om 23:12 heeft Job Snijders <job@ntt.net> het volgende geschreven:
>
> I think we'll also all agree that no fallback to the old behavior is
> needed, as the old behavior is not useful.

Agreed on the usefulness part, but would there be unwanted situations or behavior someone could run into if we would ‘flip the switch’? I’m looking for possible impact due to changing behavior.

Cheers,
Melchior
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Melchior Aelmans wrote:
> All, please be assured that, thanks to all PRs, cases, etc, it’s on
> our (Junipers) Radar and we are looking into it.

Thanks, looking forward to see this showing up in the very near future/
with the next updates of all current in-use releases.

> Agreed on the usefulness part, but would there be unwanted situations
> or behavior someone could run into if we would ‘flip the switch’? I’m
> looking for possible impact due to changing behavior.

Count the number of AS_SETs seen in the DFZ, reduced to "covered by a
ROA". Consider there's RFC6472, which recommends not to use AS_SETs
anymore. Then think of how many networks would miss the new "knob" to
enable RFC6907 behaviour and by not enabling, leaving the door open
for not-so-nice activities to bypass ROV.

I think most/all of us would already drop them without questioning.
The brave of us would even drop routes with AS_SETs, if there would
be a way to easily match them. And I'm sure, the ones doing ROV would
drop routes -with AS_SET in the path and covered by a ROA- to mimic
RFC6907 behaviour ... (but this requires two things not available -
matching AS_SET and covered by a ROA).

I'm almost willing to bet, there won't be any cases because of the
changed behaviour. Maybe a few because people don't understand the
reason for the invalid in first place ... (BTW: maybe also time to
change the logging within traceoptions, as AS_SETs and empty as-paths
seem to both log "as-set detected, validation result unknown".)

You still can provide a disable-rfc6907 option, but don't have the
default be "unsecure".

Thanks again,
Markus

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> On Oct 2, 2019, at 12:37 AM, Weber, Markus <Markus.Weber@kpn.de> wrote:
>
> Melchior Aelmans wrote:
>> All, please be assured that, thanks to all PRs, cases, etc, it’s on
>> our (Junipers) Radar and we are looking into it.
>
> Thanks, looking forward to see this showing up in the very near future/
> with the next updates of all current in-use releases.
>
>> Agreed on the usefulness part, but would there be unwanted situations
>> or behavior someone could run into if we would ‘flip the switch’? I’m
>> looking for possible impact due to changing behavior.
>
> Count the number of AS_SETs seen in the DFZ, reduced to "covered by a
> ROA". Consider there's RFC6472, which recommends not to use AS_SETs
> anymore. Then think of how many networks would miss the new "knob" to
> enable RFC6907 behaviour and by not enabling, leaving the door open
> for not-so-nice activities to bypass ROV.

Yeah, this is a a chance for Juniper to have sane defaults here that will cause some routes to end up being hidden, but that is really the intended stance. If you are following the work in IETF IDR, the intent is to have these AS_SETs is likely going to end up as “treat-as-withdrawl” which is effectively the same thing.

It would be great if Juniper can help close this gap :-)

- Jared
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 1/Oct/19 18:20, Weber, Markus wrote:

>
> RFC6907 (7.1.8-7.1.12 - considering RFC6472) clarifies this: If
> there's a covering ROA and the announcement contains an AS_SET,
> it should be considered invalid (no matter if there's a ROA for
> e.g. a member of the AS_SET (apparently IOS XR behaviour)).
> Otherwise it's unknown (if there's an AS_SET).

So what is the validator's role in this decision-making?

In our validator, I see 194.45.182.0/23 from AS286 as Valid.

My IOS XR boxes have accepted the route for installation.

Mark.

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Can you show a screenshot? Not entirely sure what you are looking at.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 10/Oct/19 09:58, Job Snijders wrote:
> Can you show a screenshot? Not entirely sure what you are looking at.

The list said my screenshot was too big.

But I'm sure you got it.

Mark.

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Thu, Oct 10, 2019 at 10:19:42AM +0200, Mark Tinka wrote:
> On 10/Oct/19 09:58, Job Snijders wrote:
> > Can you show a screenshot? Not entirely sure what you are looking at.
>
> The list said my screenshot was too big.
>
> But I'm sure you got it.

Yup, I got it!

It appears there is a bug in the RIPE NCC RPKI Cache Validator, or a
visibility issue in the RIPE RIS collection mechanism. I'd suspect the
former, as RIPE RIS itself receives a fair amount of scrutiny compared
to the "BGP Preview" feature in the validator.

The full story is this:

$ bgpctl show rib 194.45.182.0/23 all
flags: * = Valid, > = Selected, I = via IBGP, A = Announced,
S = Stale, E = Error
origin validation state: N = not-found, V = valid, ! = invalid
origin: i = IGP, e = EGP, ? = Incomplete

flags ovs destination gateway lpref med aspath origin
I*> V 194.45.182.0/23 165.254.255.1 100 1001 2914 286 i
I*> ! 194.45.182.0/24 165.254.255.1 100 1001 2914 286 2858 { 517 } i
I*> ! 194.45.183.0/24 165.254.255.1 100 1001 2914 286 2858 { 517 12469 } i

The "BGP Preview" is only showing the /23, but the issue at hand is
expressed in the two /24s covered by the /23.

Kind regards,

Job
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 10/Oct/19 10:25, Job Snijders wrote:

>
> The "BGP Preview" is only showing the /23, but the issue at hand is
> expressed in the two /24s covered by the /23.

So the validator is not even showing either /24, only the /23. Could it
be implementing RFC 6907?

All of my IOS XR routers do not have the /24's in RIB, even if marked as
Invalid. So either IOS XR is implementing RFC 6907 aggressively, or the
remote side is doing the same and dropping them before I get them (which
would mean they are either running IOS XR, or are working around the
lack of this RFC in Junos).

I am seeing both /24's from all of my Junos routers.

Unfortunately, I don't have any IOS XE routers that are running RPKI
with a full BGP table, so I can't use that as a control mechanism for
Cisco's implementation.

Mark.

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Mark wrote:
> So what is the validator's role in this decision-making?

Nothing [*].

> My IOS XR boxes have accepted the route for installation.

It's not about 194.45.182.0/23. It's about 194.45.182.0/24
and 194.45.183.0/24.

These should be -according to RFC6907- considered as invalid,
not as unknown (what JunOS currently does).

Cisco XR might consider 194.45.182.0/24 as unknown or in-
valid (?), but 194.45.183.0/24 as valid (as within the
AS_SET an AS is listed, for which a matching ROA exists)
[source 7018].

The consequences on JunOS: Easy bypassing the validation
mechanism (and even works for more specifics, which you
can't do by just "spoofing" the origin AS).

Checking lg.seacomnet.com I see both /24 accepted as with
"RPKI State not found".

Markus


[*] Well, the validator should - beside validating the ROAs
- as well ensure, that the <prefix,max-length,originAS> are
"reasonable" ... ever fed <1.2.3.0/24,23,1> via rtr to JunOS
(max-length > prefix mask)? Another "hope there will never be
published ROAs passing through validators causing similar
effects" (JunOS simply takes the rtr session down when seeing
such records via rtr).

--
AS286 - for the time being ...

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Mark wrote:
> So the validator is not even showing either /24, only the /23.
> Could it be implementing RFC 6907?

https://github.com/RIPE-NCC/rpki-validator-3 ...

> All of my IOS XR routers do not have the /24's in RIB, even if
> marked as Invalid. So either IOS XR is implementing RFC 6907
> aggressively, or the remote side is doing the same and dropping
> them before I get them (which would mean they are either running
> IOS XR,

Interesting. 7018 mentioned for another prefix "2402:7500::/32.
Our IOS-XR routers see the received as-path as '2914 9924 9924 9924
{24158,131614}'. The relevant VRP authorizes only 24158 to originate
2402:7500::/32-48."

The only difference I see here for 194.45.183.0/24 is, that the
ROA is for the 2nd AS in the AS_SET, above there is (or was) a
match for the first.

> or are working around the lack of this RFC in Junos.

Any idea how to workaround this in JunOS other than building
filters "somewhere else"? I wouldn't know how to easily drop
paths with AS_SET in JunOS.

Markus
--
AS286 - still here ...
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Markus wrote:
|Mark wrote:
|> So the validator is not even showing either /24, only the /23.
|> Could it be implementing RFC 6907?
|https://github.com/RIPE-NCC/rpki-validator-3 ...

If I'm not mistaken, the RIPE validator uses

http://www.ris.ripe.net/dumps/

which lists for the two /24 test prefixes:

{517} 194.45.182.0/24 242
{517,12469} 194.45.183.0/24 241

and seems to use - Asn.parse of net.ripe.ipresource.Asn - when loading
this dump. Asn.parse uses "(?:AS)?(\\d+)(\\.(\\d+))?" to match on ASes
... and returns 517? Just a quick check ... not that good with Java ...
But let me publish a ROA for 194.45.183.0/24-24,AS517 ... then we know.

Sorry for the non j-nsp noise, should shift this conversation away from
here ...

Markus
--
AS286 - for the time being

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

> If I'm not mistaken, the RIPE validator uses
> http://www.ris.ripe.net/dumps/
> which lists for the two /24 test prefixes:
> {517} 194.45.182.0/24 242
> {517,12469} 194.45.183.0/24 241
> and seems to use - Asn.parse of net.ripe.ipresource.Asn - when loading
> this dump. Asn.parse uses "(?:AS)?(\\d+)(\\.(\\d+))?" to match on ASes
> ... and returns 517? Just a quick check ... not that good with Java ...

Wrong reading. The parser for the dumps in the RIPE validator matches input
lines against
"^\\s*([0-9]+)\\s+([0-9a-fA-F.:/]+)\\s+([0-9]+)\\s*$"
- above lines don't match and thus are not seen at all in the BGP preview
(these announcements simply don't exists in this preview ... with the
first reading they should have been visible).

Thus the absence of these announcements in the RIPE validator are not
because RFC6907 ...

> But let me publish a ROA for 194.45.183.0/24-24,AS517 ... then we know.

Still in to see if Cisco XR would not accept this.

Sorry again for the non j-nsp noise, should shift this conversation away
from here ... but I couldn't leave this wrong-with-first-shot code reading
uncommented.

Markus
--
AS286 - for the time being

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Thanks Markus. Good sleuthing.

The question that still seems to be open: how to we reject BGP
announcements that contain an AS_SET anywhere in the AS_PATH?
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 10/Oct/19 11:16, Weber, Markus wrote:

> Nothing [*].

You say that, but it would be interesting to learn why the validator
isn't seeing the Invalid path.

I'll take Job up on his observations and reach out to RIPE to understand
if they think this a bug.


> These should be -according to RFC6907- considered as invalid,
> not as unknown (what JunOS currently does).

Agree that Junos is broken.


>
> Cisco XR might consider 194.45.182.0/24 as unknown or in-
> valid (?), but 194.45.183.0/24 as valid (as within the
> AS_SET an AS is listed, for which a matching ROA exists)
> [source 7018].

IOS XR is seeing neither of the /24's, meaning that it's either doing
something right, or the remote peers are filtering it (I doubt the
latter very much).


>
> The consequences on JunOS: Easy bypassing the validation
> mechanism (and even works for more specifics, which you
> can't do by just "spoofing" the origin AS).

Yes, this is not cute at all.


>
> Checking lg.seacomnet.com I see both /24 accepted as with
> "RPKI State not found".

Those are IOS classic boxes (thanks, totally forgot I had those that
take a full feed, hehe).

So we know what that code does, which is akin to Junos.

Mark.

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 10/Oct/19 11:29, Weber, Markus wrote:

> https://github.com/RIPE-NCC/rpki-validator-3 ...

Well, we are still on 2, as we found 3 to be just a hot mess.


> Interesting. 7018 mentioned for another prefix "2402:7500::/32.
> Our IOS-XR routers see the received as-path as '2914 9924 9924 9924
> {24158,131614}'. The relevant VRP authorizes only 24158 to originate
> 2402:7500::/32-48."

So even that isn't showing up in our validator. So either there is a
bug, or a feature, at play. I'll ask RIPE.


> Any idea how to workaround this in JunOS other than building
> filters "somewhere else"? I wouldn't know how to easily drop
> paths with AS_SET in JunOS.

No idea, but I am sure one could build a filter. However, it doesn't
strike me as an immediate benefit that this has been done across both
our peers and upstreams.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 10/Oct/19 12:25, Weber, Markus wrote:

> Still in to see if Cisco XR would not accept this.

Will check again once it has done the rounds.


>
> Sorry again for the non j-nsp noise, should shift this conversation away
> from here ... but I couldn't leave this wrong-with-first-shot code reading
> uncommented.

I think it's appropriate to be on j-nsp. This is going to become an
issue for more networks as they deploy.

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 10/Oct/19 12:28, Job Snijders wrote:

> The question that still seems to be open: how to we reject BGP
> announcements that contain an AS_SET anywhere in the AS_PATH?

Aside from building a filter, bank on Juniper to fix this as they said
they would earlier in this thread.

On the Cisco side, seems like IOS (and by extension, IOS XE) are likely
broken.

IOS XR seems to be working, but I can't say for sure. Need to query
someone with clue at Cisco.

Mark.

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On Thu, Oct 10, 2019 at 2:41 PM Mark Tinka <mark.tinka@seacom.mu> wrote:

> > These should be -according to RFC6907- considered as invalid,
> > not as unknown (what JunOS currently does).
>
> Agree that Junos is broken.
>

this is being worked on as we speak.

Cheers,
Melchior
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

On 10/Oct/19 16:13, Melchior Aelmans wrote:

>
>
> this is being worked on as we speak.

This is most appreciated!

Mark.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp