Route Hijacks
Folks, Can anyone point me at literature regarding the frequency and cost of BGP route hijacks? Also, please email me privately if there is any information that you can share in confidence. Ron Juniper Business Use Only
RE: SRm6 (was:SRv6)
Robert, Absolutely nothing. In fact, that is very close to what we had in mind in RFC 4797. But couldn't the same argument be used with regard to SRv6 when the network operator wants traffic to take the least-cost path from PE to PE? Ron Juniper Business Use Only From: Robert Raszuk Sent: Wednesday, September 16, 2020 5:51 PM To: Ron Bonica Cc: nanog@nanog.org Subject: Re: SRm6 (was:SRv6) [External Email. Be cautious of content] Hi Ron, > If you want an IPv6 underlay for a network offering VPN services And what's wrong again with MPLS over UDP to accomplish the very same with simplicity ? MPLS - just a demux label to a VRF/CE UDP with IPv6 header plain and simple + minor benefit: you get all of this with zero change to shipping hardware and software ... Why do we need to go via decks of SRm6 slides and new wave of protocols extensions ??? Best, Robert. On Wed, Sep 16, 2020 at 10:17 PM Ron Bonica via NANOG mailto:nanog@nanog.org>> wrote: Folks, If you want an IPv6 underlay for a network offering VPN services, it makes sense to: * Retain RFC 4291 IPv6 address semantics * Decouple the TE mechanism from the service labeling mechanism Please consider the TE mechanism described in draft-bonica-6man-comp-rtg-hdr and the service labeling mechanism described in draft-bonica-6man-vpn-dest-opt. These can be deployed on a mix and match basis. For example can deploy: * Draft-bonica-6man-vpn-dest-opt only, allowing traffic to follow the least-cost path from PE to PE. * Deploy draft-bonica-6man-vpn-dest-opt only, using a legacy method (VXLAN, RFC 4797) to label services. In all cases, the semantic of the IPv6 address is unchanged. There is no need to encode anything new in the IPv6 address. Ron Juniper Business Use Only
SRm6 (was:SRv6)
Folks, If you want an IPv6 underlay for a network offering VPN services, it makes sense to: * Retain RFC 4291 IPv6 address semantics * Decouple the TE mechanism from the service labeling mechanism Please consider the TE mechanism described in draft-bonica-6man-comp-rtg-hdr and the service labeling mechanism described in draft-bonica-6man-vpn-dest-opt. These can be deployed on a mix and match basis. For example can deploy: * Draft-bonica-6man-vpn-dest-opt only, allowing traffic to follow the least-cost path from PE to PE. * Deploy draft-bonica-6man-vpn-dest-opt only, using a legacy method (VXLAN, RFC 4797) to label services. In all cases, the semantic of the IPv6 address is unchanged. There is no need to encode anything new in the IPv6 address. Ron Juniper Business Use Only
Re: Using /126 for IPv6 router links
Chris, Discussion of draft-kohno-ipv6-prefixlen-p2p is on the IETF 6man WG mailing list. But please do chime in. Operator input very welcomed. Ron Christopher Morrow wrote: On Sat, Jan 23, 2010 at 7:52 AM, Mathias Seiler mathias.sei...@mironet.ch wrote: Hi In reference to the discussion about /31 for router links, I d'like to know what is your experience with IPv6 in this regard. I use a /126 if possible but have also configured one /64 just for the link between two routers. This works great but when I think that I'm wasting 2^64 - 2 addresses here it feels plain wrong. So what do you think? Good? Bad? Ugly? /127 ? ;) coughdraft-kohno-ipv6-prefixlen-p2p-00.txt/cough (http://tools.ietf.org/id/draft-kohno-ipv6-prefixlen-p2p-00.txt) why not just ping your vendors to support this, and perhaps chime in on v6ops about wanting to do something sane with ptp link addressing? :) -Chris
Re: ip options
Folks, I would love to see the IETF OPSEC WG publish a document on the pros and cons of filtering optioned packets. Would anybody on this list be willing to author an Internet Draft? Ron (co-director IETF OM Area) Luca Tosolini wrote: Experts, out of the well-known values for ip options: x...@r4# set ip-options ? Possible completions: range Range of values [Open a set of values any Any IP option loose-source-route Loose source route route-record Route record router-alert Router alert security Security stream-idStream ID strict-source-route Strict source route timestampTimestamp I can only think of: - RSVP using router-alert - ICMP using route-record, timestamp But I can not think of any other use of any other IP option. Considering the security hazard that they imply, I am therefore thinking to drop them. Is any other ip options used by: ospf, isis, bgp, ldp, igmp, pim, bfd? Thanks, Luca.
Re: ISP port blocking practice
Folks, I would love to see the IETF OPSEC WG publish a Best Common Practices document on ISP Port filtering. The document would capture information similar to that offered by Justin. Would anybody on this list be willing to author an Internet Draft? Ron (co-director IETF OM Area) Justin Shore wrote: Zhiyun Qian wrote: Hi all, What is the common practice for enforcing port blocking policy (or what is the common practice for you and your ISP)? More specifically, when ISPs try to block certain outgoing port (port 25 for instance), they could do two rules: 1). For any outgoing traffic, if the destination port is 25, then drop the packets. 2). For any incoming traffic, if the source port is 25, then drop the packets. I block on both generally. I block inbound and outbound for residential customers in dynamic pools. I block inbound only for residential with statically-assigned IPs. That way a customer can request (and pay for) a static IP and be able to get around out outbound SMTP block. Few companies use the MSP port (tcp/587). I'm not sure why more don't make the effort but most don't. To make up for that we allow static residential customers to evade that filter with a static IP. We still block inbound though. We also allow them to use our SMTP servers and SmartHosts if they want with no requirements on source domains (like some providers require, essentially requiring the customer to advertise for you). The inbound block isn't really all that useful as you elude to. However I use it more often than not to look for people scanning out ranges for open relays. I use that data for feed my RTBH trigger router and drop the spammer's traffic on the floor (or the poor, unfortunate owner of the compromised PC that's been 0wned. We block several other things too. Netbios traffic gets dropped both ways. MS-SQL traffic gets dropped both ways (a few users have complained about this but very few stick to their guns when you point out that their traffic is traversing the web completely unencrypted). I block default and common proxy ports such as 3128, 7212, and 6588 in both directions. Squid is too easy to misconfigure (done it myself). GhostSurf and WinGate have both been abusable as open proxies in various releases. I also block 8000, 8080 and 8081 towards the customers. These are some of our most commonly scanned ports (usually all 3 at once plus some or all of the 80xx ones). I've encountered many compromised residential CPEs that the users either enabled themselves or were enabled by default. I don't block those 3 ports on outbound flows though; too many false positives. And finally we also block several different types of ICMPs. First off we block ICMP fragments. Then we permit echo, echo-reply, packet-too-big, and time-exceeded. The rest get explicitly dropped. IPv6 will change this list dramatically. I haven't had time to research ICMPv6 thoroughly enough to say any more than that. Basically I just pick out some of the really bad ports and block them. This gives me a wealth of data with which to null-route compromised PCs scanning my networks. Also, is it common that the rules are based on tcp flags (e.g. SYN, SYN-ACK)? One would think block SYN packet is good enough. I don't get that deep into it. Forged packets of types other than SYN can still reek havoc on existing flows. I think it's better to block all and move on. Justin .
draft-iana-ipv4-examples
Folks, The IETF has recently passed draft-iana-rfc3330bis-08. This draft documents the fact that the following address ranges have been reserved for documentation: - 192.0.2.0/24 (TEST-NET-1) - 198.51.100.0/24 (TEST-NET-2) - 203.0.113.0/24 (TEST-NET-3) In addition, some authors have used 128.66.0.0/16 (TEST-B) for example purposes. There is no RFC that talks about this block, but my understanding is that IANA/ARIN have marked it as reserved. If you search the Internet you will find at least some number of examples and firewall rule sets that use this block, but I have no good idea about how widespread such usage is. What should we do about this block? Some of the potential answers include documenting its role, marking it as reserved but deprecating its use in examples, and returning it to the free pool immediately (with a warning sign about possible filtering problems). Comments? Ron
draft-iana-ipv4-examples
Folks, Please take a look at draft-iana-ipv4-examples. This draft discusses the following subnet allocations: - 192.0.2.0/24 (TEST-NET-1) - 198.51.100.0/24 (TEST-NET-2) - 203.0.113.0/24 (TEST-NET-3) RFC 1166 allocates TEST-NET-1 for use in documentation. Because the other two have been used in documentation, the current draft proposes allocating them, too. There has been some discussion of this on the IETF general mailing list. If you care about this issue, please visit the mailing list archive and check out the thread Re: Last Call: draft-iana-ipv4-examples (IPv4 Address Blocks Reserved for Documentation) to Informational RFC. Ron
draft-scholl-idr-advisory
Folks, At our Philadelphia meeting, the operator community displayed strong support for IETF draft-scholl-idr-advisory. This draft describes a BGP extension for passing free-form advisory messages between peers. The IDR WG is split regarding this draft, with enthusiasm waning. I am about to post a message to the IDR mailing list in support of this draft and would for those of you who support the draft to do likewise. In order to subscribe to the IDR WG mailing list, send a subscription request to idr-requ...@ietf.org. The subject of the messages should be subscribe. thanks, Ron
IPv4 Router Alert Option
Folks, It is my belief that many ISPs, will not accept datagrams containing the Router Alert IP option from customers. Do I have that right? I am asking so that I might better evaluate Internet drafts that would require ISPs to accept such packets. Ron Bonica
