Re: IPv6 day and tunnels
On Jun 4, 2012, at 6:11 PM, Jeroen Massar wrote: On 2012-06-04 17:57, Owen DeLong wrote: [..] If you're going to redesign the header, I'd be much more interested in having 32 bits for the destination ASN so that IDR can ignore IP prefixes altogether. One can already do that: route your IPv6 over IPv4 IPv4 has 32bit destination addresses remember? :) It is also why it is fun if somebody uses a 32-bit ASN to route IPv4, as one is not making the problem smaller that way. ASNs are more used as identifiers to avoid routing loops than as actual routing parameters. Greets, Jeroen While this is true today (to some extent), it doesn't have to always be true. If we provided a reliable scaleable mechanism to distribute and cache prefix-ASN mappings and could reliably populate a DEST-AS field in the packet header, stub networks would no longer need separate ASNs to multihome and IDR routing could be based solely on best path to the applicable DEST-AS and we wouldn't even need to carry prefixes beyond the local AS border. While I don't think DNS is up to the task of reliable distribution and caching (though something somewhat similar to DNS could do the job rather well), DNS-style resource records could be used. For example, instead of using my own AS1734 as I do today, my multi-homed household could be placed in the database with pointers to my two upstream ASNs as follows: 2620:0:930::/48 AS 10 6939 AS 10 8121 192.124.40.0/23 AS 10 6939 AS 10 8121 192.159.10.0/24 AS 10 6939 AS 10 8121 Or, if I wanted to do some traffic engineering, I could tweak the preferences to be non-equal values. The router doing the DEST-AS insertion into the packet would grab the most preferred AS to which it has a valid feasible successor. I believe that the number of transit autonomous systems on the planet is much smaller than the minimum number of prefixes to represent all multi-homed organizations with independent routing policies. As such, I believe this could produce much more scalable routing with relatively little additional overhead. Owen
Re: IPv6 day and tunnels
On Jun 4, 2012, at 7:47 PM, Jimmy Hess wrote: On 6/4/12, Owen DeLong o...@delong.com wrote: [snip] Probing as you have proposed requires you to essentially do a binary search to arrive at some number n where 1280≤n≤9000, so, you end up doing something like this: [snip] So, you waited for 13 timeouts before you actually passed useful traffic? Or, perhaps you putter along at the lowest possible MTU until you [snip] Instead of waiting for 13 timeouts, start with 4 initial probes in parallel, and react rapidly to the responses you receive; say 9000,2200, 1500, 830. What's the point of an 830 probe when the minimum valid MTU is 1280? Don't wait until any timeouts until the possible MTUs are narrowed. FindLocalMTU(B,T) Let B := Minimum_MTU Let T := Maximum_MTU Let D := Max(1, Floor( ( (T - 1) - (B+1) ) / 4 )) Let R := T Let Attempted_Probes := [] While ( ( (B + D) T ) orAttempted_Probes is not Empty ) do IfR is not a member of Attempted_Probes or Retries 1 then AsynchronouslySendProbeOfSize (R) Append (R,Tries) to list of Attempted_Probes if not exists or if (R,Tries) already in list then increment Retries. Did I miss the definition of Tries and/or Retries somewhere? ;-) else T := R - 1 Delete from Attempted_Probes (R) end if ( (B +D) T )AsynchronouslySendProbeOfSize (B+ D) if ( (B + 2*D) T )AsynchronouslySendProbeOfSize (B+ 2*D) if ( (B + 3*D) T ) AsynchronouslySendProbeOfSize (B+ 3*D) if ( (B + 4*D) T ) AsynchronouslySendProbeOfSize (B+ 4*D) Shouldn't all of those be = T? Wait_For_Next_Probe_Response_To_Arrive() Wait_For_Additional_Probe_Response_Or_Short_Subsecond_Delay() Add_Probe_Responses_To_Queue(Q) Not really a Queue, more of a list. In fact, no real need to maintain a list at all, you could simply keep a variable Q and let Q=max(Q,Probe_response) R := Get_Largest_Received_Probe_Size(Q) Which would allow you to eliminate this line altogether and replace R below with Q. If ( R T ) then T := R end If ( R B ) then B := R D := Max(1, Floor( ( (R - 1) - (B+1) ) / 4 )) end done Result := B # If you receive the response at n=830 first, then wait 1ms and send the next 4 probes 997 1164 1331 1498, and resend the n=1500 probe If 1280 is what the probe needs to detect. You'll receive a response for 1164 , so wait 1ms then retry n=1498 next 4 probes are 1247 1330 1413 1496 if 1280 is what the probe needs to detect, You'll receive a response for 1247, so wait 1ms resend n=1496 next 4 probes are 1267 1307 1327 1347 if 1280 is what you neet to detect, you'll receive response for 1267, so retry n=1347 wait 1ms next 4 probes are: 1276 1285 1294 1303 next 4 probes are: 1277 1278 1279 1280 next 2 parallel probes are: 1281 1282 You hit after 22 probes, but you only needed to wait for n=1281 n=1282 and their retry to time out. But that's a whole lot more packets than working PMTU-D to get there and you're also waiting for all those round trips, not just the 4 timeouts. The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at 100ms is 2.2 seconds. That's a long time to go without first data packet passed, Owen
Re: NOC presentations
On 2012-06-04 12.46, Stefan Liström wrote: Hi all, In TF-NOC we have been collecting information about NOCs for some time now[1]. Most of the NOCs are from research and educational organizations and we think it would also be very interesting to get the same kind of information from commercial NOCs. I understand that many commercial companies might not be able to share this information, but I thought it might be worth asking. If you would like to share information about your NOC please check out our presentation template[2] for inspiration and let me know. Even if you are not able to share information about your NOC the information we have gathered will hopefully still be interesting for you. [1] http://www.terena.org/activities/tf-noc/nocs.html [2] http://www.terena.org/activities/tf-noc/TF-NOC-flashpresentation-v2.ppt Hi again, Got an off list reminder about the great NOC list at Puck: http://puck.nether.net/netops/nocs.cgi I forgot to mention that if you know any other groups of people that collect and publish information about NOCs I'd love to hear about it. But I also wanted to clarify that we are not trying to create a contact list for NOCs. We are more aiming at getting to know how different NOCs work. E.g. if you are responsible for a hybrid network a certain size or a distributed NOC what kind of tools and procedures do you find useful. So that other NOCs in a similar situation can be inspired and get useful tips on how they could improve their network operations. -- Best regards Stefan Liström
Re: IPv6 day and tunnels
Owen DeLong wrote: But that's a whole lot more packets than working PMTU-D to get there and you're also waiting for all those round trips, not just the 4 timeouts. The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at 100ms is 2.2 seconds. That's a long time to go without first data packet passed, Owen Yes, it is quite nice when ICMP helpfully informs you what your MTU is. However, we have known for quite some time that is simply not reliable on the IPv4 internet, for a multitude of reasons, with intentional ICMP blocking just one of them. I have no reason to expect it to work better in IPv6. This is why more reliable methods are a good idea, even if they work slower or add more overhead, because as I see it they are intended to be used concurrently with ICMP. Also, as I understand the probing, getting data through happens much faster then arriving at the optimal mtu size might take. Perhaps short flows should just be sticking to the min-mtu anyways. Joe
Re: ATT DSL IPv6
Probably, you were using Teredo or some other method to use IPv6. BTW if you have a Cisco gateway I have a blog post on how to set up a dynamic tunnel with HE. While native IPv6 would be best, the tunnel should work for you as I also have Bellsouth/ATT DSL. http://www.brianraaen.com/2011/10/21/dynamic-he-tunnel-and-dyndns/ Brian Raaen Zcorum Network Architect On Mon, Jun 4, 2012 at 8:35 PM, Grant Ridder shortdudey...@gmail.com wrote: Hi Everyone, Does anyone know about IPv6 on ATT residential DSL circuits? About 8 or 9 months ago i ran through several IPv6 tests (http://test-ipv6.iad.vr.org/) and they all passed. With all the talk of IPv6 day over the past week i decided to run it again just out of curiosity. However to my surprise, it is returning the result of IPv4 only now. Any ideas why they would have rolled back IPv6? Thanks, Grant
Our first inbound email via IPv6 (was spam!)
In preparation for the World IPv6 Launch, inbound (SMTP) email to the comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC. Roughly one minute later, at 9:35:30 UTC we received our first inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail was spam, and was caught by our Cloudmark messaging anti-abuse platform (the sender attempted a range of standard spam tactics in subsequent connections). In the past several hours we have of course seen other messages from a range of hosts, many of which were legitimate email so it wasn't just spam! ;-) Since the Internet is of course more than just the web, we encourage others to start making non-HTTP services available via IPv6 as well. Jason Livingood Comcast
Re: Our first inbound email via IPv6 (was spam!)
Jason, In preparation for the World IPv6 Launch, inbound (SMTP) email to the comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC. Roughly one minute later, at 9:35:30 UTC we received our first inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail was spam, and was caught by our Cloudmark messaging anti-abuse platform (the sender attempted a range of standard spam tactics in subsequent connections). You specificly tell 'inbound' ... by that you mean the MX record was added. But just to be sure. Comcast is also sending out over IPv6 now right? And if so, what protocol is preferred by default? Outgoing mail over IPv4 or over IPv6? Since the Internet is of course more than just the web, we encourage others to start making non-HTTP services available via IPv6 as well. Watching logs here to see if things (at least mail for me now) will raise the next few days... Bye, Raymond.
Re: Our first inbound email via IPv6 (was spam!)
Hi! In preparation for the World IPv6 Launch, inbound (SMTP) email to the comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC. Roughly one minute later, at 9:35:30 UTC we received our first inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail was spam, and was caught by our Cloudmark messaging anti-abuse platform (the sender attempted a range of standard spam tactics in subsequent connections). In the past several hours we have of course seen other messages from a range of hosts, many of which were legitimate email so it wasn't just spam! ;-) Since the Internet is of course more than just the web, we encourage others to start making non-HTTP services available via IPv6 as well. Looking more closely... Is this still work in progress? ;; ANSWER SECTION: comcast.net.358 IN MX 5 mx3.comcast.net. comcast.net.358 IN MX 10 mx1.comcast.net. comcast.net.358 IN MX 5 mx2.comcast.net. ;; ADDITIONAL SECTION: mx2.comcast.net.6958IN A 76.96.30.116 mx3.comcast.net.358 IN A 68.87.26.147 mx1.comcast.net.358 IN 2001:558:fe14:70::22 You are now only accepting IPv6 if all IPv4 fails? Or will records for mx2 and mx3 added later? Bye, Raymond.
Re: Our first inbound email via IPv6 (was spam!)
On 2012-06-05 07:29, Raymond Dijkxhoorn wrote: [..] ;; ANSWER SECTION: comcast.net.358 IN MX 5 mx3.comcast.net. comcast.net.358 IN MX 10 mx1.comcast.net. comcast.net.358 IN MX 5 mx2.comcast.net. ;; ADDITIONAL SECTION: mx2.comcast.net.6958IN A 76.96.30.116 mx3.comcast.net.358 IN A 68.87.26.147 mx1.comcast.net.358 IN 2001:558:fe14:70::22 You are now only accepting IPv6 if all IPv4 fails? Or will records for mx2 and mx3 added later? Though it can work, it used to be a really bad idea as there where a couple of SMTP systems (Communigate Pro being one of them I recall) which just failed when not seeing an A on an MX, this as they did not understand IPv6... There is bound to be other systems that are broken like that that will not failover to the secondary MX, as such, you might want to add an IPv4 address there too just in case. Greets, Jeroen
Re: ipv6 book recommendations?
On Jun 5, 2012, at 9:29 PM, David Hubbard wrote: security practices http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945 http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton
RE: IPv6 day and tunnels
A quick comment on probes. Making the tunnel ingress probe is tempting but fraught with difficulties; believe me, I have tried. So, having the tunnel ingress fragment when necessary in conjunction with the original source probing is the way forward, and we should advocate both approaches. RFC4821 specifies how the original source can probe with or without tunnels in the path. It does not have any RTT delays, because it starts small and then tries for larger sizes in parallel with getting the valuable data through without loss. Thanks - Fred fred.l.temp...@boeing.com
Re: Our first inbound email via IPv6 (was spam!)
Op 5-6-2012 16:10, Livingood, Jason schreef: In preparation for the World IPv6 Launch, inbound (SMTP) email to the comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC. Roughly one minute later, at 9:35:30 UTC we received our first inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail was spam, and was caught by our Cloudmark messaging anti-abuse platform (the sender attempted a range of standard spam tactics in subsequent connections). In the past several hours we have of course seen other messages from a range of hosts, many of which were legitimate email so it wasn't just spam! ;-) Since the Internet is of course more than just the web, we encourage others to start making non-HTTP services available via IPv6 as well. I always wondered why (ISPs) never started with rolling out IPv6 email servers first, the fallback from 6 to 4 is transparent and invisible to the end user at a delay of a maximum of 30 seconds. I enabled v6 for my email before my website since the impact if it didn't work on the 1st try was almost nil. Still waiting for the 1st Country to top Romania' 6% deployment. I'm sure we can do better then 0.21. IMHO Asking users if they want IPv6 is the wrong way round, you enable IPv6 and then allow for opt-out in the service portal. That's basically what the Romanian ISP did. They have not gone bankrupt either, so maybe it's not all as bad as we think. Cheers, Seth
Re: ipv6 book recommendations?
Op 5-6-2012 16:29, David Hubbard schreef: Does anyone have suggestions on good books to really get a thorough understanding of v6, subnetting, security practices, etc. Or a few books. Just turned up dual stack with our peers and a test network but I'd like to be a lot more comfortable with it before looking at our customer network. I liked the O'reilly IPv6 essentials. I've read a few chapters when I needed it. Cheers, Seth
Re: ipv6 book recommendations?
I believe that Silvia Hagan's book [1] is still the primary reference available, but there are others reviewed here: http://getipv6.info/index.php/Book_Reviews. Cheers, ~Chris PS - Shameless plug: If you're running Juniper, I wrote two books for them that you can get for free [2][3]. And I have an intro to IPv6 done in four parts on my blog as well (read from the bottom up) [4]. [1] - http://shop.oreilly.com/product/9780596100582.do [2] - http://chrisgrundemann.com/index.php/2010/day-exploring-ipv6/ [3] - http://chrisgrundemann.com/index.php/2011/day-advanced-ipv6-configuration/ [4] - http://chrisgrundemann.com/index.php/category/ipv6/introducing-ipv6/ On Tue, Jun 5, 2012 at 8:33 AM, Dobbins, Roland rdobb...@arbor.net wrote: On Jun 5, 2012, at 9:29 PM, David Hubbard wrote: security practices http://www.ciscopress.com/bookstore/product.asp?isbn=1587055945 http://www.ciscopress.com/bookstore/product.asp?isbn=1587053365 --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton -- @ChrisGrundemann http://chrisgrundemann.com
New routing systems (Was: IPv6 day and tunnels)
On 2012-06-04 23:06, Owen DeLong wrote: On Jun 4, 2012, at 6:11 PM, Jeroen Massar wrote: On 2012-06-04 17:57, Owen DeLong wrote: [..] If you're going to redesign the header, I'd be much more interested in having 32 bits for the destination ASN so that IDR can ignore IP prefixes altogether. One can already do that: route your IPv6 over IPv4 IPv4 has 32bit destination addresses remember? :) It is also why it is fun if somebody uses a 32-bit ASN to route IPv4, as one is not making the problem smaller that way. ASNs are more used as identifiers to avoid routing loops than as actual routing parameters. Greets, Jeroen While this is true today (to some extent), it doesn't have to always be true. If we provided a reliable scaleable mechanism to distribute and cache prefix-ASN mappings and could reliably populate a DEST-AS field in the packet header, stub networks would no longer need separate ASNs to multihome and IDR routing could be based solely on best path to the applicable DEST-AS and we wouldn't even need to carry prefixes beyond the local AS border. The problem here does not lie with the fact that various of these systems (LISP comes to mind amongst others) have been well researched and implemented already, but with the fact that the general operator community will not change to such a new system as it is not what they are used to. Greets, Jeroen
Re: Our first inbound email via IPv6 (was spam!)
On 6/5/12 10:22 AM, Raymond Dijkxhoorn raym...@prolocation.net wrote: You specificly tell 'inbound' ... by that you mean the MX record was added. But just to be sure. Comcast is also sending out over IPv6 now right? And if so, what protocol is preferred by default? Outgoing mail over IPv4 or over IPv6? Outbound SMTP will be enabled very soon (likely within 24 hours). - Jason
Re: Our first inbound email via IPv6 (was spam!)
Hi! Seth, In the past several hours we have of course seen other messages from a range of hosts, many of which were legitimate email so it wasn't just spam! ;-) Since the Internet is of course more than just the web, we encourage others to start making non-HTTP services available via IPv6 as well. I always wondered why (ISPs) never started with rolling out IPv6 email servers first, the fallback from 6 to 4 is transparent and invisible to the end user at a delay of a maximum of 30 seconds. I enabled v6 for my email before my website since the impact if it didn't work on the 1st try was almost nil. Still waiting for the 1st Country to top Romania' 6% deployment. I'm sure we can do better then 0.21. IMHO Asking users if they want IPv6 is the wrong way round, you enable IPv6 and then allow for opt-out in the service portal. That's basically what the Romanian ISP did. They have not gone bankrupt either, so maybe it's not all as bad as we think. I think its pretty simple. Many do this, but protection is little. Abuse also but that may change. To get to the point. There are no widely available IPv6 blacklists. Like you are used to have on IPv4. Might be a legitimate reason ... Lets see how Comcast does. Bye, Raymond.
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Monday, June 04, 2012 4:40 PM To: Templin, Fred L; nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: I'm not sure that a randomly-chosen skip value is even necessary. It is not necessary, because, for ID uniqueness fundamentalists, single event is bad enough and for most operators, slight possibility is acceptable. Outer fragmentation cooks the tunnel egresses at high data rates. Have egresses with proper performance. That's the proper operation. How many core routers would be happy to reassemble at line rates without a forklift upgrade and/or strong administrative tuning? End systems are expected and required to reassemble on their own behalf. That is not a proper operation of tunnels. Why not? Thus, don't insist on having unique IDs so much. Non-overlapping fragments are disallowed for IPv6, but I think are still allowed for IPv4. So, IPv4 still needs the unique IDs by virtue of rate limiting. Even though there is no well defined value of MSL? MSL is well defined. For TCP, it is defined in RFC793. For IPv4 reassembly, it is defined in RFC1122. For IPv6 reassembly, it is defined in RFC2460. I'm talking about not protocol recommendation but proper operation. I don't see any operational guidance recommending the tunnel ingress to configure an MRU of 1520 or larger. I'm talking about not operation guidance but proper operation. The tunnel ingress cannot count on administrative tuning on the egress - all it can count on is reassembly of 1500 or smaller and it can't count on good performance even at those levels. Proper operators can, without any guidance, perform proper operation. No amount of proper operation can fix a platform that does not have adequate performance. And, there is no way for the tunnel ingress to tell what, if any, mitigations have been applied at the egress. Thanks - Fred fred.l.temp...@boeing.com Masataka Ohta
Re: Our first inbound email via IPv6 (was spam!)
On 6/5/12 10:33 AM, Jeroen Massar jer...@unfix.org wrote: Though it can work, it used to be a really bad idea as there where a couple of SMTP systems (Communigate Pro being one of them I recall) which just failed when not seeing an A on an MX, this as they did not understand IPv6... There is bound to be other systems that are broken like that that will not failover to the secondary MX, as such, you might want to add an IPv4 address there too just in case. Thanks for the advice. You are seeing inbound records in the very first stage. More RRs are coming. The next 24-48 hours around World IPv6 Launch will be interesting. Jason
Re: IPv6 day and tunnels
In message e1829b60731d1740bb7a0626b4faf0a65d374a8...@xch-nw-01v.nw.nos.boeing .com, Templin, Fred L writes: A quick comment on probes. Making the tunnel ingress probe is tempting but fraught with difficulties; believe me, I have tried. So, having the tunnel ingress fragment when necessary in conjunction with the original source probing is the way forward, and we should advocate both approaches. RFC4821 specifies how the original source can probe with or without tunnels in the path. It does not have any RTT delays, because it starts small and then tries for larger sizes in parallel with getting the valuable data through without loss. It's useful for TCP but it is not a general solution. PTB should not be being blocked and for some applications one should just force minimum mtu use. Thanks - Fred fred.l.temp...@boeing.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
RE: IPv6 day and tunnels
The proper solution is to have a field in IPv7 header to measure PMTU. It can be a 8 bit field, if fragment granularity is 256B. We tried that for IPv4 and it didn't work very well [RFC1063]. You are welcome to try again in IPv7 when we have a green field. Fred fred.l.temp...@boeing.com
Penetration Test Assistance
Howdy all, I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a complete network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? Thanks, Tim This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
RE: IPv6 day and tunnels
-Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Tuesday, June 05, 2012 7:55 AM To: Templin, Fred L Cc: Owen DeLong; Jimmy Hess; nanog@nanog.org Subject: Re: IPv6 day and tunnels In message E1829B60731D1740BB7A0626B4FAF0A65D374A86CB@XCH-NW- 01V.nw.nos.boeing .com, Templin, Fred L writes: A quick comment on probes. Making the tunnel ingress probe is tempting but fraught with difficulties; believe me, I have tried. So, having the tunnel ingress fragment when necessary in conjunction with the original source probing is the way forward, and we should advocate both approaches. RFC4821 specifies how the original source can probe with or without tunnels in the path. It does not have any RTT delays, because it starts small and then tries for larger sizes in parallel with getting the valuable data through without loss. It's useful for TCP but it is not a general solution. PTB should not be being blocked and for some applications one should just force minimum mtu use. Any packetization layer that is capable of getting duplicate ACKs from the peer can do it. Plus, support for just TCP is all that is needed for the vast majority of end systems at the current time. Thanks - Fred fred.l.temp...@boeing.com Thanks - Fred fred.l.temp...@boeing.com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Our first inbound email via IPv6 (was spam!)
On Tuesday, June 5, 2012 at 3:42 PM, Seth Mos wrote: Op 5-6-2012 16:10, Livingood, Jason schreef: I enabled v6 for my email before my website since the impact if it didn't work on the 1st try was almost nil. Still waiting for the 1st Country to top Romania' 6% deployment. I'm sure we can do better then 0.21. IMHO Asking users if they want IPv6 is the wrong way round, you enable IPv6 and then allow for opt-out in the service portal. That's basically what the Romanian ISP did. They have not gone bankrupt either, so maybe it's not all as bad as we think. It is actually opt-in. But they've advertised it a lot in the months before mass deployment and their user base was educated and willing enough to toggle the knob. -- PacketDam: a cost-effective software solution against DDoS
Re: Penetration Test Assistance
On Tue, Jun 5, 2012 at 10:52 AM, Green, Timothy timothy.gr...@mantech.com wrote: Howdy all, I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a complete network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? Thanks, Tim Any penetration test should only require your networks and masks. As far as a diagram it is of value to keep a staff member with the singular task of documentation and auditing or an optional contract basis. Small things like typographical errors can cause great confusion in emergency situations. Take the time and do it right. I personally prefer the flexibility and ease of use that Mediawiki offers but other free and pay solutions exist. -- ~ Andrew lathama Latham lath...@gmail.com http://lathama.net ~
Re: Penetration Test Assistance
On Tue, 5 Jun 2012, Green, Timothy wrote: I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a complete network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. As someone who is charged with both engineering and maintaining the records and diagrams of a large network, I take exception to the word 'lazy' ;) Network engineers tend to be an over-worked lot, and their work is often interrupt-driven, so large blocks of time to work on a single task are often a rarity. The issue is that if they haven't kept their diagrams up to date (many people don't, unfortunately), then getting them up to date turns into a much more labor-intensive job. If they have kept the diagrams up to date and they're just not getting them to you, then take the issue up with their manager. There might also be the question of how much information they are allowed to release to third parties, even if it is for a pentest. This could mean that some information might need to be removed or redacted from the diagrams. Again, the engineering manager/director/CIO/CTO might be able to provide clarification on this. I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? From what I've seen, in-depth pentests are often done in coordination with other groups, such as engineering/ops. In a large network, that's often done out of necessity, if for no other reason than dealing with issues like the ones you've raised (logistics, communication, etc...). What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? I don't have any pentest horror stories, but sometimes large network diagrams have to be broken up into pieces, to maintain some degree of readability. Large diagrams can get cluttered very quickly if you try to put every minute piece of detail on them. I tend to treat the main diagram as a high-level view of the network, and then either break out sections that need more detail as a separate drawing, or as a link to our internal knowledge base that can go into very high detail, including pictures, access information, etc. There is no right way to diagram every network. It depends on what best suits your needs, and what established proceures are already in place. jms
Re: Penetration Test Assistance
A complete diagram makes their life easier, may make for a more complete test, but they are working for you, so if you don't have it, you don't have. I'm not a big fan of having a single diagram with everything laid out anyway, but I'm from the old shcool. -jim On Tue, Jun 5, 2012 at 11:52 AM, Green, Timothy timothy.gr...@mantech.com wrote: Howdy all, I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a complete network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? Thanks, Tim This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
Re: Our first inbound email via IPv6 (was spam!)
On 6/5/2012 7:42 AM, Seth Mos wrote: Op 5-6-2012 16:10, Livingood, Jason schreef: In preparation for the World IPv6 Launch, inbound (SMTP) email to the comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC. Roughly one minute later, at 9:35:30 UTC we received our first inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail was spam, and was caught by our Cloudmark messaging anti-abuse platform (the sender attempted a range of standard spam tactics in subsequent connections). In the past several hours we have of course seen other messages from a range of hosts, many of which were legitimate email so it wasn't just spam! ;-) Since the Internet is of course more than just the web, we encourage others to start making non-HTTP services available via IPv6 as well. I always wondered why (ISPs) never started with rolling out IPv6 email servers first, the fallback from 6 to 4 is transparent and invisible to the end user at a delay of a maximum of 30 seconds. My email will come in via IPv6 as soon as Postini has IPv6 inbound and outbound. As far as I can tell, they still have neither, despite requests going back to 2009. Matthew Kaufman
Re: Penetration Test Assistance
On 6/5/12 07:52 , Green, Timothy wrote: Howdy all, I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a complete network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? Logical diagrams tend to elide the information consider unnecessary for them to be suitably informative. An ethernet switch with 560 network segments radiating out from it may be accurate but not all that easy to parse or use. Documentation needs to be sufficiently accurate and appropiate to the tasks at hand, so it may be that you don't have what you need or perhaps you do. Thanks, Tim This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
IPv6 Facebook
Hello, Somewhere from GlobalCrossing/Level3 here to contact me off list? Here from Brazil we are going thru Europe to reach the Facebook on USA. # mtr -c 100 -wr www.facebook.com HOST: border02.scr Loss% Snt Last Avg Best Wrst StDev 1.|-- removed 2.|-- removed 3.|-- 2804:1b0:1000:4e05:: 0.0% 1004.0 7.3 3.1 202.1 24.7 4.|-- 2001:450:2002:448::1 0.0% 100 68.5 63.8 59.4 79.5 5.4 5.|-- 2001:450:2001:800a::20.0% 100 143.0 153.3 143.0 336.8 31.8 6.|-- 2001:1900:5:3::12d 1.0% 100 323.6 328.0 323.1 427.2 14.6 7.|-- vl-4080.edge3.*Paris1*.Level3.net0.0% 100 322.3 323.7 321.9 352.9 5.1 8.|-- vl-4086.car1.Washington1.Level3.net 1.0% 100 348.0 356.8 341.0 570.6 36.0 9.|-- vl-60.edge3.Washington4.Level3.net 0.0% 100 337.1 339.6 336.5 373.2 6.9 10.|-- FACEBOOK-IN.edge3.Washington4.Level3.net 0.0% 100 341.1 344.6 340.7 400.8 12.0 11.|-- ae1.bb02.iad2.tfbnw.net 1.0% 100 337.9 339.3 336.3 385.1 8.3 12.|-- ae8.bb04.prn1.tfbnw.net 1.0% 100 403.7 404.8 403.1 445.0 5.7 13.|-- ae3.dr05.prn1.tfbnw.net 1.0% 100 403.4 404.5 402.7 455.8 6.9 14.|-- 2620:0:1cff:dead:beee::149 1.0% 100 410.6 406.5 404.4 454.2 6.3 15.|-- www6-10-08-prn1.facebook.com 1.0% 100 403.5 402.8 401.8 406.5 0.8 Regards, -- Eduardo Schoedler
Re: Penetration Test Assistance
It's not much of a penetration test, imho, if the attackers have detailed knowledge of your network and systems before the attack. You should determine what kind of a scenario you are trying to simulate, and how the results will be used to improve security. Is this a black box situation, where you want to see what potential attackers can discover about your systems without insider information? Or will this be a step by step, examine each part of the system and then step back to see what's going on from a high level scenario? If you're trying to both reduce vulnerabilities and your attack profile, I would go for the black box approach and see what your pentesters can come up with themselves. Man is a resourceful creature, and you never know what they could turn up. Q On Tue, Jun 5, 2012 at 8:52 AM, Green, Timothy timothy.gr...@mantech.comwrote: Howdy all, I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a complete network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? Thanks, Tim This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
Re: IPv6 day and tunnels
Templin, Fred L wrote: Have egresses with proper performance. That's the proper operation. How many core routers would be happy to reassemble at line rates without a forklift upgrade and/or strong administrative tuning? You don't have to do it with core routers. End systems are expected and required to reassemble on their own behalf. That is not a proper operation of tunnels. Why not? Lack of transparency. Even though there is no well defined value of MSL? MSL is well defined. For TCP, it is defined in RFC793. For IPv4 reassembly, it is defined in RFC1122. For IPv6 reassembly, it is defined in RFC2460. As you can see, they are different values. I'm talking about not operation guidance but proper operation. The tunnel ingress cannot count on administrative tuning on the egress I'm afraid you don't understand tunnel operation at all. No amount of proper operation can fix a platform that does not have adequate performance. Choosing a proper platform is a part of proper operation. Masataka Ohta
RE: Penetration Test Assistance
Not discounting the need for network diagrams, there are also differing approaches to pen testing. One alternative is a sort of black-box approach where the pen testers are given little or no advanced knowledge of the network. It is up to them to 'discover' what they can through open source means and commence their attacks from what they glean from their intelligence gathering. This way they are realistically mimicking the hacker methodology. Ron Baklarz C|CISO, CISSP, CISA, CISM, NSA-IAM/IEM Chief Information Security Officer Export Control Compliance Officer National Passenger Railroad Corporation (AMTRAK) 10 G Street, NE Office 6E606 Washington, DC 20002 bakl...@amtrak.com -Original Message- From: Green, Timothy [mailto:timothy.gr...@mantech.com] Sent: Tuesday, June 05, 2012 10:53 AM To: nanog@nanog.org Subject: Penetration Test Assistance Howdy all, I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a complete network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? Thanks, Tim This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
Re: IPv6 day and tunnels
Templin, Fred L wrote: The proper solution is to have a field in IPv7 header to measure PMTU. It can be a 8 bit field, if fragment granularity is 256B. We tried that for IPv4 and it didn't work very well [RFC1063]. IP option is a bad idea, which is partly why IPv6 sucks. Masataka Ohta
Re: ipv6 book recommendations?
On Tue, Jun 5, 2012 at 7:29 AM, David Hubbard dhubb...@dino.hostasaurus.com wrote: Does anyone have suggestions on good books to really get a thorough understanding of v6, subnetting, security practices, etc. Or a few books. Just turned up dual stack with our peers and a test network but I'd like to be a lot more comfortable with it before looking at our customer network. Network Warrior. Sounds a bit silly since it's a bit of an overview of lots of different things, however it's chapters on IPV6 get right to the point and helped clear up a lot of things for me. -B
Re: Penetration Test Assistance
On 12-06-05 11:32 AM, Andrew Latham wrote: On Tue, Jun 5, 2012 at 10:52 AM, Green, Timothy timothy.gr...@mantech.com wrote: Howdy all, I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a complete network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? Thanks, Tim Any penetration test should only require your networks and masks. As far as a diagram it is of value to keep a staff member with the singular task of documentation and auditing or an optional contract basis. Small things like typographical errors can cause great confusion in emergency situations. Take the time and do it right. I personally prefer the flexibility and ease of use that Mediawiki offers but other free and pay solutions exist. Yup, a list of subnets in use on your network is all I've ever needed to provide to pen testers in the past on the few occasions I've worked with them. A good pen test should scan everything on your network anyways, with a reasonable chance of figuring out what everything is. As far as horror stories... yeah. My most memorable experience was a guy (with a CISSP designation, working for a company who came highly recommended) who: - Spent a day trying to get his Backtrack CD to work properly. When I looked at it, it was just a color depth issue in X that took about 45 seconds from why is this broken? to hey look, I fixed it!. - Completely missed the honeypot machine I set up for the test. I had logs from the machine showing that his scanning had hit the machine and had found several of the vulnerabilities, but the entire machine was absent from the report. - Called us complaining that a certain behavior that he'd never seen before was happening when he tried to nmap our network. The certain behavior was a firewall with some IPS functionality, along with him not knowing how to read nmap output. - Completely messed up the report -- three times. His report had the wrong ports vulnerabilities listed on the wrong IPs, so according to the report, we apparently had FreeBSD boxes running IOS or MS SQL... - Stopped taking our calls when we asked why the honeypot machine was completely missing from the report. In general, my experience with most pen testers is a severe disappointment, and isn't anything that couldn't be done in-house by taking the person in your department who has the most ingrained hacker/geek personality, giving them Nessus/Metasploit/nmap/etc, pizza and a big ass pot of coffee, and saying Find stuff we don't know about. Go.. There is the occasional pen tester who is absolutely phenomenal and does the job properly (i.e. the guys who actually write their own shellcode, etc), but the vast majority of pen testers just use automated tools and call it a day. Like everything else in IT, security has been commercialized to the point where finding really good vendors/people is hard, because everyone and their mom has CEH, CISSP, and whatever other alphabet soup certifications you can imagine.
Re: Penetration Test Assistance
On 6/5/12, Green, Timothy timothy.gr...@mantech.com wrote: I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a complete network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? Tim, Your system is what it is, including any defects in configuration management. Provide the testers with what you have, give them contact info for the engineers so they can ask questions and specify that you expect strengths and weaknesses in configuration management which impact system security to be reflected in their report. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: IPv6 day and tunnels
On 6/5/12, Owen DeLong o...@delong.com wrote: [snip] But that's a whole lot more packets than working PMTU-D to get there and you're also waiting for all those round trips, not just the 4 timeouts. The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at 100ms is 2.2 seconds. That's a long time to go without first data packet I'm only suggesting probing to discover the MTU between neighboring endpoints directly connected to the same subnet -- Layer 2 interconnect. PTMU doesn't work, because devices know the MTU of _their link_, but not necessarily the MTU of every intervening bridge or L2 tunnel, Not for IP end-end-to-end MTU discovery. The too big packet forwarded is just discarded by the L2 bridge, there's no ICMP packet that can result from that, the L2 bridge might not even have an IP address to source one from, so the PMTU method which relies on ICMP alone cannot possibly work. The router after discovering the local MTU constraints to its neighbors would then be responsible for sending TooBig messages as needed or passing on the MTU constraint. You've got an issue if there are 100ms between two peers on your LAN. You're right, you don't need to probe for possible MTUs below 1280. -- -JH
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Tuesday, June 05, 2012 9:37 AM To: Templin, Fred L Cc: nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: Have egresses with proper performance. That's the proper operation. How many core routers would be happy to reassemble at line rates without a forklift upgrade and/or strong administrative tuning? You don't have to do it with core routers. Tunnel endpoints can be located either nearer the edges or nearer the middle. Tunnel endpoints that are located nearer the edges might be able to do reassembly at nominal data rates, but there is no assurance of a maximum MRU greater than 1500 (which is too small to reassemble a 1500+20 packet). Tunnel endpoints that are located nearer the middle can be swamped trying to keep up with reassembly at high data rates - again, with no MRU assurances. End systems are expected and required to reassemble on their own behalf. That is not a proper operation of tunnels. Why not? Lack of transparency. Huh? Even though there is no well defined value of MSL? MSL is well defined. For TCP, it is defined in RFC793. For IPv4 reassembly, it is defined in RFC1122. For IPv6 reassembly, it is defined in RFC2460. As you can see, they are different values. RFC793 sets MSL to 120 seconds. RFC1122 uses MSL as the upper bound for reassembly buffer timeouts. IPv6 doesn't reference MSL but sets reassembly buffer timeouts to 60 seconds. Personally, I can't imagine a reassembly that takes even as long as 30seconds being of any use to the final destination even if it were to finally complete. But, if we set 60 sec as the reassembly timeout value for IPv* I'm sure we'd be OK. I'm talking about not operation guidance but proper operation. The tunnel ingress cannot count on administrative tuning on the egress I'm afraid you don't understand tunnel operation at all. I don't? Are you sure? No amount of proper operation can fix a platform that does not have adequate performance. Choosing a proper platform is a part of proper operation. This is getting tiresome. Fred fred.l.tem...@boeing.com Masataka Ohta
Fwd: [arin-announce] IPv4 Countdown Plan Update
NANOG Folks - Apologies for cross-posting, but this is very important information for all organizations about how requests for IPv4 address space will be handled as we approach runout in this region. FYI ( Thanks!) /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN i...@arin.netmailto:i...@arin.net Subject: [arin-announce] IPv4 Countdown Plan Update Date: June 5, 2012 10:06:46 AM PDT To: arin-annou...@arin.netmailto:arin-annou...@arin.net On 23 April 2012 during ARIN XXIX in Vancouver, Leslie Nobile, Director of Registration Services gave a presentation on ARIN's plan to manage the distribution of its remaining IPv4 address pool. You can view the presentation at: https://www.arin.net/participate/meetings/reports/ARIN_XXIX/webcast/nobile_ipv4_countdown.mov We received some great input and in response have made a few adjustments to the Countdown Plan. *The time window to complete payment and the RSA have been extended from 45 to 60 days. *Reinstatement of a 30 day hold period for returned, revoked and reclaimed resources during the final phase of the countdown, when ARIN supply is at or below one /8 equivalent. *The block size distribution of ARIN's remaining IPv4 inventory is now available on the page and will be updated daily. The ARIN community has worked together over the last several years in developing policy to manage how ARIN allocates and assigns IPv4 addresses. ARIN has reviewed and refined its procedures to create an IPv4 Countdown Plan explaining how IPv4 requests will be processed as the remaining IPv4 address pool is distributed. We have posted the details of the plan at: https://www.arin.net/resources/request/ipv4_countdown.html The IPv4 Countdown is a dynamic process and we will notify the community as we approach and reach the trigger points for each new phase of the plan. ARIN will be updating and adding more information to the IPv4 Countdown page as we move through this process, so we strongly encourage you to pay attention to announcements and keep track of the current IPv4 inventory by monitoring the counter on the ARIN homepage. Because the IPv4 inventory may fluctuate on a daily basis, it is not intended as a tool to guide the timing of your IPv4 resource requests. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ___ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (arin-annou...@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact i...@arin.net if you experience any issues.
Re: Penetration Test Assistance
On 5 June 2012 15:52, Green, Timothy timothy.gr...@mantech.com wrote: Howdy all, I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. I'd treat this as the first of their pen tests - a social engineering attack to obtain secret information about the network, and refuse. Aled
Re: Penetration Test Assistance
On Jun 5, 2012, at 12:52 PM, Peter Kristolaitis alte...@alter3d.ca wrote: In general, my experience with most pen testers is a severe disappointment, and isn't anything that couldn't be done in-house by taking the person in your department who has the most ingrained hacker/geek personality, giving them Nessus/Metasploit/nmap/etc, pizza and a big ass pot of coffee, and saying Find stuff we don't know about. Go.. There is the occasional pen tester who is absolutely phenomenal and does the job properly (i.e. the guys who actually write their own shellcode, etc), but the vast majority of pen testers just use automated tools and call it a day. Like everything else in IT, security has been commercialized to the point where finding really good vendors/people is hard, because everyone and their mom has CEH, CISSP, and whatever other alphabet soup certifications you can imagine. There are definitely a number of incredible pen-testers out there. But I agree with Peter… If you end up with a report that's nothing more than an executive statement pasted at the top of a Nessus report, then you've wasted your money. To be honest, I'd recommend getting a sample report from the company and quiz them on it before committing to a contract with them. --- Jason 'XenoPhage' Frisvold xenoph...@godshell.com --- Any sufficiently advanced magic is indistinguishable from technology. - Niven's Inverse of Clarke's Third Law
Re: Penetration Test Assistance
Hi Tim, A _good_ pen test team would not need a network diagram. Their first round of penetration test would have them build their own network diagram from their analysis of your network. Barry On Jun 5, 2012, at 7:52 AM, Green, Timothy wrote: Howdy all, I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a complete network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? Thanks, Tim This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
RE: Penetration Test Assistance
Seriously. --p -Original Message- From: Aled Morris [mailto:al...@qix.co.uk] I'd treat this as the first of their pen tests - a social engineering attack to obtain secret information about the network, and refuse. Aled
RE: Penetration Test Assistance
I'm with Barry--a network diagram showing everything from the pov of the pen team should be part of the end report. --p -Original Message- From: Barry Greene [mailto:bgre...@senki.org] Hi Tim, A _good_ pen test team would not need a network diagram. Their first round of penetration test would have them build their own network diagram from their analysis of your network. Barry
Re: Penetration Test Assistance
There are lots of reasons why a pentester would want a network diagram. The foremost being a point to which they can say, these are the networks that I was given as a point of reference to pentest. This is often a CYA policy for when people start complaining about the scanning that is going to occur and potentially break their systems. Cheers, Harry On 06/05/2012 02:34 PM, Darden, Patrick S. wrote: I'm with Barry--a network diagram showing everything from the pov of the pen team should be part of the end report. --p -Original Message- From: Barry Greene [mailto:bgre...@senki.org] Hi Tim, A _good_ pen test team would not need a network diagram. Their first round of penetration test would have them build their own network diagram from their analysis of your network. Barry
Re: IPv6 day and tunnels
Templin, Fred L wrote: You don't have to do it with core routers. Tunnel endpoints can be located either nearer the edges or nearer the middle. Tunnel endpoints that are located nearer the edges might be able to do reassembly at nominal data rates, but there is no assurance of a maximum MRU greater than 1500 (which is too small to reassemble a 1500+20 packet). Tunnel endpoints that are located nearer the middle can be swamped trying to keep up with reassembly at high data rates - again, with no MRU assurances. As operators know outer fragmentation is used to carry inner 1500B packets, the proper operation is to have equipments with large enough MRU. As core routers may be good at fragmentation but not particularly good at reassembly, operators do not have to insist on using core routers. I'm afraid you don't understand tunnel operation at all. I don't? Are you sure? See above. Masataka Ohta
ROVER routing security - its not enumeration
Hi, Just wanted to clarify a few things about the ROVER approach. One key misunderstanding seems to be that ROVER is an approach for enumerating all potentially valid routes. This is not the case. Slides on ROVER are posted for the NANOG 55 talk and there was an additional Lightning talk Monday in NANOG A good summary of misunderstandings are listed below and addressed below: Summarizing a few other things other people have mentioned: - The normal operating mode with RPKI is to fetch everything rather than do a point query. We've spent the last decade or so making that harder to do with DNS (blocking AXFR/IXFR, using NSEC3 instead of NSEC, etc). This makes it fairly difficult to know in advance what queries one should be asking ROVER (as Paul Vixie puts it, ROVER isn't a catalogue). When I pressed the ROVER folks about this at the Paris IETF meeting, they mumbled something about maybe walking the IRR or other external databases as a way of knowing what DNS queries to issue. ROVER's operational model is ask a question and get an answer. ROVER is not an enumeration method.RPKI does provide enumeration, but ROVER is not trying to duplicate RPKI. I think the first step is to step back and ask whether every operational model needs enumeration. For example, the talk yesterday by Level3 used the DNS and IRR did not need such an enumeration. Enumeration is not a goal in itself. There are number of operational models that provide the needed routing protection without enumeration. - Circular dependencies are a problem. Helical dependencies can be made to work, but this says that one probably should not be depending on routing to make a point query to make decisions about routing. If you look at the architecture of the existing RPKI validators (well, mine and BBN's, anyway, not sure about RIPE's but suspect they took the same approach), we've gone to some trouble to make sure that the validator will continue to work across network outages as long as the collected data haven't expired or been revoked. In theory one could do the same thing with bulk transfers of DNS (whether AXFR/IXFR or NSEC walking, if they worked) but it would not work well with point queries. Or a simpler approach that does not require bulk zone transfers or zone walking is simply DNS caching, which already exists and is well understood. More broadly, whether one calls its a cache or RPKI validator or whatever, you can build it with redundancy.One can certainly make either system work across network outages. - ROVER gives us no traction on path validation (BGPSEC), it's limited to origin validation. RPKI can certify both prefixes and ASNs, which gives it the basics needed to support path validation as well as origin validation. ASNs have no hierarchical structure, thus would be a very poor match for encoding as DNS names. The focus is on origin and sub prefix hijacks. There are certainly discussions and early experiments with future additions, but the work is focused on origin/subprefix events. - Some of the DNS aspects of ROVER are a little strange. In particular, as currently specified ROVER requires the relying party to pay attention to DNS zone cuts, which is not normal in DNS (the basic DNS model since RFC 883 has been that zones are something for the zone administrator to worry about, resolvers mostly just see a tree of RRsets). ROVER requires the relying party to check for the same data in multiple zones and pay close attention to zone cuts. While it is certainly possible to do all this, it is not a matter of issuing a simple DNS query and you're done. DNS caching effects can also complicate matters here if the zone structure is changing: think about what happens if you have cached responses to some (but not all) of the queries you need to make to figure out whether to allow a more specific route punched out of a larger prefix block. This is a misunderstanding of the ROVER approach. Multiple copies of the data do not exist in multiple zones. There is a one-to-one mapping between a prefix and a DNS name. The resolver simply finds the data and has no need to understand where zone cuts occur. On the other hand, DNS administrators do care about how they make zone cuts and delegate to their customers. They can take a /16 and delegate two /17's, or they can manage the whole thing in a single zone. Their choice. A resolver simply issues a query for the unique DNS name associated with a prefix.This could be done with anything from a complex tool set to a simply command line tool like dig. The confusion here may arise from what happens if you get an *authenticated* response saying there is no routing data at this name. This could mean 1) the prefix should not be announced or 2) the reverse DNS happens to be signed
Re: New routing systems (Was: IPv6 day and tunnels)
On Jun 5, 2012, at 7:44 AM, Jeroen Massar wrote: On 2012-06-04 23:06, Owen DeLong wrote: On Jun 4, 2012, at 6:11 PM, Jeroen Massar wrote: On 2012-06-04 17:57, Owen DeLong wrote: [..] If you're going to redesign the header, I'd be much more interested in having 32 bits for the destination ASN so that IDR can ignore IP prefixes altogether. One can already do that: route your IPv6 over IPv4 IPv4 has 32bit destination addresses remember? :) It is also why it is fun if somebody uses a 32-bit ASN to route IPv4, as one is not making the problem smaller that way. ASNs are more used as identifiers to avoid routing loops than as actual routing parameters. Greets, Jeroen While this is true today (to some extent), it doesn't have to always be true. If we provided a reliable scaleable mechanism to distribute and cache prefix-ASN mappings and could reliably populate a DEST-AS field in the packet header, stub networks would no longer need separate ASNs to multihome and IDR routing could be based solely on best path to the applicable DEST-AS and we wouldn't even need to carry prefixes beyond the local AS border. The problem here does not lie with the fact that various of these systems (LISP comes to mind amongst others) have been well researched and implemented already, but with the fact that the general operator community will not change to such a new system as it is not what they are used to. Greets, Jeroen LISP et. al requires a rather complicated deployment and would be even more complex to troubleshoot when it fails. What I am proposing could, literally, be deployed with the existing system still running as it does. The difference would be that for packets containing a dest-as field, we would (initially) have the option of routing to destination based on that field and ignoring the prefix. Later, the distribution of prefixes in BGP could be deprecated, but that would be several years off. What I am proposing is much much simpler to implement and much closer to what operators are used to than the map/encap solutions proposed to date. What I am proposing, however, requires us to add fields to the packet header (at the source), so it will take a long time to get implemented even if it ever did. Deploying it would require code updates to every router and end host and would require a new IP version number. However, the code changes at the host level would be pretty minor. Add some bits to the header and set them all to zero. The first router with full routing information and access to a populated cache or the ability to resolve dest-as for the destination prefix would populate the dest-as field. From that point until it arrived at the actual destination AS, the packet would be routed based on the best path to the AS in question. True, this would mean operators would have to revert to using an ASN to represent a common routing policy, but at most that would require some larger operators to deploy a few more ASNs. ASNs would no longer be required for what are now stub AS. It's truly unfortunate that IETF chose to drop the ball on this when IPv6 was being developed. Owen
Re: ipv6 book recommendations?
Shameless plug: Certification wise, the IPv6 Sage certification at Hurricane Electric (http://www.tunnelbroker.net) uses a practical step-by-step approach where you actually have to deploy IPv6 and make it work to progress through the steps. Owen On Jun 5, 2012, at 10:07 AM, isabel dias wrote: http://long.ccaba.upc.es/long/070Related_Activities/020Documents/IPv6_An_Internet_Revolution.pdf worth going through certification From: Seth Mos seth@dds.nl To: nanog@nanog.org Sent: Tuesday, June 5, 2012 3:45 PM Subject: Re: ipv6 book recommendations? Op 5-6-2012 16:29, David Hubbard schreef: Does anyone have suggestions on good books to really get a thorough understanding of v6, subnetting, security practices, etc. Or a few books. Just turned up dual stack with our peers and a test network but I'd like to be a lot more comfortable with it before looking at our customer network. I liked the O'reilly IPv6 essentials. I've read a few chapters when I needed it. Cheers, Seth
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Tuesday, June 05, 2012 11:36 AM To: Templin, Fred L; nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: You don't have to do it with core routers. Tunnel endpoints can be located either nearer the edges or nearer the middle. Tunnel endpoints that are located nearer the edges might be able to do reassembly at nominal data rates, but there is no assurance of a maximum MRU greater than 1500 (which is too small to reassemble a 1500+20 packet). Tunnel endpoints that are located nearer the middle can be swamped trying to keep up with reassembly at high data rates - again, with no MRU assurances. As operators know outer fragmentation is used to carry inner 1500B packets, the proper operation is to have equipments with large enough MRU. As core routers may be good at fragmentation but not particularly good at reassembly, operators do not have to insist on using core routers. I am making a general statement that applies to all tunnels everywhere. For those, specs say that all that is required for MRU is 1500 and not 1500+20. *Unless there is some explicit pre-arrangement between the tunnel endpoints*, the ingress has no way of knowing whether the egress can do better than 1500 outer packet (meaning 1480 inner packet). That is certainly the case for point-to-multipoint automatic tunnels as many of these IPv6 transition technologies are. Fred fred.l.temp...@boeing.com I'm afraid you don't understand tunnel operation at all. I don't? Are you sure? See above. Masataka Ohta
Drupal-GEO maping
Hello, I am looking for advise on mapping data in Drupal. We are building a Portal using the Drupal core. i am looking for a way to be able to map ip addresses to countries etc. Is anyone aware of any modules available that could accomplish this task. -- Sincerely; James Smith CEO, CEH, Security Analyst Email: ja...@smithwaysecurity.com Phone: 1877-760-1953 Cell Phone:1506-650-6500 Website: www.SmithwaySecurity.com Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. - This communication is confidential to the parties it was intended to serve -
Re: Drupal-GEO maping
Hi James Nice question. I am interested if someone can suggest some similar extension or some code to integrate it within Joomla too. Thanks. On Wed, Jun 6, 2012 at 12:42 AM, James Smith ja...@smithwaysecurity.comwrote: Hello, I am looking for advise on mapping data in Drupal. We are building a Portal using the Drupal core. i am looking for a way to be able to map ip addresses to countries etc. Is anyone aware of any modules available that could accomplish this task. -- Sincerely; James Smith CEO, CEH, Security Analyst Email: ja...@smithwaysecurity.com Phone: 1877-760-1953 Cell Phone:1506-650-6500 Website: www.SmithwaySecurity.com Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. - This communication is confidential to the parties it was intended to serve - -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia| Google+ https://plus.google.com/118280168625121532854
Re: IPv6 day and tunnels
On Jun 5, 2012, at 10:15 AM, Jimmy Hess wrote: On 6/5/12, Owen DeLong o...@delong.com wrote: [snip] But that's a whole lot more packets than working PMTU-D to get there and you're also waiting for all those round trips, not just the 4 timeouts. The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at 100ms is 2.2 seconds. That's a long time to go without first data packet I'm only suggesting probing to discover the MTU between neighboring endpoints directly connected to the same subnet -- Layer 2 interconnect. PTMU doesn't work, because devices know the MTU of _their link_, but not necessarily the MTU of every intervening bridge or L2 tunnel, Not for IP end-end-to-end MTU discovery. This is a horrible misconfiguration of the devices on that link. If your MTU setting on your interface is larger than the smallest MTU of any L2 forwarder on the link, then, you have badly misconfigured your system(s). Adding probing to compensate for this misconfiguration merely serves to perpetuate such errant configurations. The too big packet forwarded is just discarded by the L2 bridge, there's no ICMP packet that can result from that, the L2 bridge might not even have an IP address to source one from, so the PMTU method which relies on ICMP alone cannot possibly work. Sure... PMTU-D isn't designed to compensate for misconfigured links, it's designed to detect the path MTU based on the smallest correctly configured L3 MTU in the path. The router after discovering the local MTU constraints to its neighbors would then be responsible for sending TooBig messages as needed or passing on the MTU constraint. So you want to add an MTU setting for each L2 destination to the L2 adjacency table? This seems like a really bad idea. The better solution would be to correctly configure your link MTUs in the first place. You've got an issue if there are 100ms between two peers on your LAN. You're right, you don't need to probe for possible MTUs below 1280. LAN, sure. However, consider that there are intercontinental L2 links. Owen
Re: ROVER routing security - its not enumeration
One correction below. On Jun 5, 2012, at 12:42 PM, Daniel Massey wrote: [--snip--] I think the first step is to step back and ask whether every operational model needs enumeration. For example, the talk yesterday by Level3 used the DNS and IRR did not need such an enumeration. To clarify the above, the IRR _does_ provide an enumerated list of Candidate (IP prefix + Origin_AS) pairs. The second step is to walk through those Candidate pairs and ask DNSSEC, in question/answer process, to validate that the Candidate IRR (IP prefix, Origin_AS) pairs are authentic, or not. So, considering each step independently: the former (IRR data) is enumeration, the second is not. However, in the context of this specific operational model, the end result is an enumerated list of validated (IP Prefix, Origin_AS) pairs. -shane
Re: ROVER routing security - its not enumeration
On Tue, Jun 5, 2012 at 2:42 PM, Daniel Massey mas...@cs.colostate.edu wrote: did not need such an enumeration. Enumeration is not a goal in itself. There are number of operational models that provide the needed routing protection without enumeration. which are? I can see a use-case for something like: Build me a prefix list from the RIR data which is essentially: 1) pull IRR data for customer-X 2) validate all entries with 'resource certification' data 3) deploy new filter to edge-link-to-customer-X (only if changes occur) (shane seems to point at this as the method in question...) I think this means that the customer here has to keep updated their DNS data and their IRR data, and in the case (today) of 'ROVER' getting no-answer, the customer skates... (no validation is possible). I'm not sure you can extend usage of 'ROVER' to things which are not 'offline processed' though, and it's not clear to me that the fail-open answer is good for us, absent some signal that 'customer-x will not be playing today'. - Circular dependencies are a problem. Helical dependencies can be made to work, but this says that one probably should not be depending on routing to make a point query to make decisions about routing. If you look at the architecture of the existing RPKI validators (well, mine and BBN's, anyway, not sure about RIPE's but suspect they took the same approach), we've gone to some trouble to make sure that the validator will continue to work across network outages as long as the collected data haven't expired or been revoked. In theory one could do the same thing with bulk transfers of DNS (whether AXFR/IXFR or NSEC walking, if they worked) but it would not work well with point queries. Or a simpler approach that does not require bulk zone transfers or zone walking is simply DNS caching, which already exists and is well understood. caching implies that: 1) the cache is filled 2) the timeout on records is longer than the outage(s) 3) the timeout is still short-enough to meet user change requirements - ROVER gives us no traction on path validation (BGPSEC), it's limited to origin validation. RPKI can certify both prefixes and ASNs, which gives it the basics needed to support path validation as well as origin validation. ASNs have no hierarchical structure, thus would be a very poor match for encoding as DNS names. The focus is on origin and sub prefix hijacks. There are certainly discussions and in somewhat real-time on the router (get update, lookup dns records, decide)? or via offline compute and peer filter-updates? - Some of the DNS aspects of ROVER are a little strange. In particular, as currently specified ROVER requires the relying party to pay attention to DNS zone cuts, which is not normal in DNS (the basic DNS model since RFC 883 has been that zones are something for the zone administrator to worry about, resolvers mostly just see a tree of RRsets). ROVER requires the relying party to check for the same data in multiple zones and pay close attention to zone cuts. While it is certainly possible to do all this, it is not a matter of issuing a simple DNS query and you're done. DNS caching effects can also complicate matters here if the zone structure is changing: think about what happens if you have cached responses to some (but not all) of the queries you need to make to figure out whether to allow a more specific route punched out of a larger prefix block. This is a misunderstanding of the ROVER approach. Multiple copies of the data do not exist in multiple zones. There is a one-to-one mapping 1.23.45.10.in-addr.arpa. rover prefix entry-10.45/16 that's 2 copies... what about: 1.23.45.10.in-addr-arpa. rover-covering-route entry rover-customer-allocation-10.45.16/19 rover-customer-of-customer-allocation-10.45.23/24 that's 4 copies. between a prefix and a DNS name. The resolver simply finds the data and has no need to understand where zone cuts occur. don't I have to walk up the tree a few times in the above example though? Is this the covering route? the customer route? the customer-of-customer-route? the-hijack? Wait, no RLOCK, so this was a giant waste of time... A resolver simply issues a query for the unique DNS name associated with a prefix. This could be done with anything from a complex tool set to a simply command line tool like dig. 'resolver' here is what? router? unix-y-box-thing doing filter-generation? near-line-query/response-box for router-real-time-lookup? The convention is also useful for storing data at prefixes; geolocations is one example. not to nit-pick, but near as I can tell no one uses the geoloc entries in dns... also they aren't very well kept up to date by those few who actually do put them into dns :( (conflicting data for same prefix can appear in multiple zones, relying party has to sort this out, yum).
Re: Drupal-GEO maping
http://lmgtfy.com/?q=drupal+geo+ip http://lmgtfy.com/?q=joomla+geo+ip On Tue, Jun 5, 2012 at 3:19 PM, Anurag Bhatia m...@anuragbhatia.com wrote: Hi James Nice question. I am interested if someone can suggest some similar extension or some code to integrate it within Joomla too. Thanks. On Wed, Jun 6, 2012 at 12:42 AM, James Smith ja...@smithwaysecurity.comwrote: Hello, I am looking for advise on mapping data in Drupal. We are building a Portal using the Drupal core. i am looking for a way to be able to map ip addresses to countries etc. Is anyone aware of any modules available that could accomplish this task. -- Sincerely; James Smith CEO, CEH, Security Analyst Email: ja...@smithwaysecurity.com Phone: 1877-760-1953 Cell Phone:1506-650-6500 Website: www.SmithwaySecurity.com Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. - This communication is confidential to the parties it was intended to serve - -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Linkedin http://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia| Google+ https://plus.google.com/118280168625121532854
Re: rpki vs. secure dns?
On Mon, 28 May 2012, David Conrad wrote: As far as I can tell, ROVER is simply Yet Another RPKI Access Method like rsync and bittorrent with its own positives and negatives. Not quite. ROVER's SRO RLOCK statements have different semantics than RPKI ROAs, and there are semantics that may not be (practically) expressible in ROVER. ROVER's semantics depend on DNS zone structure. The protection offered by the RLOCK statement stops when a zone cut is reached -- longer routes are allowed unless there's an RLOCK in every descendant zone. Having DNS users care about zone structure is, to quote Rob Austein, not normal. -- Sam Weiler
Re: Drupal-GEO maping
Hi Anrag, FYI:Depending on the type of information you running joomla is not always safest bet. But I do know Drupal works well for data maping. On 12-06-05 04:36 PM, Richard Barnes wrote: http://lmgtfy.com/?q=drupal+geo+ip http://lmgtfy.com/?q=joomla+geo+ip On Tue, Jun 5, 2012 at 3:19 PM, Anurag Bhatiam...@anuragbhatia.com wrote: Hi James Nice question. I am interested if someone can suggest some similar extension or some code to integrate it within Joomla too. Thanks. On Wed, Jun 6, 2012 at 12:42 AM, James Smithja...@smithwaysecurity.comwrote: Hello, I am looking for advise on mapping data in Drupal. We are building a Portal using the Drupal core. i am looking for a way to be able to map ip addresses to countries etc. Is anyone aware of any modules available that could accomplish this task. CONFIDENTIALITY NOTICE: This communication with its contents mayeric.mo...@corp.xplornet.com contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. - This communication is confidential to the parties it was intended to serve - -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Linkedinhttp://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia| Google+https://plus.google.com/118280168625121532854 -- Sincerely; James Smith CEO, CEH, Security Analyst Email: ja...@smithwaysecurity.com Phone: 1877-760-1953 Cell Phone:1506-650-6500 Website: www.SmithwaySecurity.com Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. - This communication is confidential to the parties it was intended to serve -
Re: ROVER routing security - its not enumeration
There are number of operational models that provide the needed routing protection without enumeration. I can see a use-case for something like: Build me a prefix list from the RIR data this requires a full data fetch, not doable in dns. and, at the other end of the spectrum, for any dynamic lookup on receiving a bgp announcement, the data had best be already in the router. a full data set on an in-rack cache will go nuts on any significant bgp load. beyond that, you are in non-op space. randy
Re: Drupal-GEO maping
Hello, Generic Mapping Tools http://gmt.soest.hawaii.edu/ PostGIS http://postgis.refractions.net/ Eduardo.- Quoting James Smith ja...@smithwaysecurity.com: Hello, I am looking for advise on mapping data in Drupal. We are building a Portal using the Drupal core. i am looking for a way to be able to map ip addresses to countries etc. Is anyone aware of any modules available that could accomplish this task. -- Sincerely; James Smith CEO, CEH, Security Analyst Email: ja...@smithwaysecurity.com Phone: 1877-760-1953 Cell Phone:1506-650-6500 Website: www.SmithwaySecurity.com Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. - This communication is confidential to the parties it was intended to serve - -- Eduardo A. Suarez Facultad de Ciencias Astronómicas y Geofísicas - UNLP FCAG: (0221)-4236593 int. 172/Cel: (0221)-15-4557542/Casa: (0221)-4526589 This message was sent using IMP, the Internet Messaging Program.
Re: IPv6 day and tunnels
Templin, Fred L wrote: I am making a general statement that applies to all tunnels everywhere. General statement? Even though you assume tunnel MTU 1500B and tunnel overhead 20B? For those, specs say that all that is required for MRU is 1500 and not 1500+20. That is a requirement for hosts with Ethernet interface, which is, by no means, general and has nothing to do with tunnels. For the general argument on tunnels, see, for example, RFC2473 Generic Packet Tunneling in IPv6, where there is no requirement of 1500. Note that the RFC uses outer fragmentation: (b) if the original IPv6 packet is equal or smaller than the IPv6 minimum link MTU, the tunnel entry-point node encapsulates the original packet, and subsequently fragments the resulting IPv6 tunnel packet into IPv6 fragments that do not exceed the Path MTU to the tunnel exit-point. Masataka Ohta
Re: ROVER routing security - its not enumeration
On Tue, Jun 5, 2012 at 3:40 PM, Randy Bush ra...@psg.com wrote: There are number of operational models that provide the needed routing protection without enumeration. I can see a use-case for something like: Build me a prefix list from the RIR data this requires a full data fetch, not doable in dns. does it? shane implied (and it doesn't seem UNREASONABLE, modulo some 'doing lots of spare queries') to query for each filter entry at filter creation time, no? get-as-GOOGLE = 216.239.32.0/19 lookup-in-dns = rover-query-for-/19 + rover-query-for-/20 + rover-query-for-/21. that could be optimized I bet, but it SEEMS doable, cumbersome, but doable. the 'fail open' answer also seems a bit rough in this case (but no worse than 'download irr, upload to router, win!' which is today's model). -chris
Re: Penetration Test Assistance
On Jun 5, 2012, at 9:52 AM, Peter Kristolaitis wrote: As far as horror stories... yeah. My most memorable experience was a guy (with a CISSP designation, working for a company who came highly recommended) who: - Spent a day trying to get his Backtrack CD to work properly. When I looked at it, it was just a color depth issue in X that took about 45 seconds from why is this broken? to hey look, I fixed it!. - Completely missed the honeypot machine I set up for the test. I had logs from the machine showing that his scanning had hit the machine and had found several of the vulnerabilities, but the entire machine was absent from the report. - Called us complaining that a certain behavior that he'd never seen before was happening when he tried to nmap our network. The certain behavior was a firewall with some IPS functionality, along with him not knowing how to read nmap output. - Completely messed up the report -- three times. His report had the wrong ports vulnerabilities listed on the wrong IPs, so according to the report, we apparently had FreeBSD boxes running IOS or MS SQL... - Stopped taking our calls when we asked why the honeypot machine was completely missing from the report. In general, my experience with most pen testers is a severe disappointment, and isn't anything that couldn't be done in-house by taking the person in your department who has the most ingrained hacker/geek personality, giving them Nessus/Metasploit/nmap/etc, pizza and a big ass pot of coffee, and saying Find stuff we don't know about. Go.. There is the occasional pen tester who is absolutely phenomenal and does the job properly (i.e. the guys who actually write their own shellcode, etc), but the vast majority of pen testers just use automated tools and call it a day. Like everything else in IT, security has been commercialized to the point where finding really good vendors/people is hard, because everyone and their mom has CEH, CISSP, and whatever other alphabet soup certifications you can imagine. I agree with a lot of what you've said, but there are absolutely good security guys (pen tester, vulnerability assessors, etc) that use both open source and commercial automated tools, but still do a fantastic job because they understand the underlying technologies and protocols. I used to do a lot of this in the past, had lots of automated tools, and only occasionally wrote some assessment modules or exploit code if necessary. But again, a person in that position has to understand technology holistically (network, systems, software, protocols, etc). -b
Re: Drupal-GEO maping
The overall goal is to look similar to this but inside Drupal. ( http://wildkatzenwegeplan.geops.de/) But thanks everyone for for your input. On 12-06-05 04:36 PM, Richard Barnes wrote: http://lmgtfy.com/?q=drupal+geo+ip http://lmgtfy.com/?q=joomla+geo+ip On Tue, Jun 5, 2012 at 3:19 PM, Anurag Bhatiam...@anuragbhatia.com wrote: Hi James Nice question. I am interested if someone can suggest some similar extension or some code to integrate it within Joomla too. Thanks. On Wed, Jun 6, 2012 at 12:42 AM, James Smithja...@smithwaysecurity.comwrote: Hello, I am looking for advise on mapping data in Drupal. We are building a Portal using the Drupal core. i am looking for a way to be able to map ip addresses to countries etc. Is anyone aware of any modules available that could accomplish this task. -- Sincerely; James Smith CEO, CEH, Security Analyst Email: ja...@smithwaysecurity.com Phone: 1877-760-1953 Cell Phone:1506-650-6500 Website: www.SmithwaySecurity.com Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. - This communication is confidential to the parties it was intended to serve - -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Linkedinhttp://in.linkedin.com/in/anuragbhatia21 | Twitterhttps://twitter.com/anurag_bhatia| Google+https://plus.google.com/118280168625121532854 -- Sincerely; James Smith CEO, CEH, Security Analyst Email: ja...@smithwaysecurity.com Phone: 1877-760-1953 Cell Phone:1506-650-6500 Website: www.SmithwaySecurity.com Address: 1 Yonge Street #1801, Toronto, ON, M5E 1W7 CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication. - This communication is confidential to the parties it was intended to serve -
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Tuesday, June 05, 2012 12:42 PM To: Templin, Fred L Cc: nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: I am making a general statement that applies to all tunnels everywhere. General statement? General statement for IPv6-in-IPv4 tunneling, yes. But inner fragmentation applies equally for *-in-* tunneling. Even though you assume tunnel MTU 1500B What I am after is a tunnel MTU of infinity. 1500 is the minimum packet size that MUST get through. 1501+ packets are admitted into the tunnel unconditionally in hopes that they MIGHT get through. and tunnel overhead 20B? The size 20 represents the size of the IPv4 encaps header. The size 40 would represent the size of an IPv6 encaps header. The size foo would represent the size of some other encapsulation overhead, e.g., for IPsec tunnels, IP/UDP tunnels, etc. So, let the size of the encaps header(s) be X, substitute X for 20 everywhere and you will see that the approach is fully generally applicable. For those, specs say that all that is required for MRU is 1500 and not 1500+20. That is a requirement for hosts with Ethernet interface, which is, by no means, general and has nothing to do with tunnels. RFC2460 says the MinMRU for IPv6 nodes is 1500. RFC1122 says that IPv4 hosts should reassemble as much as their connected interfaces (1500 for Ethernet). RFC1812 says the MinMRU for IPv4 routers is 576. For the general argument on tunnels, see, for example, RFC2473 Generic Packet Tunneling in IPv6, where there is no requirement of 1500. Note that the RFC uses outer fragmentation: (b) if the original IPv6 packet is equal or smaller than the IPv6 minimum link MTU, the tunnel entry-point node encapsulates the original packet, and subsequently fragments the resulting IPv6 tunnel packet into IPv6 fragments that do not exceed the Path MTU to the tunnel exit-point. Wow - that is an interesting quote out of context. The text you quoted is describing the limiting condition to make sure that 1280 and smaller get through even if the path MTU is deficient. In that case alone, outer fragmentation is needed. My document also allows for outer fragmentation on the inner fragments. But, like the RFC4213-derived IPv6 transition mechanisms treats outer fragmentation as an anomalous condition to be avoided if possible - not a steady state operational approach. See Section 3.2 of RFC4213. Thanks - Fred fred.l.temp...@boeing.com Masataka Ohta
Re: Penetration Test Assistance
You should have a look at the Pentest Standards page, it was created by some very skilled Pen Testers how are trying to create a minimum standard for all tests and reporting. http://www.pentest-standard.org/index.php/Main_Page Also you should just have to give them your external net-block allocation that is in scope unless it is a more forced test and not a general external test. On 5 June 2012 20:48, Brett Watson br...@the-watsons.org wrote: On Jun 5, 2012, at 9:52 AM, Peter Kristolaitis wrote: As far as horror stories... yeah. My most memorable experience was a guy (with a CISSP designation, working for a company who came highly recommended) who: - Spent a day trying to get his Backtrack CD to work properly. When I looked at it, it was just a color depth issue in X that took about 45 seconds from why is this broken? to hey look, I fixed it!. - Completely missed the honeypot machine I set up for the test. I had logs from the machine showing that his scanning had hit the machine and had found several of the vulnerabilities, but the entire machine was absent from the report. - Called us complaining that a certain behavior that he'd never seen before was happening when he tried to nmap our network. The certain behavior was a firewall with some IPS functionality, along with him not knowing how to read nmap output. - Completely messed up the report -- three times. His report had the wrong ports vulnerabilities listed on the wrong IPs, so according to the report, we apparently had FreeBSD boxes running IOS or MS SQL... - Stopped taking our calls when we asked why the honeypot machine was completely missing from the report. In general, my experience with most pen testers is a severe disappointment, and isn't anything that couldn't be done in-house by taking the person in your department who has the most ingrained hacker/geek personality, giving them Nessus/Metasploit/nmap/etc, pizza and a big ass pot of coffee, and saying Find stuff we don't know about. Go.. There is the occasional pen tester who is absolutely phenomenal and does the job properly (i.e. the guys who actually write their own shellcode, etc), but the vast majority of pen testers just use automated tools and call it a day. Like everything else in IT, security has been commercialized to the point where finding really good vendors/people is hard, because everyone and their mom has CEH, CISSP, and whatever other alphabet soup certifications you can imagine. I agree with a lot of what you've said, but there are absolutely good security guys (pen tester, vulnerability assessors, etc) that use both open source and commercial automated tools, but still do a fantastic job because they understand the underlying technologies and protocols. I used to do a lot of this in the past, had lots of automated tools, and only occasionally wrote some assessment modules or exploit code if necessary. But again, a person in that position has to understand technology holistically (network, systems, software, protocols, etc). -b -- BaconZombie LOAD *,8,1
Re: Penetration Test Assistance
On 12-06-05 03:48 PM, Brett Watson wrote: On Jun 5, 2012, at 9:52 AM, Peter Kristolaitis wrote: As far as horror stories... yeah. My most memorable experience was a guy (with a CISSP designation, working for a company who came highly recommended) who: - Spent a day trying to get his Backtrack CD to work properly. When I looked at it, it was just a color depth issue in X that took about 45 seconds from why is this broken? to hey look, I fixed it!. - Completely missed the honeypot machine I set up for the test. I had logs from the machine showing that his scanning had hit the machine and had found several of the vulnerabilities, but the entire machine was absent from the report. - Called us complaining that a certain behavior that he'd never seen before was happening when he tried to nmap our network. The certain behavior was a firewall with some IPS functionality, along with him not knowing how to read nmap output. - Completely messed up the report -- three times. His report had the wrong ports vulnerabilities listed on the wrong IPs, so according to the report, we apparently had FreeBSD boxes running IOS or MS SQL... - Stopped taking our calls when we asked why the honeypot machine was completely missing from the report. In general, my experience with most pen testers is a severe disappointment, and isn't anything that couldn't be done in-house by taking the person in your department who has the most ingrained hacker/geek personality, giving them Nessus/Metasploit/nmap/etc, pizza and a big ass pot of coffee, and saying Find stuff we don't know about. Go.. There is the occasional pen tester who is absolutely phenomenal and does the job properly (i.e. the guys who actually write their own shellcode, etc), but the vast majority of pen testers just use automated tools and call it a day. Like everything else in IT, security has been commercialized to the point where finding really good vendors/people is hard, because everyone and their mom has CEH, CISSP, and whatever other alphabet soup certifications you can imagine. I agree with a lot of what you've said, but there are absolutely good security guys (pen tester, vulnerability assessors, etc) that use both open source and commercial automated tools, but still do a fantastic job because they understand the underlying technologies and protocols. I used to do a lot of this in the past, had lots of automated tools, and only occasionally wrote some assessment modules or exploit code if necessary. But again, a person in that position has to understand technology holistically (network, systems, software, protocols, etc). -b I completely agree. I didn't mean to imply that using automated tools is a bad thing -- simply that running an automated tool to pump out a report with no further investigation isn't really a useful pen test. I've seen vendors whose comprehensive penetration testing was basically We'll run Nessus against your network, write up an executive summary and email you the scan results. Quite the bargain for $20K! Automated tools are definitely good to provide a first pass over a network, but even then multiple tools should be used, and an experienced eye should review the results for anomalies (whether that's a vulnerability that has a chance for false positives, discrepancies between the results of two or more automated tools, etc). That kind of work, along with more aggressive pen tests and exploit development, need a guru meditation-level understanding of the involved technologies, protocols, etc, as you mentioned. Like everything else IT, the specific tools used are more or less immaterial to an excellent practitioner -- a good programmer can hack code in any language, a good network engineer can use any brand of network equipment, etc -- because these types of people truly understand the systems they're dealing with, and use tools to accomplish a specific task which fits into part of the big picture they have in their heads. Poor practitioners in a field use tools for the sake of using the tool (I'm scanning a network with Nessus because that's what the certification course told me to do) without that deep level of understanding, and therefore don't provide any real value to the process. - Pete
Re: Penetration Test Assistance
On Jun 5, 2012, at 11:34 AM, Darden, Patrick S. wrote: I'm with Barry--a network diagram showing everything from the pov of the pen team should be part of the end report. Maybe, maybe not. It all depends on the scope of the engagement. I've had customers ask for very specific pen test of a group of servers, or specific applications, wherein they provide all the topology, system, and network info, and just want me to look at one specific area. Then of course others want a black box assessment, wherein they don't tell you anything, and expect you to discover whatever you can discover. I'm personally very specific about scoping, and just give the customer exactly what they want but you've got to interview each other to figure all of that out. And totally agree with a previous poster, you should always get a redacted or sample report to see what kind of quality you can expect in the finished product. -b
Re: ATT DSL IPv6
After talking with someone else, i am guessing that your Toredo statement is correct. However, i don't know why that would have stopped working as it works fine when i am at school on TWTC circuit. I do not have a Cisco gateway however, i have been looking into switching to one that i have laying around. Thanks, Grant On Tue, Jun 5, 2012 at 9:06 AM, Brian Christopher Raaen mailing-li...@brianraaen.com wrote: Probably, you were using Teredo or some other method to use IPv6. BTW if you have a Cisco gateway I have a blog post on how to set up a dynamic tunnel with HE. While native IPv6 would be best, the tunnel should work for you as I also have Bellsouth/ATT DSL. http://www.brianraaen.com/2011/10/21/dynamic-he-tunnel-and-dyndns/ Brian Raaen Zcorum Network Architect On Mon, Jun 4, 2012 at 8:35 PM, Grant Ridder shortdudey...@gmail.com wrote: Hi Everyone, Does anyone know about IPv6 on ATT residential DSL circuits? About 8 or 9 months ago i ran through several IPv6 tests ( http://test-ipv6.iad.vr.org/) and they all passed. With all the talk of IPv6 day over the past week i decided to run it again just out of curiosity. However to my surprise, it is returning the result of IPv4 only now. Any ideas why they would have rolled back IPv6? Thanks, Grant
Re: ipv6 book recommendations?
And you get a t-shirt at the end! That was enough motivation for me, anyway :) -- Adam Kennedy Network Engineer Omnicity, Inc. From: Owen DeLong o...@delong.commailto:o...@delong.com To: isabel dias isabeldi...@yahoo.commailto:isabeldi...@yahoo.com Cc: nanog@nanog.orgmailto:nanog@nanog.org nanog@nanog.orgmailto:nanog@nanog.org Subject: Re: ipv6 book recommendations? Shameless plug: Certification wise, the IPv6 Sage certification at Hurricane Electric (http://www.tunnelbroker.net) uses a practical step-by-step approach where you actually have to deploy IPv6 and make it work to progress through the steps. Owen On Jun 5, 2012, at 10:07 AM, isabel dias wrote: http://long.ccaba.upc.es/long/070Related_Activities/020Documents/IPv6_An_Internet_Revolution.pdf worth going through certification From: Seth Mos seth@dds.nlmailto:seth@dds.nl To: nanog@nanog.orgmailto:nanog@nanog.org Sent: Tuesday, June 5, 2012 3:45 PM Subject: Re: ipv6 book recommendations? Op 5-6-2012 16:29, David Hubbard schreef: Does anyone have suggestions on good books to really get a thorough understanding of v6, subnetting, security practices, etc. Or a few books. Just turned up dual stack with our peers and a test network but I'd like to be a lot more comfortable with it before looking at our customer network. I liked the O'reilly IPv6 essentials. I've read a few chapters when I needed it. Cheers, Seth
Re: ROVER routing security - its not enumeration
routing protection without enumeration. I can see a use-case for something like: Build me a prefix list from the RIR data this requires a full data fetch, not doable in dns. does it? shane implied (and it doesn't seem UNREASONABLE, modulo some 'doing lots of spare queries') to query for each filter entry at filter creation time, no? what is the query set, every prefix /7-/24 for the whole fracking ABC space? that could be optimized I bet, but it SEEMS doable, cumbersome, but doable. the 'fail open' answer also seems a bit rough in this case (but no worse than 'download irr, upload to router, win!' which is today's model). irr, i do have the 'full' set. but you said RIR (the in-addr roots), not IRR. was it a mis-type? and i am not gonna put my origin data in the irr and the dns. randy
Re: New routing systems (Was: IPv6 day and tunnels)
On 2012-06-05 11:44, Owen DeLong wrote: [..] LISP et. al requires a rather complicated deployment and would be even more complex to troubleshoot when it fails. What I am proposing could, literally, be deployed with the existing system still running as it does. The difference would be that for packets containing a dest-as field, we would (initially) have the option of routing to destination based on that field and ignoring the prefix. I would love to see a more formal specification ala a IETF draft about it and/or a short preso style thing along with a comparison of existing proposals and how this is different/better. What I am proposing, however, requires us to add fields to the packet header (at the source) Well, we have IPv6 extension headers and the flow-label is still undefined too ;) Greets, Jeroen
Re: ipv6 book recommendations?
On 6/5/12, David Hubbard dhubb...@dino.hostasaurus.com wrote: Does anyone have suggestions on good books to really get a thorough understanding of v6, subnetting, security practices, etc. Or a few books. Just turned up dual stack with our peers and a test network but I'd like to be a lot more comfortable with it before looking at our customer network. Hi David, Instead of going the book route, I'd suggest getting some tunneled addresses from he.net and then working through http://ipv6.he.net/certification/ . They have the basics pretty well covered, it's interactive and it's free. Some additional thoughts: 1. Anybody who tells you that there are security best practices for IPv6 is full of it. It simply hasn't seen enough use in the environment to which we're now deploying it and rudimentary technologies widely used in IPv4 (e.g. NAT/PAT to private address space) haven't yet made their transition. 2. Subnetting in v6 in a nutshell: a. If it's a LAN, /64. Always. Stateless autoconfiguration (SLAAC) only works for /64. b. Delegations on 4-bit boundaries for reverse-DNS convenience. c. If it's a point to point, a reasonable practice seems to be a /64 per network area and around /124 per link. Works OK for ethernet point to points too. d. Default customer assignments should be /56 or /48 depending on who you ask. /48 was the IETF's original plan. Few of your customers appear to use tens of LANS, let alone thousands. Maybe that will change but the motivations driving such a thing seem a bit pie in the sky. /56 let's the customer implement more than one LAN (e.g. wired and wireless) but burns through your address space much more slowly. /60 would do that too but nobody seems to be using it. /64 allows only one LAN, so avoid it. e. sparse allocation if you feel like it. The jury is still out on whether this is a good idea. Basically, instead of assigning address blocks linearly, you divide your largest free space in half and stick the new assignment right in the middle. Good news: if the assignment later needs to grow your can probably just change the subnet mask, keeping the number of entries in the routing table the same. Bad news: fragments the heck out of your address space so when you actually need a large address block for something, you don't have it. Trying to keep non-dynamic assignments in local or regional aggregable blocks works about as well as it did in IPv4, which is to say poorly. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: ROVER routing security - its not enumeration
On Tue, Jun 5, 2012 at 5:00 PM, Randy Bush ra...@psg.com wrote: routing protection without enumeration. I can see a use-case for something like: Build me a prefix list from the RIR data this requires a full data fetch, not doable in dns. does it? shane implied (and it doesn't seem UNREASONABLE, modulo some 'doing lots of spare queries') to query for each filter entry at filter creation time, no? what is the query set, every prefix /7-/24 for the whole fracking ABC space? that could be optimized I bet, but it SEEMS doable, cumbersome, but doable. the 'fail open' answer also seems a bit rough in this case (but no worse than 'download irr, upload to router, win!' which is today's model). irr, i do have the 'full' set. but you said RIR (the in-addr roots), not IRR. was it a mis-type? oh hell :( yes, I meant IRR. and i am not gonna put my origin data in the irr and the dns. yea... so today people already fill in: RIR (swip/rwhois) IRR (routing filter updates) DNS (make sure your mailserver has PTRs!) putting origin-validation data into IRR's happens today, it's not 'secured' in any fashion, and lots of proof has shown that 'people fill it with junk' :( So being able to bounce the IRR data off some verifiable source of truth seems like a plus. How verifiable is the rdns-rover tree though? how do I get my start in that prefix hierarchy anyway? by talking to IANA? to my local RIR? to 'jimbo the dns guy down the street?' (I realize that referencing the draft would probably get me this answer but it's too hard to look that up in webcrawler that right now...) -Chris
Re: ROVER routing security - its not enumeration
putting origin-validation data into IRR's happens today, it's not 'secured' in any fashion, and lots of proof has shown that 'people fill it with junk' :( So being able to bounce the IRR data off some verifiable source of truth seems like a plus. so i should use the sow's ear as the authoritative definition of the full set? randy
Re: ROVER routing security - its not enumeration
Shane A. gave a Lightning Talk the slides for which will be posted at some time soon. They came in at the last minute which is why they're not up already. Tony On Tue, Jun 5, 2012 at 3:28 PM, Christopher Morrow morrowc.li...@gmail.comwrote: On Tue, Jun 5, 2012 at 2:42 PM, Daniel Massey mas...@cs.colostate.edu wrote: ROVER is not trying to do exactly what RPKI is doing. Much of this seems to be an attempt to build a form of enumeration into ROVER.See the Level3 NANOG talk from Monday (6/4/12) for a concrete example of a different model. There are many different you referenced this a few times: http://www.nanog.org/meetings/nanog55/agenda.php doesn't mention a talk from L3 on 6/4 ... got link? -chris
Re: IPv6 day and tunnels
Templin, Fred L wrote: General statement for IPv6-in-IPv4 tunneling, yes. But inner fragmentation applies equally for *-in-* tunneling. Even though you assume tunnel MTU 1500B What I am after is a tunnel MTU of infinity. 1500 is the minimum packet size that MUST get through. 1501+ packets are admitted into the tunnel unconditionally in hopes that they MIGHT get through. Infinity? You can't carry 65516B in an IPv4 packet. My document also allows for outer fragmentation on the inner fragments. But, like the RFC4213-derived IPv6 transition mechanisms treats outer fragmentation as an anomalous condition to be avoided if possible - not a steady state operational approach. See Section 3.2 of RFC4213. Instead, see the last two lines in second last slide of: http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf It is a common condition. Masataka Ohta
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Tuesday, June 05, 2012 2:44 PM To: Templin, Fred L; nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: General statement for IPv6-in-IPv4 tunneling, yes. But inner fragmentation applies equally for *-in-* tunneling. Even though you assume tunnel MTU 1500B What I am after is a tunnel MTU of infinity. 1500 is the minimum packet size that MUST get through. 1501+ packets are admitted into the tunnel unconditionally in hopes that they MIGHT get through. Infinity? You can't carry 65516B in an IPv4 packet. I should qualify that by saying: 1) For tunnels over IPv4, let infinity equal (2^16 - 1) minus the length of the encapsulation headers 2) For tunnels over IPv6, let infinity equal (2^32 - 1) minus the length of the encapsulation headers My document also allows for outer fragmentation on the inner fragments. But, like the RFC4213-derived IPv6 transition mechanisms treats outer fragmentation as an anomalous condition to be avoided if possible - not a steady state operational approach. See Section 3.2 of RFC4213. Instead, see the last two lines in second last slide of: http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf It is a common condition. Are you interested in only supporting tinygrams? IMHO, go big or go home! Fred fred.l.temp...@boeing.com Masataka Ohta
Re: ipv6 book recommendations?
On Jun 5, 2012, at 2:23 PM, William Herrin wrote: On 6/5/12, David Hubbard dhubb...@dino.hostasaurus.com wrote: Does anyone have suggestions on good books to really get a thorough understanding of v6, subnetting, security practices, etc. Or a few books. Just turned up dual stack with our peers and a test network but I'd like to be a lot more comfortable with it before looking at our customer network. Hi David, Instead of going the book route, I'd suggest getting some tunneled addresses from he.net and then working through http://ipv6.he.net/certification/ . They have the basics pretty well covered, it's interactive and it's free. Some additional thoughts: 1. Anybody who tells you that there are security best practices for IPv6 is full of it. It simply hasn't seen enough use in the environment to which we're now deploying it and rudimentary technologies widely used in IPv4 (e.g. NAT/PAT to private address space) haven't yet made their transition. Not quite. I will say that the security BCPs are not mature and are evolving, but that does not mean that they do not yet exist. 2. Subnetting in v6 in a nutshell: a. If it's a LAN, /64. Always. Stateless autoconfiguration (SLAAC) only works for /64. b. Delegations on 4-bit boundaries for reverse-DNS convenience. c. If it's a point to point, a reasonable practice seems to be a /64 per network area and around /124 per link. Works OK for ethernet point to points too. /64 is perfectly reasonable per point to point as well. d. Default customer assignments should be /56 or /48 depending on who you ask. /48 was the IETF's original plan. Few of your customers appear to use tens of LANS, let alone thousands. Maybe that will change but the motivations driving such a thing seem a bit pie in the sky. /56 let's the customer implement more than one LAN (e.g. wired and wireless) but burns through your address space much more slowly. /60 would do that too but nobody seems to be using it. /64 allows only one LAN, so avoid it. Planning your IPv6 deployment based on today's network needs is folly. Deploying /48s will help future-proof your network and pave the way for some very interesting innovations in the home networking space. e. sparse allocation if you feel like it. The jury is still out on whether this is a good idea. Basically, instead of assigning address blocks linearly, you divide your largest free space in half and stick the new assignment right in the middle. Good news: if the assignment later needs to grow your can probably just change the subnet mask, keeping the number of entries in the routing table the same. Bad news: fragments the heck out of your address space so when you actually need a large address block for something, you don't have it. Since you should be doing this mostly at the 4-12 bits to the right of your base allocation and the policy is structured such that you should, in most cases, be able to assign same-sized chunks everywhere at this level, that really shouldn't be an issue. Lower in the hierarchy, it's a judgement call on which optimization fits better on a case-by-case basis. Generally, the higher up the hierarchy, the more likely that allocation by bisection (there are other forms of sparse allocation as well) is ideal. In some cases, sparse allocation by reservation, for example, can reduce fragmentation while still providing substantial room for likely growth. Trying to keep non-dynamic assignments in local or regional aggregable blocks works about as well as it did in IPv4, which is to say poorly. If you apply for a large enough IPv6 block, this should be less of an issue. That was hard to do under previous policy regimes, but the current ISP allocation policy should make it pretty easy to optimize for this. Certainly, if you have suggestions for how policy can better support this, I am open to improvements at any time. Owen
Re: ipv6 book recommendations?
On Jun 5, 2012, at 2:23 PM, William Herrin wrote: 2. Subnetting in v6 in a nutshell: FWIW - There is a published BCOP on IPv6 subnetting: http://www.ipbcop.org/ratified-bcops/bcop-ipv6-subnetting/ Cheers, ~Chris -- @ChrisGrundemann http://chrisgrundemann.com
Re: ipv6 book recommendations?
On 6/5/12, Owen DeLong o...@delong.com wrote: On Jun 5, 2012, at 2:23 PM, William Herrin wrote: c. If it's a point to point, a reasonable practice seems to be a /64 per network area and around /124 per link. Works OK for ethernet point to points too. /64 is perfectly reasonable per point to point as well. Hi Owen, Sure, but with the neighbor discovery cache issues that come up with /64's under attack, why open yourself to trouble where you can't realize any benefit? Regards, Bill -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: ipv6 book recommendations?
On Jun 5, 2012, at 3:15 PM, Chris Grundemann wrote: On Jun 5, 2012, at 2:23 PM, William Herrin wrote: 2. Subnetting in v6 in a nutshell: FWIW - There is a published BCOP on IPv6 subnetting: http://www.ipbcop.org/ratified-bcops/bcop-ipv6-subnetting/ Unfortunately, this BCOP recommends /56s for residential which is potentially harmful. I'm also not a fan of the /126 or /127 on point-to-points, but, the theoretical issues of neighbor table exhaustion attacks, etc. certainly should not be ignored entirely. Owen
Re: ipv6 book recommendations?
On Jun 5, 2012, at 3:23 PM, William Herrin wrote: On 6/5/12, Owen DeLong o...@delong.com wrote: On Jun 5, 2012, at 2:23 PM, William Herrin wrote: c. If it's a point to point, a reasonable practice seems to be a /64 per network area and around /124 per link. Works OK for ethernet point to points too. /64 is perfectly reasonable per point to point as well. Hi Owen, Sure, but with the neighbor discovery cache issues that come up with /64's under attack, why open yourself to trouble where you can't realize any benefit? Why permit external traffic aimed at your point to point links at all? No external traffic, no attack surface. Owen
Re: ipv6 book recommendations?
On Jun 5, 2012, at 3:23 PM, William Herrin wrote: On 6/5/12, Owen DeLong o...@delong.com wrote: On Jun 5, 2012, at 2:23 PM, William Herrin wrote: c. If it's a point to point, a reasonable practice seems to be a /64 per network area and around /124 per link. Works OK for ethernet point to points too. /64 is perfectly reasonable per point to point as well. Hi Owen, Sure, but with the neighbor discovery cache issues that come up with /64's under attack, why open yourself to trouble where you can't realize any benefit? It makes little sense to me to permit people outside your network to deliver packets to your point to point interfaces. Denying this traffic at your borders/edges eliminates all of the attacks without having to juggle inconsistent prefix sizes or do silly bit-math to figure out which address is at the other end of the link. Owen
Re: ipv6 book recommendations?
Sure, but with the neighbor discovery cache issues that come up with /64's under attack, why open yourself to trouble where you can't realize any benefit? I happen to be a fan of /126s, but if you chose to use a /64, presumably your infrastructure ACLs would provide protection against such attacks.
Re: ipv6 book recommendations?
On Tue, Jun 5, 2012 at 4:29 PM, Owen DeLong o...@delong.com wrote: On Jun 5, 2012, at 3:15 PM, Chris Grundemann wrote: On Jun 5, 2012, at 2:23 PM, William Herrin wrote: 2. Subnetting in v6 in a nutshell: FWIW - There is a published BCOP on IPv6 subnetting: http://www.ipbcop.org/ratified-bcops/bcop-ipv6-subnetting/ Unfortunately, this BCOP recommends /56s for residential which is potentially harmful. While it does use /56 as an example (mainly because most of the operators I have spoken to say that is as big as they'll go and many are shooting for less) but it does NOT make that a recommendation, from the BCOP: This is an example for demonstrative purposes only. Individual operators will need to determine their own prefix size preference for serving customers (internal or external). The SMEs of this BCOP highly recommend a /48 for any site that requires more than one subnet and that a site be defined as an individual customer in residential networks. I'm also not a fan of the /126 or /127 on point-to-points, but, the theoretical issues of neighbor table exhaustion attacks, etc. certainly should not be ignored entirely. Agreed, they must be considered. Cheers, ~Chris Owen -- @ChrisGrundemann http://chrisgrundemann.com
Re: IPv6 day and tunnels
Templin, Fred L wrote: Infinity? You can't carry 65516B in an IPv4 packet. 2) For tunnels over IPv6, let infinity equal (2^32 - 1) You can't carry a 65516B IPv6 packet in an IPv4 packet. Instead, see the last two lines in second last slide of: http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf It is a common condition. Are you interested in only supporting tinygrams? IMHO, go big or go home! Bigger packets makes it rather circuit switching than packet switching. The way to lose. Faster is the way to go. Masataka Ohta
Re: ipv6 book recommendations?
Apologies for the double post... Mistakenly hit send instead of cancel on the first one. Owen On Jun 5, 2012, at 3:32 PM, Owen DeLong wrote: On Jun 5, 2012, at 3:23 PM, William Herrin wrote: On 6/5/12, Owen DeLong o...@delong.com wrote: On Jun 5, 2012, at 2:23 PM, William Herrin wrote: c. If it's a point to point, a reasonable practice seems to be a /64 per network area and around /124 per link. Works OK for ethernet point to points too. /64 is perfectly reasonable per point to point as well. Hi Owen, Sure, but with the neighbor discovery cache issues that come up with /64's under attack, why open yourself to trouble where you can't realize any benefit? It makes little sense to me to permit people outside your network to deliver packets to your point to point interfaces. Denying this traffic at your borders/edges eliminates all of the attacks without having to juggle inconsistent prefix sizes or do silly bit-math to figure out which address is at the other end of the link. Owen
Re: IPv6 day and tunnels
On Jun 5, 2012, at 5:21 AM, Joe Maimon wrote: Owen DeLong wrote: But that's a whole lot more packets than working PMTU-D to get there and you're also waiting for all those round trips, not just the 4 timeouts. The round trips add up if you're dealing with a 100ms+ RTT. 22 RTTs at 100ms is 2.2 seconds. That's a long time to go without first data packet passed, Owen Yes, it is quite nice when ICMP helpfully informs you what your MTU is. However, we have known for quite some time that is simply not reliable on the IPv4 internet, for a multitude of reasons, with intentional ICMP blocking just one of them. You keep saying this, yet you have offered no other explanations. I have no reason to expect it to work better in IPv6. That's where we differ. In IPv4, since PMTU-D was a new thing, it had to be optional and we had to work around places where it was broken to avoid flat-out breaking the internet. In IPv6, we have the opportunity to push the issue and use education to resolve the problem correctly. This is why more reliable methods are a good idea, even if they work slower or add more overhead, because as I see it they are intended to be used concurrently with ICMP. ICMP can be a reliable method if we just stop breaking it. Do you have some reason to believe people won't break the other methods, too? I don't. PMTU-D can't be fire-and-forget because paths aren't static. Also, as I understand the probing, getting data through happens much faster then arriving at the optimal mtu size might take. At the expense of sending a lot of unnecessary additional datagrams. Perhaps short flows should just be sticking to the min-mtu anyways. So you want to turn a short-flow (say a retrieving a 20k PNG) from being a 3-packet transaction on a path with jumbo frame support at 9000 octets into a 16+ packet exchange? (note I'm only counting the payload packets in one direction, not setup, teardown, additional acks, etc.). Still seems like a bad idea to me. Owen
RE: IPv6 day and tunnels
-Original Message- From: Masataka Ohta [mailto:mo...@necom830.hpcl.titech.ac.jp] Sent: Tuesday, June 05, 2012 3:41 PM To: Templin, Fred L Cc: nanog@nanog.org Subject: Re: IPv6 day and tunnels Templin, Fred L wrote: Infinity? You can't carry 65516B in an IPv4 packet. 2) For tunnels over IPv6, let infinity equal (2^32 - 1) You can't carry a 65516B IPv6 packet in an IPv4 packet. No, but you can carry a ((2^32 - 1) - X) IPv6 packet in an IPv6 packet. Just insert a jumbogram extension header. Instead, see the last two lines in second last slide of: http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf It is a common condition. Are you interested in only supporting tinygrams? IMHO, go big or go home! Bigger packets makes it rather circuit switching than packet switching. The way to lose. Faster is the way to go. Why only fast when you can have both big *and* fast? See Matt's pages on raising the Internet MTU: http://staff.psc.edu/mathis/MTU/ Time on the wire is what matters, and on a 100Gbps wire you can push 6MB in 480usec. That seems more like packet switching latency rather than circuit switching latency. Fred fred.l.temp...@boeing.com Masataka Ohta
Re: IPv6 day and tunnels
On 6/5/12, Owen DeLong o...@delong.com wrote: This is a horrible misconfiguration of the devices on that link. If your MTU setting on your interface is larger than the smallest MTU of any L2 forwarder on the link, then, you have badly misconfigured Not really; The network layer and L2 protocols should both be designed to handle this, it is a design error in the protocol that it doesn't.You say it's misconfiguration, but if IP handled the situation reasonably, it shouldn't be necessary to configure anything in the first place. Whether the neighbors are LAN or cross-tunnel, the issues are similar. It's only a misconfiguration because of flaws in the protocol. Just like you expect to plug devices in a typical LAN and it's not a configuration error to fail to manually find every switch in the LAN and enter MAC addresses into a forwarding table by hand; likewise, you shouldn't expect to key a MTU into every device by hand. IP should be designed so that devices on the link that _can_ handle the large transmission unit, which provides efficiency gains, should be allowed to fully utilize those capabilities, without breakage of connectivity to devices on the same link that have more limited capabilities and can only receive the Minimum required frame size (smaller MTU), and without separating the subnet or installing dividing Proxy ARP servers to send ICMP TooBig packets. Adding probing to compensate for this misconfiguration merely serves to perpetuate such errant configurations. Just like adding MAC address learning to Ethernet switches to compensate for the misconfiguration of failing to manually enter hardware addreses into your switches, serves to perpetuate such errant configurations, where the state of the forwarding tables are unreliably left in a non-deterministic state. You've got an issue if there are 100ms between two peers on your LAN. You're right, you don't need to probe for possible MTUs below 1280. LAN, sure. However, consider that there are intercontinental L2 links. Intercontinental multi-access L2 links, perhaps, are a horrible misconfiguration. Owen -- -JH
Re: Penetration Test Assistance
Tim, In the past I've used high level diagrams to illustrate the overall network topology with individual tabs (drill down) per data center or POP. The first step to assessing risk is to identify your assets. I'd suggest performing a discovery of your network. Keep in mind Pen tests are typically inconclusive of availability based threats DOS/DDOS (a very high risk today) and in fact specifically avoid tests which might cause degradation of service. I'd suggest including volumetric network (tcp, udp), application floods (http get, post, etc. /dns query floods, etc.) and slow and low attacks. Best of Luck, Dennis -- From: Baklarz, Ron bakl...@amtrak.com Sent: Tuesday, June 05, 2012 12:41 PM To: Green, Timothy timothy.gr...@mantech.com Cc: nanog@nanog.org Subject: RE: Penetration Test Assistance Not discounting the need for network diagrams, there are also differing approaches to pen testing. One alternative is a sort of black-box approach where the pen testers are given little or no advanced knowledge of the network. It is up to them to 'discover' what they can through open source means and commence their attacks from what they glean from their intelligence gathering. This way they are realistically mimicking the hacker methodology. Ron Baklarz C|CISO, CISSP, CISA, CISM, NSA-IAM/IEM Chief Information Security Officer Export Control Compliance Officer National Passenger Railroad Corporation (AMTRAK) 10 G Street, NE Office 6E606 Washington, DC 20002 bakl...@amtrak.com -Original Message- From: Green, Timothy [mailto:timothy.gr...@mantech.com] Sent: Tuesday, June 05, 2012 10:53 AM To: nanog@nanog.org Subject: Penetration Test Assistance Howdy all, I'm a Security Manager of a large network, we are conducting a Pentest next month and the testers are demanding a complete network diagram of the entire network. We don't have a complete network diagram that shows everything and everywhere we are. At most we have a bunch of network diagrams that show what we have in various areas throughout the country. I've been asking the network engineers for over a month and they seem to be too lazy to put it together or they have no idea where everything is. I've never been in this situation before. Should I be honest to the testers and tell them here is what we have, we aren't sure if it's accurate; find everything else? How would they access those areas that we haven't identified? How can I give them access to stuff that I didn't know existed? What do you all do with your large networks? One huge network diagram, a bunch of network diagrams separated by region, or both? Any pentest horror stories? Thanks, Tim This e-mail and any attachments are intended only for the use of the addressee(s) named herein and may contain proprietary information. If you are not the intended recipient of this e-mail or believe that you received this email in error, please take immediate action to notify the sender of the apparent error by reply e-mail; permanently delete the e-mail and any attachments from your computer; and do not disseminate, distribute, use, or copy this message and any attachments.
Re: IPv6 day and tunnels
Templin, Fred L wrote: You can't carry a 65516B IPv6 packet in an IPv4 packet. No, but you can carry a ((2^32 - 1) - X) IPv6 packet in an IPv6 packet. I'm afraid you wrote: General statement for IPv6-in-IPv4 tunneling, yes. But and What I am after is a tunnel MTU of infinity. in a single mail. Bigger packets makes it rather circuit switching than packet switching. The way to lose. Faster is the way to go. Why only fast when you can have both big *and* fast? Because bigger packets makes it rather circuit switching than packet switching, which is the way to lose. See Matt's pages on raising the Internet MTU: http://staff.psc.edu/mathis/MTU/ A page with too narrow perspective. Time on the wire is what matters, In senses you have never imagined, yes. and on a 100Gbps wire you can push 6MB in 480usec. That seems more like packet switching latency rather than circuit switching latency. 100Gbps is boringly slow. Are you interested in only supporting slowgrams? IMHO, go fast or go home! At 1Tbps optical packet switched network, there is no practical buffer other than fiber delay lines. If MTU is 1500B, a delay for a packet is 12ns long, delay for which requires 2.5m fiber. For practical packet lose probability, delay for tens of packets is necessary, which is not a problem. 9000B may still be acceptable. But, 6MB means too lengthy fiber. That's how time matters. Worse, at a 10Mbps edge of a network with 1Tbps backbone, 6MB packets means 4.8 seconds of blocking of other packets, which is why it is like circuit switching. Or, at a 1Tbps link in a super computer, 48usec is too much blocking. That's another way how time matters. Are you interested in only supporting circuitgrams? IMHO, go packet or go ITU! Masataka Ohta
Trouble viewing slides for Automated Configuration and Validation of a Large Scale Network
I am having trouble view the slides for this morning's presentation by Vijay Gill. It appears conversion from power point to a PDF cropped the slides. Can someone else try? Is there an email for reporting issues with the slides? Thanks. http://www.nanog.org/meetings/nanog55/presentations/Tuesday/Gill_Schmidt.pdf
Re: ROVER routing security - its not enumeration
On Tue, Jun 5, 2012 at 5:39 PM, Tony Tauber ttau...@1-4-5.net wrote: Shane A. gave a Lightning Talk the slides for which will be posted at some time soon. I figured the talk was shane's. They came in at the last minute which is why they're not up already. ok, cool. thanks -chris Tony On Tue, Jun 5, 2012 at 3:28 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Tue, Jun 5, 2012 at 2:42 PM, Daniel Massey mas...@cs.colostate.edu wrote: ROVER is not trying to do exactly what RPKI is doing. Much of this seems to be an attempt to build a form of enumeration into ROVER. See the Level3 NANOG talk from Monday (6/4/12) for a concrete example of a different model. There are many different you referenced this a few times: http://www.nanog.org/meetings/nanog55/agenda.php doesn't mention a talk from L3 on 6/4 ... got link? -chris
Re: IPv6 day and tunnels
On Jun 5, 2012, at 6:02 PM, Jimmy Hess wrote: On 6/5/12, Owen DeLong o...@delong.com wrote: This is a horrible misconfiguration of the devices on that link. If your MTU setting on your interface is larger than the smallest MTU of any L2 forwarder on the link, then, you have badly misconfigured Not really; The network layer and L2 protocols should both be designed to handle this, it is a design error in the protocol that it doesn't.You say it's misconfiguration, but if IP handled the situation reasonably, it shouldn't be necessary to configure anything in the first place. Whether the neighbors are LAN or cross-tunnel, the issues are similar. Really, no. The L3 MTU on an interface should be configured to the lowest MTU reachable via that link without crossing a router. It's just that simple. Anything else _IS_ a misconfiguration. First, your idea of handling the situation reasonably is a layering violation. Second, you are correct. All L2 bridges for a given media type should support the largest configurable MTU for that media type, so, it is arguably a design flaw in the bridges. However, in an environment where you have broken L2 devices (design flaw), you have to configure appropriately for that. It's only a misconfiguration because of flaws in the protocol. No, it's a misconfiguration because of the limitations of the hardware due to its design defects. L3 should not need to test the end-to-end L2 capabilities. It should be able to depend on what the OS tells it. Just like you expect to plug devices in a typical LAN and it's not a configuration error to fail to manually find every switch in the LAN and enter MAC addresses into a forwarding table by hand; likewise, you shouldn't expect to key a MTU into every device by hand. You don't expect to ever care about the MAC addresses of any of the switches in the LAN let alone enter them into any form of forwarding table at all. You do expect to need to know about the MAC addresses of adjacent systems you are trying to reach, and, you use either ND or ARP to map L3 addresses onto their corresponding L2 addresses as needed. I will note that this depends on sending a packet out to an address that reaches all of the candidate hosts (In the case of ND, this is a multicast to all hosts which have the same last 24 bits in their IP suffix. In the case of ARP, this is a broadcast packet) and expects them (at L3) to answer That's ME!. Of course you can enter them by hand in situations where ARP or ND don't work for whatever reason. You expect ARP or ND to work and a bridge that didn't forward ARP would be just as broken as a bridge which doesn't support the full interface MTU. I would expect to have to enter MAC adjacencies manually if I had a bridge that didn't pass ARP/ND traffic, just as I expect to have to enter the MTU manually if I have a bridge that doesn't support the correct full MTU of the network. IP should be designed so that devices on the link that _can_ handle the large transmission unit, which provides efficiency gains, should be allowed to fully utilize those capabilities, without breakage of connectivity to devices on the same link that have more limited capabilities and can only receive the Minimum required frame size (smaller MTU), and without separating the subnet or installing dividing Proxy ARP servers to send ICMP TooBig packets. No, it really shouldn't. Doing this is a serious layering violation for one, and, it can't be achieved efficiently number two. It adds lots of overhead and is very error prone. There's no signaling mechanism for L3 to be informed when the L2 topology changes, for example, which might necessitate a recalculation of the MTU. A given link should have a single MTU period. I don't know of ANY L3 protocol which supports anything else. Not IP, not IPX, not DECNET, not AppleTalk, no Banyan Vines, not XNS, none of them support the idea of MTU per adjacency. If you can only have one MTU per link, then, it must be the lowest common denominator of all participants and forwarders on that link. Adding probing to compensate for this misconfiguration merely serves to perpetuate such errant configurations. Just like adding MAC address learning to Ethernet switches to compensate for the misconfiguration of failing to manually enter hardware addreses into your switches, serves to perpetuate such errant configurations, where the state of the forwarding tables are unreliably left in a non-deterministic state. Apples and oranges. See above. In fact, MAC address learning on the switches is utterly unrelated to the MAC adjacency table maintained by ARP/ND. One is an L2 forwarding tree never learned by anything at L3 (the MAC forwarding table learned on the switches) and the other is a MAC adjacency table for a given link used by the L2 software on the host to populate the L2 packet header based on the L3 information. You've got an issue if there are 100ms between
Re: IPv6 day and tunnels
Bigger packets makes it rather circuit switching than packet switching. The way to lose. Faster is the way to go. Why only fast when you can have both big *and* fast? Because bigger packets makes it rather circuit switching than packet switching, which is the way to lose. Er... No. It's attitudes like this that killed ATM. (argument about whether the ATM cell payload should be 64 or 128 octets lead to a mathematical compromise decision that was completely unworkable and vastly inferior to either choice. Unfortunately, neither the US telcos (128) or the EU telcos (64) would give ground and accept the other standard.) Larger packets for sustained flows of large amounts of data do not make it circuit switched, they make packet switching more efficient by reducing overhead. Especially on higher bandwidth links. Admittedly, if you go to too large an MTU for your bps, you can create HOL blocking issues which have the same loss characteristics as circuit switching. However, let's say that anything 10ms HOL blocking is our definition of bad. At 10Gbps, that's 100,000 bits or 12,500 octets. At 100Gbps, that's 125,000 octets. Given the combination of Moore's law and the deployment lifecycle, designs we do today in this regard can be expected to last ~12 years or more, so they should be prepared for at least 16x. At 1,600 Gbps, that puts our target maximum MTU up around 200M octets. See Matt's pages on raising the Internet MTU: http://staff.psc.edu/mathis/MTU/ A page with too narrow perspective. Time on the wire is what matters, In senses you have never imagined, yes. ? Time on the wire is what matters. It is the primary distinction between packet and circuit switching. and on a 100Gbps wire you can push 6MB in 480usec. That seems more like packet switching latency rather than circuit switching latency. 100Gbps is boringly slow. His case only gets better when you go faster. Seriously, Mas, try to keep up. Are you interested in only supporting slowgrams? IMHO, go fast or go home! At 1Tbps optical packet switched network, there is no practical buffer other than fiber delay lines. Which argues for an even larger MTU. If MTU is 1500B, a delay for a packet is 12ns long, delay for which requires 2.5m fiber. For practical packet lose probability, delay for tens of packets is necessary, which is not a problem. 9000B may still be acceptable. But, 6MB means too lengthy fiber. 6MB at 1TB/sec is 48 microseconds which is 120 km fiber. Modern single-mode spools 10 times that size can actually be built within reason. That's how time matters. Worse, at a 10Mbps edge of a network with 1Tbps backbone, 6MB packets means 4.8 seconds of blocking of other packets, which is why it is like circuit switching. But you wouldn't carry a 6MB MTU out to a 10 Mbps edge. You'd drop the edge MTU to 1500. That's why Path MTU Discovery is useful. Or, at a 1Tbps link in a super computer, 48usec is too much blocking. In which case you would want to use a smaller MTU. However, I doubt that anyone is likely to run a tunnel in a situation where 48microseconds is too much latency and we are talking about tunnel MTUs here. That's another way how time matters. Are you interested in only supporting circuitgrams? IMHO, go packet or go ITU! Sigh... I now realize that the other end of this conversation is a human with too narrow a view. Owen
