Re: 240/4

2007-10-18 Thread Daniel Karrenberg

On 18.10 10:48, Adrian Chadd wrote:
 
  Asking the whole internet to support 240/4 is going to tie up
  valuable resources that would be far better off working on IPv6.  Keep
  in mind that it's not just software patches.  Software vendors don't do
  stuff for free.  I doubt ISPs are going to pay huge amounts of money to
  support a peer crazy enough to try this.  And until tested, there is no
  guarantee that hardware based routing platforms (your PFCs, etc) can
  route Class E addresses as if they're unicast.
 
 So how about pulling a reachability test and announcing a few /19's from
 240/4, stick a website on it and get people to report back?

If there was serious community interest in this, I am sure the RIPE NCC
could be persuaded to test this as part of the well-oiled de-bogonising 
machinery. this immediately provides automated measurements as well.

It may take a little longer than sual to set up as we may want to ask
all our de-bogonising peers whether they are OK with this just to be sure.

Daniel

PS: Personally I am not convinced that this space will ever become useful for 
global routing. But we won't know for sure until we have tried it.


Re: Spain was offline

2006-09-04 Thread Daniel Karrenberg

On 01.09 13:47, Martin Hannigan wrote:
 
 I can't get a TLD zone? But back to the root servers. Are you
 agreering with me that if I announce F and I root's netblocks
 inside of my own network that everyone would be ok with that?
 
 C'mon Joe, straight answer on that one. :)

Straight answer: No.


Exercises: 

Who is responsible if this set-up fails?

Who is responsible if it lies?

Who is likely to get blamed for any failures?

Would this require explicit consent from all customers 
subject to such treatment?

Would this require a possibility for each custoemr to opt out
of such a scheme?

And - ah yes - what particular problem does such a set-up solve?


Daniel

helps operating K
helped create nsd
measures dns



Re: the future of the net

2005-11-17 Thread Daniel Karrenberg

On 16.11 21:33, Bubba Parker wrote:
 
 Seems to be back up now.

At this time I got

Linux Journal Is Currently Unavailable Due to a Denial of Service (DoS) Attack

Sorry for any inconvenience.

Interesting. At first sight I though that was why Randy
posted the URL under future of the net ;-) ;-) ;-).

Daniel


Re: IAB and private numbering

2005-11-17 Thread Daniel Karrenberg

On 15.11 07:38, Mark Smith wrote:
 
 RFC1627, Network 10 Considered Harmful (Some Practices Shouldn't be
 Codified) and RFC3879, Deprecating Site Local Addresses provide some
 good examples of where duplicate or overlapping address spaces cause
 problems, which is what happens when different organisations use RFC1918
 addresses, even if they aren't connected to the Internet.

This is practical engineering, not theoretical science.  Practical
engineering is about *trade-offs*. 

We were seeing address space requests for huge deployments with a real
low probability to ever be routed anywhere beyond a quite local domain. 
There are huge deployments of this kind now and happily so without
unnecessary using finite address resources. 

The drawbacks were known and discussed.  Note that 16271918.  Clear
warnings were written into 1918; it is one of the more operational
RFCs, certainly at the time.  We also discussed the possibility of NATs
but it was out-of-scope for 1918; we discussed application layer
gateways though; we did not anticipate any NAT deployments beyond a very
local scale. 

Would we rather have run out of unallocated unique IPv4 address space at
some point in the past?  Would an alternative  have been ready by then? 

(Would we rather run out of unallocated IPv4 address space on -say- 
31-Dec-2005? 
Will IPv6 be ready for prime time then?)

Daniel 
One of the instigators and co-author of RFC1918. 


Re: oh k can you see

2005-11-07 Thread Daniel Karrenberg

We have considered the options carefully and decided to announce a
covering /23 to get around the problem spotted by Randy and the folks in
Oregon.  We considered the /24+/25 soloution but decided against that
because it makes little sense when we are considering to eventually
remove as much of the BG cleverness as possible. 

See the attached announcement for details. 

Thanks to all people who took the time to make suggestions either
privately or on list(s). 

This was both operational and useful. ;-)

Daniel
---BeginMessage---
Dear Colleagues,

As you probably know, the RIPE NCC have been deploying two types of
anycast mirror instances of K-root server: global nodes and so-called
local nodes, intended to serve only a local ISP community. To limit
propagation of the K-root prefix for the local nodes we are using a
NO_EXPORT community.

Unfortunately this may lead to a situation when some of multihomed
networks don't see K-root prefix at all, even for a global node. For
more detailed description see
http://www.merit.edu/mail.archives/nanog/msg13358.html. Thank you,
Randy, for spotting this.

This is not specific to anycast and has never appeared to be
particularly widespread.

To remedy this problem we plan to start announcing a covering prefix
193.0.14.0/23 from AS25152 from our global node to our peers at AMS-IX
without the NO_EXPORT community.

We will announce the covering prefix at 10:00 UTC on Thursday, 10th
November 2005. In parallel we will be monitoring and measuring changes
in traffic distribution for further analysis. We will then proceed with
other global nodes.

Regards,

Andrei Robachevsky
RIPE NCC
---End Message---


Re: oh k can you see

2005-11-01 Thread Daniel Karrenberg

Randy's description of the issue with NO_EXPORT is correct. 
It has never appeared to be particularly widespread.
It is not specific to anycast.

You also describe the rationale correctly by saying it would be good if
a server in Kenya did not take load from nyc.  I'll expand a little
more on that.  K does anycast with two objectives: primarily to increase
robustness of the service in the face of serious load increases,
secondarily provide better service to some local areas in the Internet
topology.  It is the secondary objective that poses the problem.  We
operate local nodes which are intended to serve only a local area.

This is clearly a routing problem and routing policy is clearly the
responsibility of ISPs.  The local ISPs should make sure that routes of
local nodes do not propagate far enough to cause unwanted load. 
Consequently we could just announce one route without doing anything to
it and wash our hands as far as routing and network load is concerned.
Server load is not a concern here because in the case of local nodes the
network will saturate far more quickly than the server. 
This is a very clean solution. It keeps responsibility where it belongs
and does not introduce extra complexity in BOP routing. I like it. ;-)

However we try to be helpful and provide tools to the ISPs by tagging
the routes from such local nodes with NO_EXPORT and we artificially
lengthen the AS-paths to the global nodes in order to make the local
nodes more attractive to ASes that hear both.  The latter is problematic
too because it can cause non-optimal node selection but does not lead to
anything worse than that.  Remember that these are nothing but hints to 
ISPs who determine their own routing policy and are responsible for it. 
So if someone barks at K for this it is the wrong tree for the most part.

What should we do? Stop giving the hints? Add complexity by announcing
another less specific covering prefix like F does? Any better ideas?

We are currently in an evaluation phase of our anycast deployment.
We are taking measurements and are analysing them. 
Early results:
http://www.ripe.net/ripe/meetings/ripe-51/presentations/pdf/ripe51-anycast_k-root.pdf
We are also seriously considering to reduce the number of local nodes
where this is feasible.

This is a good time to hear good ideas. Let us have them. 

Daniel

PS:  Bill, I hope this also answers your question on why we do this.
We have been doing it for a long time too.
As I said: suggestions are welcome.


Re: oh k can you see

2005-11-01 Thread Daniel Karrenberg

On 01.11 05:41, Randy Bush wrote:
 mornin' daniel:

ev'nin randy:

Of course the NCC takes resposibility for the K anycast deployment
including the way we announce BGP routes to K. We also clearly describe
and announce what we do.  We cannot take responsibility for what others
do with that routing information;  we cannot because we have no control
over and little way of knowing what they do.  We are doing the best we
can;  hence this conversation. 

We are considering to add a covering prefix announced from global nodes
relatively quickly.  This should solve the particular problem and we
cannot (yet) see any problems it would create. But this is more complex
than the current state and thus brings us further away from salvation ;-).
If there are reasons not to do this, please let us know. 

We are also considering seriously to treat local nodes and global
nodes the same routing wise wherever possible.  This will be done
one-by-one wiht the proper announcements and concurrent measurements. 
My poersonal hope is that we can do this for all K nodes and thus remove
all BGP cleverness that originates from us. This does not mean that all
cleverness concerning K's routes would be removed though.

Daniel


Re: Level 3's side of the story

2005-10-17 Thread Daniel Karrenberg

On 16.10 16:04, Simon Leinen wrote:
 
 Kevin Loch writes:
  Does anyone have reachability data for c-root during this episode?
 
 The RIPE NCC DNSMON service has some:
 
 http://dnsmon.ripe.net/dns-servmon/server/plot?server=c.root-servers.nettype=dropststart=1128246543tstop=1128972253

If there is anyone with more comprehensive  data I'd like to hear about it ;-) !

 According to BGPlay for that particular prefix from Route-Views data
 (for some reason the RIPE RIS server used by BGPlay seems to be down
 at the moment), the episode seems to be between these times (UTC):

It is up now. Of the two routes to c.root-servers.net via Level 3 in that 
data set one stayed up during the period and the other got healed immediateely 
via AS286. It flipped back later.

 ...

 The interval in the URL above starts 72 hours before the start of the
 episode and ends 72 hours after its end.  I cannot see any particular
 problems that would coincide with the episode, from that set of probes
 (RIPE TTM).

I agree that there is nothing really significant here. It is mostly noise.
What one is looking for in these graphs is strong vertical 
patterns.  dnsmon did not detect anything significant concerning
reachability of c.root-servers.net.

 As someone else said, partial unreachability of a particular root
 nameserver isn't that much of an issue.  

Indeed.

 But it's an interesting question nevertheless.

A red instance of a fish from the northern seas ?

Daniel


Re: as numbers

2005-08-01 Thread Daniel Karrenberg

On 31.07 17:20, [EMAIL PROTECTED] wrote:
 
   we did that (move a root) in the CIDR /8 experiment.
   we could do it for this too :)

one root name server: yes
the root name servers: no, definitely not

Daniel

PS: Ony as soon as implementations are available of course ! ;-(


Re: as numbers

2005-07-30 Thread Daniel Karrenberg

On 29.07 09:59, Henk Uijterwaal wrote:
 
 I'd think that 30 days is too low.  What we see (*) is that after 30 days,
 only half of the assigned ASN have appeared on the Internet.  Some 75%
 of the assigned ASN appear on the net in the first 6 months after
 assignment, 80-85% after a year.  Anything not seen after a year (15-20%),
 is unlikely to ever appear, these can be recovered (at least in theory).
 
 While this looks like a lot, it does not really solve any problem.  Geoff's
 numbers show that the pool will expire in 5 years.  Our estimate is a
 little bit longer, but not that much.  2010-2005 is 5 years, if the trend
 that 20% never appears continues and all these ASN are revoked, this simply
 means that the pool will  expire in 6 years.  2010 or 2011 hardly makes a
 difference.

Henk hits the nail on the head. And reclamation is not straightforward:

The RIPE NCC has hit strong resistance to reclamation, most often with
the argument that the ASes are used in inter-domain routing on the
Internet but our BGP data collectors just do not see the paths
concerned.  It takes considerable effort to do reclamation properly
whithout putting the future user of any reclaimed number space at risk! 

Also: I think we should all be very concerned about this. As with all such 
projections, Geoff's are valid only for an unchanged consumtion pattern.  
If I was running a network I would start to ask my vendors serious questions 
and start to prepare deployment scenarios.

Daniel


Re: GSM gateways in the US?!?

2005-07-28 Thread Daniel Karrenberg

On 25.07 07:59, Simon Lockhart wrote:
 
  There are two methods that are obvious to terminate calls into mobile 
  (GSM) networks in North America:
 
 Just to give you a .uk experience, I don't know the technical details of how
 this is implemented 

These are pretty common plans over here even for enterprises smaller than the 
BBC.

A friend in a medium sized taxpayer funded organisation recently 
related the following: that organisation had just invested considerably
into their PABX, particularly into toll authorisation and billing. 
Shortly after this was introduced they realised that the national toll
volume sharply decreased.  They were just about to declare a serious
victory for effective cost control when they realised that this was due
a change in the corporate GSM plan that allowed essentially free
national calling and people in the organisation were making the right
choice ;-)

This suggests a much simpler solution to this whole problem: Give all the 
people in the office cell phones for intra-organisational calling.
Lacks some call management features, and certainly lacks geek satisfaction,
but costs very little to implement...

Daniel


Re: soBGP deployment

2005-05-25 Thread Daniel Karrenberg

On 23.05 22:13, Tony Li wrote:
 ... We,
 as responsible operators/architects/vendors/coders need to pick a
 solution and field it.  It may well be an interim solution, but we MUST
 act, and soon.  We are already seeing the stress patterns, without
 reinforcement it is only a matter of time before we see wholesale
 fractures.  Given that any solution will have an implementation and
 deployment delay, we dare not wait much longer.

From discussions with large operators during NANOG week it is clear to
me that at this point most will simply not deploy anything that
dynamically interacts with their inter-domain routing (BGP).  All are
comforatble with deploying something that works via the current
mechanism of periodically built configurations.  In fact most said to
wait for something that would take some of the heuristics out of that
process.  We will not get any deployment unless either that attitude
changes or we engineer taking it into account.  I prefer the latter. 

To me the first stage of any deployment becomes obvious then:
Map the fucntionality of s*BGP into tools to build routing configurations
from signed information distributed by whatever means. This will make rapid
deployment possible with a high comfort level for operators which is key!
It would bring immediate benefits and help us build and understand the 
databases that are necessary. In parallel we can develop more dynamic
ways of distributing the information and interacting with BGP.
If the design and trust model of s*BGP is indeed well conceived this
will be attractive enough for operators to see deployment.

Note that I am not advocating routing registries. I agree with those that
consider them a failure although I have been a long time supporter.
The idea is to start building the (signed) meta-information and using it
as additional input to the configuration generation already done by operators.
Ideally this would quickly obsolete from routing registries and many heuristics.

Can such a first step of an incremental deployment be designed for any of s*BGP?

Daniel


Re: [dnsop] Re: Root Anycast

2005-05-05 Thread Daniel Karrenberg

On 03.05 16:06, Rodney Joffe wrote:
 
 ...
 
 See y'all in Seattle. Daniel Karrenberg and others will be providing loads
 of fuel to spark debate amongst non-kooks about the efficacy of anycast DNS
 ;-)

Sneak preview:

http://rosie.ripe.net/ripe/meetings/ripe-50/presentations/uploads/Tuesday/karrenberg-bgp_anycast_stability.pdf

Daniel


Re: [dnsop] Re: Root Anycast

2005-05-05 Thread Daniel Karrenberg

On 05.05 16:56, Daniel Karrenberg wrote:
 
 Sneak preview:
 
 http://rosie.ripe.net/ripe/meetings/ripe-50/presentations/uploads/Tuesday/karrenberg-bgp_anycast_stability.pdf

Sorry, correct URL is:

http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-tue-anycast.pdf


Re: fwd: Re: [registrars] Re: panix.com hijacked

2005-01-16 Thread Daniel Karrenberg

On 16.01 10:25, Lou Katz wrote:
 
 
 Is there anything that us folks out in the peanut gallery can
 do to help, other than locally serving the panix.net zone
 for panix.com?

Avoid being caught by an IPR lawyer while helping; ;-)
Then organise operators to insert operational clue 
into the various policy processes.

Daniel


Re: verizon.net and other email grief

2004-12-16 Thread Daniel Karrenberg

On 14.12 09:39, Todd Vierling wrote:
 
 That's definitely true, though it can be used successfully -- if there's a
 very reliable kill-switch to withdraw the advertisement in a moment, or some
 kind of fallback mechanism in place to handle gross failures.

Using this as the *only* remedy for unavailability of an anycast instance
is insufficient given the speed at which bad news travels in BGP. You want
to have the service available at multiple addresses with each of those 
engineered as differently as possible.

Daniel


Re: anycast stability experiment

2004-11-17 Thread Daniel Karrenberg


The RIPE NCC dnsmon (http://dnsmon.ripe.net) has collected such data for
all root servers from dozens of places for about two years already.  You
are welcome to the raw data.  NB: The further back in time the more work
it will be for us to dig out raw data. 

Differences to your set-up:

- most probes are not near the edges of the net, for most definitions of 
edge
- probing times are properly randomised
- the mean probing interval is 60s
- UDP only

[Continuous but not scientifically rigorous examination of the data
shows that your bet is a pretty safe one. In other words: for practical 
purposes routing is stable at all proble locations. So the data is 
in fact pretty boring. If it weren't as boring, k.root-servers.net 
would not be anycast the way it is.]

Daniel


Re: European Nanog?

2004-09-15 Thread Daniel Karrenberg

On 14.09 13:23, Roland Perry wrote:
 
  ...
 more to the point, who decided meeting content?  essentially daniel
 karrenberg does.
 
 I thought it was a committee of the Workgroup chairs (apart perhaps from 
 the first day).


Roland, 

you are almost right.

From http://www.ripe.net/ripe/meetings/ripe-49/eof-info.html :

The European Operators Forum (EOF) is a forum where new
technologydevelopments of interest to Internet Protocol network
operators arepresented and discussed.  The EOF has no formal charter or
chair.  The agenda is co-ordinated by a program committee led by Rob
Blokzijl, RIPE Chair. 

Participation is open to all interested parties.  The EOF is normally a
day and a half session that takes place prior to scheduled RIPE Working
Group sessions.  The Program Committee welcomes input for possible
topics and can be reached at [EMAIL PROTECTED]. ... 

All sugestions for content go to the eof-coord list.  Anyone willing to
contribute to putting together the EOF programme is welcome to join this
list.  It is an extremely informal group.  Most, if not all, RIPE WG
chairpeople are on the list; but it is not limited to them.  The RIPE NCC
currently supports me to act as a secretary and to look after the
meeting/speaker logistics.  

Daniel


Re: RIPE Golden Networks Document ID - 229/210/178

2004-09-06 Thread Daniel Karrenberg


Some facts:

RIPE is an operator forum, comparable to NANOG, APRICOT, AFNOG, 
(Strictly speaking RIPE pre-dates all of the others if one disregards
that NANOG started as the NSFnet regional network meetings. ;-)

RIPE NCC is a Regional Internet Registry, comparable to ARIN, APNIC, LACNIC, 
AFRINIC, 
(The RIPE NCC is the first of the regional registries.)

RIPE is the public forum where RIPE NCC policies and procedures are set;
they describe how the RIR allocates and assigns internet numbers.

RIPE NCC policies and procedures are *extremely* careful not to prescribe
any inter-domain routing practises and go out of their way to stress that
operators have the authority about that.

RIPE also makes general recommendations, which have nothing to do with the 
RIPE NCC. The golden networks recommendations are in this category.
They are also just that: recommendations.


---


Some opinions:

The goals of the RIPE recommendations are laudable: Make dampening
work predictably by aligning parameters. They reflect a general 
belief in think globally, act locally which still permeates 
RIPE discussions.

However, this is not likely to work because:

- operators have the sole authority about routing
- different local goals
- different capabilities of infrastructure 
- different capabilities of staff (design and operation)
- sheer ignorance

(Yes, I tend to be a bit more cynical these days 
than the average RIPE attender.)

I doubt if a survey such as Rodney tries to perform will yield
any useful results because responses will not be universal nor
evenly distributed. 

--

More personal opinions:

If there is a significant number of operators that want to base any of
their decisions on what services are behind specific addresses, this
cannot be solved by static documents but must be solved by a registry. 
I would design this as a voluntary registry which operators may use in
any which way they want if they choose to.  The *art* in the design of
such a registry would be defining the classes of services and agreeing
on how to verify that an address houses a service of a given class 
for some classes such as DNS root and TLD servers. 

OTOH for DNS root and TLD servers, determining their addresses is
trivial using the DNS itself and the containing prefixes can be found
from current BGP tables and/or BGP archives such as the RIS.  
So the case for such a registry for DNS servers alone is highly questionable. 

Daniel


Re: that MIT paper again (Re: VeriSign's rapid DNS updates in .com/.net ) (longish)

2004-07-24 Thread Daniel Karrenberg

On 23.07 22:30, Simon Waters wrote:
  
 The abstract doesn't mention that the TTL on NS records is found to be
 important for scalability of the DNS. 

Sic!

And it is the *child* TTL that counts for most implementations.


Re: VeriSign's rapid DNS updates in .com/.net

2004-07-23 Thread Daniel Karrenberg

On 22.07 14:46, Randy Bush wrote:
 
 ... the TTL issue is almost entirely NS RRs, ...
 of course, almost all date in the gtlds are NS RRs, so the worry about
 TTL crank-down holds, though just for silly gtld servers.  then again,
 they're paid to serve.

This assumes rational behavior of a lot of zone admins. YMMV

Of course rational behavior may be increased by information and education.

Daniel


Re: VeriSign's rapid DNS updates in .com/.net

2004-07-22 Thread Daniel Karrenberg

Matt, others,

I am a quite concerned about these zone update speed improvements
because they are likely to result in considerable pressure to reduce
TTLs **throughout the DNS** for little to no good reason.

It will not be long before the marketeers will discover that they do not
deliver what they (implicitly) promise to customers in case of **changes
and removals** rather than just additions to a zone. 

Reducing TTLs across the board will be the obvious *soloution*. 

Yet, the DNS architecture is built around effective caching! 

Are we sure that the DNS as a whole will remain operational when
(not if) this happens in a significant way? 

Can we still mitigate that trend by education of marketeers and users? 

Daniel


Re: VeriSign's rapid DNS updates in .com/.net

2004-07-22 Thread Daniel Karrenberg

On 22.07 12:26, Stephen J. Wilcox wrote:
 
 I dont see any reference to adjusting the TTL in the verisign announcement.

Correct.

 They say they will update the zones every 5 minutes from the registry data.
 
 These are not the same things (or did I miss that bit?)

Correct.

 Also, isnt a lot of this dependent on the NS records in the second level gtlds 
 which is hosted by the ISPs.. so this part doesnt change?

Correct. 

What I am concerned about is the pressure to lower TTLs across the board
if the increase in zone update speed creates expectations that it alone
cannot fulfill. 

I observe this being sold as instantaneous updates instead of
instantaneous additions.  When this becomes clear the pressure will be
to deliver what the salespeople promised.  This will result inthe obvious
soloution: Lower TTLs everywhere. 

I am not sure the DNS will remain stable if TTLs are lowered to
a couple of seconds throughout.

I am suggesting clearer marketing:
Quick additions: Yes.  Quick changes/deletions: No.

Note that I am not concerned about *judicious* lowering of TTLs 
in preparation for changes or to provide services such as akamai.
It is more a general trend of many independent actors serving nor real
purpose that worries me. 

Caveat emptor.

Daniel


Re: VeriSign's rapid DNS updates in .com/.net

2004-07-22 Thread Daniel Karrenberg

On 22.07 17:08, Paul Vixie wrote:
 
   therefore if there were a drop in TTL for root-zone data, it would
 only be a multiplier against 2.1% of f-root's present volume.

I am not worried so much about the root servers here because of the 
reasons you cite. The root server system is engineered to cope with
hugely excessive loads already.
I am worried about all the other root servers that have to deal with
much lesser query loads and might feel the impact of lowered TTLs
much more. 

 ... and the impact of
 having it in many TLD's will be to put downward pressure on TTL's.  this
 all needs to be looked at very carefully.

Yes, we need to keep an eye on this and argue against lowering TTLs 
across the board for little good reasion.




Re: VeriSign's rapid DNS updates in .com/.net

2004-07-22 Thread Daniel Karrenberg

On 22.07 21:05, an alter ego of Daniel Karrenberg wrote:
 
 I am worried about all the other root servers that have to deal with
 much lesser query loads and might feel the impact of lowered TTLs
 much more. 

Of course I meant all the other DNS servers.

Daniel


Check Your Routing Table! 85-88/8 active

2004-04-28 Thread Daniel Karrenberg

It is *now* high time to check whether you see the following
pilot prefixes: 

85.192/16, 85.255.248/21, 
86.192/16, 86.255.248/21, 
87.192/16, 87.255.248/21, 
88.192/16, 88.255.248/21.

If you do not see all of these prefixes it is extremely likely that you
will have a connectivity problem shortly.  We also suggest that you
check any packet filters you may be responsible for. 

Regards

Daniel Karrenberg
RIPE NCC

--

Notes:

This address space has been allocated by the IANA on April 4th 2003,
almost a month ago.  The fact has been widely announced then.

Routing decisions are fully within the responsibility of the network
operators.  The IANA and the RIRs will only announce which parts of the
address space are currently in use.  They have no authority whatsoever
over routing decisions taken by you and other network operators.

More details about this pilot service of the RIPE NCC can be found at
http://www.ripe.net/ripe/draft-documents/deboganising-draft.html .

A visibility comparison of the pilot prefixes with some production
prefixes can be found at http://www.ris.ripe.net/debogon/debogon.html .
Those interested in history, see http://www.ris.ripe.net/debogon/ .

Pingable targets exist in all pilot prefixes at 
t{85,86,87,88}-{16,21}.rrc03.ripe.net , i.e. the target within 
the /21 pilot prefix of 85/8 is t85-21.rrc03.ripe.net .

For testing purposes it is possible to do ping and traceroute 
originating within the pilot prefixes via
http://www.ris.ripe.net/cgi-bin/debogon.cgi .
Please use this with prudence.

More information on how to do Bogon filtering efficiently and reliably
can be found at Team CYMRU: http://www.cymru.com/Bogons/index.html



EOF, Amsterdam, May - Call for Presentations

2004-03-25 Thread Daniel Karrenberg

[apologies for duplicates, hint: they have the same message-id]

Hi Network Operations Folk,

NOW is the time to consider making a presentation at the European Operators 
Forum (EOF) to be held during the 48th RIPE meeting in Amsterdam on 
Monday 3rd and Tuesday 4th of May 2004.

We would like to have as many practical, hands-on presentations
as possible this time. Remember: They do not have to be long. 
We prefer an stand-up interesting 10 minute presentation over 
a well prepared 90 minutes explanation of something not so 
interesting to operators.

Find some information about presenting below and think about all
those experiences this year that might be interesting to 
other operators.

Should you have questions, please do not hesitate to contact me by
e-mail at any time.  

Thanks

Daniel

--

Information about the EOF and presenting there:

http://www.ripe.net/ripe/meetings/ripe-48/eof.html

Information about the meeting in general:

http://www.ripe.net/ripe/meetings/ripe-48/index.html

--

Guidelines for submitting abstracts:

We expect to finalise the program in shortly.  We will get back to you
then with scheduling details.  In the meantime please provide the
information below.  We place special emphasis on the abstract which
should contain references to related material already available if
possible.  Please send this to eof-coord at-sign ripe.net. 

- Author(s)
- Speaker
- (Working) Title 
- Abstract
- Draft Presentation (if available)
- Relation to other known work and/or presentations if known
- Time Requested

It would be helpful if the abstract was written such that potential
attenders will learn what to expect from the presentation, i.e.

The presentation will describe our experiences with the
Red Packet Washer (http://www.netdet.net/RPW/).  We have been using the
device for half a year now.  It helps us deliver more hygienic datagrams
to our customers and peers.  We will discuss problems with packet   
discolouring as well as increased throughput to our upstreams due to
decreased clogging by dirty micrograms.  We will compare performance
with the hand-scrubbing of packets which we used previously.  Currently
we are optimising device management and getting bugs resolved.  We will
strive to include the latest experiences in our report.

is much better than

The presentation will describe the Red Packet Washer made by
Network Detergents.



Re: DNS requests for 1918 space

2004-03-16 Thread Daniel Karrenberg

On 16.03 11:22, Geo. wrote:
 
 Can anyone point me at any papers that talk about security issues raised by
 private networks passing dns requests for RFC 1918 private address space out
 to their ISP's dns servers?

RFC1918


Check Your Routing Table! Production Use of 84/8 Imminent.

2004-03-11 Thread Daniel Karrenberg

The first allocation out of 84/8 has happened.  It is *now* high time to
check whether you see the pilot prefixes 84.192/16 and 84.255.248/21. 
If you do not see both of these prefixes it is extremely likely that you
will have a connectivity problem very shortly.  We also suggest that you
check any packet filters you may be responsible for. 

Regards

Daniel Karrenberg
RIPE NCC

--

Notes:

84/8 has been allocated by the IANA on November 17th 2003,
almost 4 months ago.  The fact has been announced on this list 
a couple of times since. 

Routing decisions are fully within the responsibility of the network
operators.  The IANA and the RIRs will only announce which parts of the
address space are currently in use.  They have no authority whatsoever
over routing decisions taken by you and other network operators.

More details about the pilot prefixes can be found at
http://www.ripe.net/ripe/draft-documents/deboganising-draft.html

A visibility comparison of the pilot prefixes with some production
prefixes can be found at http://www.ris.ripe.net/debogon/debogon.html
Those interested in history, see http://www.ris.ripe.net/debogon/

More information on how to do Bogon filtering efficiently and reliably
can be found at Team CYMRU: http://www.cymru.com/Bogons/index.html

Unfortunately we are not currently able to provide a host within the
pilot prefixes that can reliably answer pings, nor are we able to do
connectivity checks from there.  The allocation had to happen before 
we were ready with this part of the pilot prefix pilot.


Re: Counter DoS

2004-03-11 Thread Daniel Karrenberg

On 10.03 20:55, Steven M. Bellovin wrote:
 
 The phrase seriously bad idea comes to mind.  Other phrases include 
 illegal, collateral damage, and stupid.

Those plus escalation of agression and uncontrollable feedback loop.

Daniel Karrenberg

PS: I will spare you the re-run of a recent discussion I had with some
5-year-olds, but there *is* a certain similarity. 


Re: 168.0.0.0/6

2004-02-24 Thread Daniel Karrenberg

On 24.02 23:20, Randy Bush wrote:
 
 BGP routing table entry for 168.0.0.0/6, version 7688303
 ...
   3277 13062 20485 20485 20485 8437 3303
 194.85.4.249 from 194.85.4.249 (194.85.4.249)
   Origin IGP, localpref 100, valid, external, best
 
 ripe is being overgenerous to the swiss!

Not so. They are pretending to be over-endowed to some peers
only.

Isn't that something to notify AS3303 aka SWISSCOM about rather than NANOG?
Especially since it does not look like it is spreading very widely.

Daniel


Proposal: De-boganising New Address Blocks

2004-02-24 Thread Daniel Karrenberg

[Apologies for duplicate messages]

This is of interet to all operators worldwide.  Operators
who do not participate in RIPE are invited to send comments
and suggestions directly to the author.

De-Bogonising New Address Blocks

http://www.ripe.net/ripe/draft-documents/deboganising-draft.html

Abstract

This document describes an improvement in the notification process
about new blocks of address space being distributed by the RIRs. It is
a draft at this stage and your comments are solicited. However to gain
experience before finalising the procedures, the RIPE NCC will shortly
start announcing the routes from 84/8 described in the document under
84/8 Pilot.  




Re: New Draft Document: De-boganising New Address Blocks

2004-02-24 Thread Daniel Karrenberg

On 24.02 16:32, [EMAIL PROTECTED] wrote:
 
 That is a misleading title.

I thought it was to the point and rather cute ;-).
 
 The problem is that ISPs cannot react quickly enough
 to open filters when new ranges are allocated. The proposed
 solution is to provide advance notification. I suppose this
 could allow ISPs to open filters before the new addresses
 are actually in use officially.

This is the status quo, aka best *current* practise.

 However, it will also allow spammers to announce this
 space and get it through bogon filters.

Correct, but only in the absence of more specific filtering.
the problem this proposal aims to correct is the increasing number of
false positives caused by the apparent *serious* lag in relatively
static bogon filtering. 

 The real solution to this problem is to make it 
 possible for ISPs to closely track RIR allocations
 in their filters in a semi-automated way. There may
 still be a few days of delay before a new allocation
 is fully routable but ISPs can compensate for that
 with internal processes. 
 
 Why can't ISPs subscribe to a feed of all new 
 RIPE allocations in near real-time?

Personally I think this is a great idea and if we hear from a lot of
operators actually willing to take such feeds it may become reality
beyond volunteer efforts like the Team CYMRU one.  However there are a
number of serious issues with something like this, not the least of
which are the liability issues in case this goes wrong very dynamically
and semi-automatedly. 

It is certainly something to progress if there is enough interest.

However I think the current proposal shold go ahead too because the false
positives are a real problem that needs to be addressed quickly.

Daniel


Re: updated root hints file

2004-01-29 Thread Daniel Karrenberg

On 29.01 15:36, Jess Kitchen wrote:
 
  http://www.root-servers.org/ seems to only have news on I's ASN change, no
  mention of B or J or the anycast F/K/I's ... methinks this info should have a
  home on this site..

If you folow the link from this site to http://k.root-servers.org/ you will
find info about K's anycast instances. We will add them to the table too,
just for completeness. 

Daniel


Re: What's the best way to wiretap a network?

2004-01-21 Thread Daniel Karrenberg

On 21.01 09:24, Kurt Erik Lindqvist wrote:
 
  From the initial discussions in Sweden around the new electronic 
 communications act, it seems as if the operators are obliged to provide 
 tapping free of charge. If this turns out to be the case, I guess it is 
 pretty much the same all over Europe as the law is supposed to be based 
 on a EU framework.

Slightly off topic:

This is being fought by ISPs and civil rights groups all over the place here.

It is amazing how much brain-damage is defended by EU Framework these days.
It is also amazing how much national politicians and  pressure groups can
assert things about *neighboring* countries that are blatantly wrong or 
totally out-of-date. In the EU political structures and processes still
have to be built; it is a new thing. 

Daniel


Re: New IPv4 Allocation to ARIN

2004-01-19 Thread Daniel Karrenberg

On 16.01 13:13, [EMAIL PROTECTED] wrote:
 ... 
 Alternatively, the RIRs might consider doing this sort of thing before
 allocating IPs from new blocks.  I know it's not their job to make sure
 IPs are routable (especially not on every remote network), but as holders
 of all the IPs, they are in the best position to setup such test sites
 that would expose problems before they're dumped on members.  

Personally I agree with you and I will argue accordingly in the relevant places.
Cooperation with the bogon project seems logical too.

Daniel


Re: good cabling in real environments [Re: Request for submissions: messy cabling and other broken things]

2003-12-17 Thread Daniel Karrenberg

On 17.12 19:07, Pekka Savola wrote:
 
 How do you do good cabling in dynamic, real environments? :-)

My own 25 years of experience boil down to: 

Try to plan for expansion as well as possible when designing,
then periodically start over and completely re-build the messy parts.

The period of starting over depends on the pain level of the planned
outages this may cause and the general pain caused by the state of things.  

All clever plans I have seen in this area have not lasted more than about 2-3 
years. It seems very difficult to predict where the growth is and how it 
happens.

I admit this is a slightly cynical view but such is life. 
What I dread most, are situations where no-one takes the responsibility
for starting over when it is really necessary and everybody suffers. 

Daniel


Re: Root Authority

2003-12-16 Thread Daniel Karrenberg

On 16.12 07:14, Paul Vixie wrote:
 we (i'm speaking for f-root here) have no authority.  nobody has to
 listen to us, we are the most powerless bunch of folks you'll ever meet.
 
 now if you'd asked where we derive our *relevance*, i'd say the same as
 mr. bush and mr. kletnieks -- from all the root.cache files that point
 at us.  and as long as we don't do anything stupid i guess (and hope)
 that this state of affairs will continue.  (relevance trumps authority.)
 
 that having been said, f-root got its start as NS.ISC.ORG and the man
 who said it was ok for us to be a root name server was jon postel.  i'm
 not sure he had any authority either, but folks pointed at him and
 so what he said was relevant in spite of any authority he mightn've had.

Amen!

This also holds for k-root and is so well put that I will not paraphrase it
just for the sake of putting it differently.  It is worth reading again!

Daniel


Re: Anit-Virus help for all of us??????

2003-11-25 Thread Daniel Karrenberg

On 24.11 18:20, William Allen Simpson wrote:
 
 Brian Bruns wrote:
  
  One thing that many people don't realize (from my personal experience) is
  that contrary to popular belief, Win98SE is a good all around desktop OS to
  use.  It can run most things like productivity apps and games, and with
  128-256MB of RAM, its quite fast even on an old laptop like mine.  Unlike
  XP, it doesn't have a million services running, nor does it have the nasty
  UPnP stuff from WinME.  

I agree wholeheartedly.

if haveto(M$) 
use(W98SE);

I recommend that at home to all local primary schools.  They often do
not have the latest hardware but some of them even run it on the latest
hardware now.  This and frequent reloads of standard clean disk images
tends to keep things clean and operational.  The image loads from a *nix
server are routinely done by 10-year-olds.  Unfortunately this is not a
really long term strategy.  I expect apps that are essential to the
schools but do not run on W98SE in the not-too-distant future. 
I guess they will have to find loads of money and buy macs then. ;-)

Daniel


Re: possible ORG problems, maybe?

2003-10-17 Thread Daniel Karrenberg
On 17.10 09:47, Randy Bush wrote:
 
 but one has little assurance that the response is from the same
 server as the one from which one had the dns response one is debugging.

That is true.  However this only matters if the operator of the server
allows them to be inconsistent *and* routing so volatile that queries
are routed to different instances over short periods of time.

In my opinion the increased DDoS resilience alone outweighs this
drawback.  In addition the service quality can be increased as the
number of places at which the service can be provided is independent of
the number of server addresses available due to DNS protocol
limitations.

Hard data:

We probe DNS servers from 60+ points across the internet once a minute
on average.  We log the id.server or hostname.bind value they return.

I have not completed the colour picture version of analysing this part
of the data but here is a quick perl script version:

For the period from UTC to 2359UTC yesterday 60 out of 63 probes (95+%) got
*all* of their 1400+ answers from the *same instance* of k.root-servers.net.
The three probes that talked to different instances showed 1, 2 and 4
change events respectively.  I consider this stable enough for debugging
purposes.

Data for f.root-servers.net shows a similar picture.

Both data files are attached.

We will provide this data in full colour form at dnsmon.ripe.net sometime
in the coming weeks.

Daniel


id.server change events over 00-24h UTC 16 Oct 2004

probe Unix-second id.server



jordaan.ripe.net 1066262834 k1.ams-ix

osdorp.ripe.net 1066265997 k2.ams-ix

tt01.ripe.net 1066265765 k1.ams-ix

tt03.ripe.net 1066264341 k1.ams-ix

tt07.ripe.net 1066263351 k2.linx

tt08.ripe.net 1066264396 k1.linx

tt101.ripe.net 1066263692 k2.linx

tt102.ripe.net 1066263660 k2.ams-ix

tt106.ripe.net 1066263675 k1.linx

tt13.ripe.net 1066263669 k2.ams-ix

tt16.ripe.net 1066265900 k1.ams-ix

tt17.ripe.net 1066265938 k2.linx

tt22.ripe.net 1066265931 k1.ams-ix

tt23.ripe.net 1066265275 k1.linx

tt26.ripe.net 1066265922 k1.linx

tt27.ripe.net 1066263670 k2.linx
tt27.ripe.net 1066277285 k2.ams-ix
tt27.ripe.net 1066281317 k2.linx
tt27.ripe.net 1066281916 k2.ams-ix
tt27.ripe.net 1066281978 k2.linx

tt28.ripe.net 1066263029 k2.linx

tt31.ripe.net 1066262515 k2.linx

tt32.ripe.net 1066265728 k1.linx

tt34.ripe.net 1066264347 k2.linx

tt35.ripe.net 1066263579 k2.linx

tt36.ripe.net 1066265821 k1.ams-ix

tt40.ripe.net 1066266054 k1.ams-ix

tt42.ripe.net 1066263820 k1.linx

tt46.ripe.net 1066262809 k2.linx
tt46.ripe.net 1066277318 k2.ams-ix
tt46.ripe.net 1066281259 k2.linx

tt47.ripe.net 1066263388 k2.linx

tt49.ripe.net 1066263719 k2.ams-ix

tt52.ripe.net 1066263700 k1.ams-ix

tt53.ripe.net 1066263547 k2.linx

tt54.ripe.net 1066263448 k2.linx

tt55.ripe.net 1066264461 k2.linx

tt56.ripe.net 1066263652 k2.linx
tt56.ripe.net 1066289206 k1.ams-ix

tt57.ripe.net 1066263443 k2.ams-ix

tt58.ripe.net 1066263917 k1.linx

tt59.ripe.net 1066263880 k2.ams-ix

tt62.ripe.net 1066263745 k1.ams-ix

tt63.ripe.net 1066265313 k2.linx

tt64.ripe.net 1066265845 k1.linx

tt66.ripe.net 1066263341 k2.ams-ix

tt69.ripe.net 1066263469 k1.linx

tt70.ripe.net 1066265124 k1.linx

tt71.ripe.net 1066265453 k1.linx

tt72.ripe.net 1066263370 k2.linx

tt73.ripe.net 1066263666 k2.ams-ix

tt74.ripe.net 1066264146 k1.linx

tt76.ripe.net 1066265324 k1.linx

tt77.ripe.net 1066264512 k2.ams-ix

tt78.ripe.net 1066263788 k1.linx

tt80.ripe.net 1066264148 k2.ams-ix

tt81.ripe.net 1066263388 k2.ams-ix

tt82.ripe.net 1066264239 k2.ams-ix

tt84.ripe.net 1066263094 k2.linx

tt85.ripe.net 1066263695 k2.linx

tt86.ripe.net 1066263776 k1.linx

tt87.ripe.net 1066263651 k1.linx

tt88.ripe.net 1066264483 k2.ams-ix

tt89.ripe.net 1066265562 k2.linx

tt90.ripe.net 1066263876 k1.ams-ix

tt92.ripe.net 1066263814 k2.linx

tt93.ripe.net 1066262921 k2.ams-ix

tt94.ripe.net 1066263274 k2.ams-ix

tt97.ripe.net 1066263862 k2.ams-ix

tt98.ripe.net 1066265295 k2.ams-ix

jordaan.ripe.net 1066262826 pao1e.f.root-servers.org

osdorp.ripe.net 1066265992 pao1f.f.root-servers.org

tt01.ripe.net 1066265749 pao1c.f.root-servers.org

tt03.ripe.net 1066264356 pao1d.f.root-servers.org

tt07.ripe.net 1066263361 pao1e.f.root-servers.org

tt08.ripe.net 1066264397 yow1b.f.root-servers.org
tt08.ripe.net 1066269597 pao1e.f.root-servers.org
tt08.ripe.net 1066269649 pao1f.f.root-servers.org
tt08.ripe.net 1066269720 yow1b.f.root-servers.org

tt101.ripe.net 1066263685 pao1e.f.root-servers.org

tt102.ripe.net 1066263678 pao1e.f.root-servers.org

tt106.ripe.net 1066263671 sfo2a.f.root-servers.org

tt13.ripe.net 1066263662 yow1a.f.root-servers.org
tt13.ripe.net 1066269591 pao1f.f.root-servers.org
tt13.ripe.net 1066269699 yow1a.f.root-servers.org
tt13.ripe.net 1066307212 pao1f.f.root-servers.org
tt13.ripe.net 1066307266 yow1a.f.root-servers.org

tt16.ripe.net 1066265895 pao1f.f.root-servers.org

tt17.ripe.net 1066265953 mad1a.f.root-servers.org

tt22.ripe.net 1066265939 yow1b.f.root-servers.org

A RR Wildcards and Stability

2003-10-08 Thread Daniel Karrenberg

The comittee should realise that the question Verisign poses about
observed adverse effects, while interesting, is not as pertinent as it
seems at first sight.  John Klensin put it very well yesterday in
a rigorous way.  I'll offer a less rigorous but more graphical analogy:

A contractor drills large holes in the central structural parts of a
building to allow installation of their innovative garbage disposal. 
Civil engineers question the effects this has on the building's stability.  
The contractor's defense is: Well it is still standing! 
How much work did those tenants really have patching up the holes
to reduce the air drafts and stop the crackling noises?

Daniel


Re: sitefinder technical discussions

2003-10-07 Thread Daniel Karrenberg

On 06.10 23:51, Mark Kosters wrote:
 
 In the interest in gaining more community review and comment, a discussion 
 list has been setup to discuss factually-based technical issues
 and solutions surrounding the operational impact of wildcards in
 top-level domains on Internet applications.
 
 VeriSign technical people will participate in discussions that are within
 the scope for this mailing list.
 
 The list is [EMAIL PROTECTED]
 
 To subscribe or unsubscribe the usual -request convention works.  Send
 a message to:
 
 [EMAIL PROTECTED]
 
 Put subscribe or unsubscribe in the body of the message.

I am very hesitant to join this particular list because I am afraid that
Verisign will somehow use the fact that I am subscribed as they please
in their PR efforts, e.g.  A panel of Internet experts convened by
Verisign Inc including insert your name here has discussed ., the
panel did not come to consensus that ..  .

I would rather use existing fora such as the relevant IETF WG(s) or this list.


Daniel




Re: VeriSign Capitulates

2003-10-06 Thread Daniel Karrenberg

On 06.10 10:54, [EMAIL PROTECTED] wrote:
 
There is no data to indicate the core operation of the domain name
system or the stability of the Internet has been adversely affected,
VeriSign's Galvin said.
 
 This means that there are no papers published or
 conference presentations which detail the problems
 caused by sitefinder. 

http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html




Re: Is there anything that actually gets users to fix their computers?

2003-10-03 Thread Daniel Karrenberg

On 03.10 04:12, Sean Donelan wrote:
 
 Short of turning off their network access, why won't users fix
 their computers when the computer is infected or needs a patch?

Hey, it's working!  If it ain't broken  

Related question for network engineers: When did you have your last
medical check-up?  To what extent do you follow your physician's
recommendations? 

Daniel


Re: Is there anything that actually gets users to fix their computers?

2003-10-03 Thread Daniel Karrenberg

On 03.10 10:36, Erik-Jan Bos wrote:
 Hey, it's working!  If it ain't broken  
 
 I doubt this. Recently, I worked with a couple of people that each had 
 their PCs infected. Their own virtual neighborhood complained to them, 
 and they surely were embaressed about the situation, but... They just 
 did not know how to fix it, i.e. where to start. Call it cluelessness, 
 call it lack of education.

There is that too; but I have frequently observed people not doing it 
even when provided detailed step-by-step instructions. On the other hand
they would proceed relatively quickly once it stopped working, 
e.g. the Internet plug was pulled. Some of them would use the instructions
provided, others would get help; but not before it stopped owrking.

The most successful tactic I have seen is for providers is to block all 
Internet access except the one to the site containing the instructions
and the fix. Of course that is often not a viable business proposition

Daniel


Re: Is there anything that actually gets users to fix their computers?

2003-10-03 Thread Daniel Karrenberg

On 03.10 10:59, Erik-Jan Bos wrote:
 
 Perhaps an auto club for PC-users: You call and within the next 24 or 
 48 hours, depending on your subscription, an expert would dial in or 
 come by to get you on the virtual road again.

If this was a viable business proposition, it would exist.  My experience
is that the product to be maintained is both too complex and too badly
designed and engineered to be readily maintainable.  In other words:
This is more viable for cars than for personal computers and more viable for
MacOSX than for WIntel. 

I speak from 10+ years of experience as friendly computer expert for the
virtual and physical neighborhood. 

Daniel

PS: The health question in my original contribution was serious.


Digression 1: Cars have become less maintainable by the auto club because
of added *proprietary* complexity too. 

Digression 2: I also help maintaining computers at the primary school my
kids attend.  When I started this, the soloution that could be
maintained by professionals was all new WIN NT servers and all new WIN
2K workstations.  Luckily (sic!) the school could not afford this by a
fair margin.  The mainenance offer was all-in for a periodic fee.  

Now the professionally maintainable soloution is based on Linux servers.  
This is moving in the right direction both from an enginieering and cost
view point.  However the maintenance offer is now buy blocks of  support hours
at a discounted rate.  My guess is that the substance of the maintenance deal 
has not changed;  they have just become more honest in selling it.  :-( ;-)
So even for a small business this option does not really exist yet.

Back to work

Daniel


Re: what happened to ARIN tonight ?

2003-09-29 Thread Daniel Karrenberg

On 29.09 10:27, James Cowie wrote:
 
 Single-homed /24 through UUNet's 7046 to 701. Withdrawals started at 01:21:38 GMT
 (21:21:38 Eastern time), and ARIN flapped severely for about fifteen minutes.   
 
 Then they spent another hour and ten minutes inconsistently reachable from half the 
 world, with the picture mutating slowly.  701 seems to have been telling 
 inconsistent 
 stories about ARIN's reachability, depending on which of our peers you consulted  -- 
 IGP instability?  By 03:10 GMT everyone seems to have slowly gotten a  
 consistent picture again, with ARIN restored. 

The RIPE NCC Routing Information System saw a very similar picture:
Flapping from  01:20:50Z - 01:38:22Z, consolidation 01:59:46Z - 02:28:20Z.

For details see:

http://www.ris.ripe.net/cgi-bin/risprefix.cgi?net=192.149.252.16%2F32preftype=lspecaction=SearchstartDay=20030929startHour=00startMin=00startSec=00endDay=20030929endHour=06endMin=00endSec=00rrcb=allpeer=alltype=%25sortby=stimeoutype=html.cgifields=type

http://www.ris.ripe.net/cgi-bin/risprefix.cgi
is quite useful in answering questions like this,
i.e. What happened to prefix x.y.z/a between times t and u?
It is near real time with a lag of typically 5 minutes.

Daniel
~



Re: Verisign Responds

2003-09-23 Thread Daniel Karrenberg

On 23.09 06:07, Paul Vixie wrote:
 We call on the IAB, the IETF, and the operational community to
 examine the specifications for the domain name system and consider
 whether additional specifications could improve the stability of
 the overall system. Most urgently, we ask for definitive
 recommendations regarding the use and operation of wildcard DNS
 names in TLDs and the root domain, so that actions and expectations
 can become universal. With respect to the broader architectural
 issues, we call on the technical community to clarify the role of
 error responses and on the separation of architectural layers,
 particularly and their interaction with security and stability.
 
 and it does seem rather urgent that if a wildcard in the root domain or in
 a top level domain is dangerous and bad, that the ietf say so out loud so
 that icann has a respected external reference to include in their contracts.

The IAB has done an excellent job with 
http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html.
I quote:

...
Proposed guideline: If you want to use wildcards in your zone and
understand the risks, go ahead, but only do so with the informed consent
of the entities that are delegated within your zone. 

Generally, we do not recommend the use of wildcards for record types
that affect more than one application protocol.  At the present time,
the only record types that do not affect more than one application
protocol are MX records. 

For zones that do delegations, we do not recommend even wildcard MX
records.  If they are used, the owners of zones delegated from that zone
must be made aware of that policy and must be given assistance to ensure
appropriate behavior for MX names within the delegated zone.  In other
words, the parent zone operator must not reroute mail destined for the
child zone without the child zone's permission. 

We hesitate to recommend a flat prohibition against wildcards in
registry-class zones, but strongly suggest that the burden of proof in
such cases should be on the registry to demonstrate that their intended
use of wildcards will not pose a threat to stable operation of the DNS
or predictable behavior for applications and users. 

We recommend that any and all TLDs which use wildcards in a manner
inconsistent with this guideline remove such wildcards at the earliest
opportunity.

What else does the IETF need to do here?

This should be enough of an expert opinion for ICANN and others 
like the US DoC in the sort term. Verisign have realised that and
are talking about an -so far vapour- expert panel to counter that.
I wonder about its composition .

Daniel


Re: Verisign Responds

2003-09-23 Thread Daniel Karrenberg

On 23.09 14:34, Paul Vixie wrote:
  
  What else does the IETF need to do here?
 
 issue an rfc.  iab is not a representative body, and their opinions
 are not refereed.

brilliant_draft = rfc-format(relevant(good(iab-statement)) + night_sleep(own-ideas));
suggest(dnsop-wg, brilliant_draft);
wait(unspec);
...

Daniel


Re: News of ISC Developing BIND Patch

2003-09-17 Thread Daniel Karrenberg

On 17.09 00:50, Sean Donelan wrote:
 
 On Tue, 16 Sep 2003, John Brown wrote:
  not all the *root-servers* carry .arpa or in-addr.arpa
 
  J (one of verisigns)  does not carry this zone, based
  on their own internal decision.
 
 Actually, I thought that was one of Jon Postel's decisions when
 they were experimenting with creating root-only root servers.

Correct.

 Unfortunately, the progress on that front didn't continue after
 the DNS wars started.

Progress has continued albeit so slowly as to resemble stagnation.

Daniel


Re: Not the best solution, but it takes VeriSign out of the loop

2003-09-17 Thread Daniel Karrenberg

On 17.09 04:27, Paul Vixie wrote:
 speaking for f-root, we won't be cooperating with anything like that.

speaking for k-root we will not either.

 ... sounds like mob rule to me -- count me out.  so, block me first, i guess?

block us second.

Daniel


Re: Dynamic Internet Maps based on BGP table / AS_PATH

2003-09-10 Thread Daniel Karrenberg


http://www.ris.ripe.net/cgi-bin/risas.cgi

Select output format graphical.  The really nice feature is that you
can do this for any time in the recent past and from multiple view
points because it works off a database of BGP data collected in 9 places
all over the globe.  Feedback welcome! 

The netlantis tool mentioned earlier works off (part of?) this data and
produces a nicer output for some purposes. 

Daniel


Re: Dynamic Internet Maps based on BGP table / AS_PATH

2003-09-10 Thread Daniel Karrenberg

On 09.09 17:09, Mehmet Akcin wrote:
 
 hey
 are you looking something like that? 
 http://www.netlantis.org/index.php?menu=2page=gasp

Actually much nicer is now

http://www.netlantis.org/index.html?menu=2page=sagm

This is *really* cool.

Daniel


Re: rfc1918 ignorant

2003-07-23 Thread Daniel Karrenberg

On 23.07 10:07, Kevin Oberman wrote:
 
 In order to use private address space, an enterprise needs to
 determine which hosts do not need to have network layer connectivity
 outside the enterprise in the foreseeable future and thus could be
 classified as private. Such hosts will use the private address space
 defined above.  Private hosts can communicate with all other hosts
 inside the enterprise, both public and private. However, they cannot
 have IP connectivity to any host outside of the enterprise. While not
 having external (outside of the enterprise) IP connectivity private
 hosts can still have access to external services via mediating
 gateways (e.g., application layer gateways).
 
 As I read this, packets with a source address in 19298 space should
 NEVER appear outside the enterprise. Comcast and many others seem to
 blithely ignore this for convenience sake. (It's not like they need a
 huge amount of space to give private addresses to these links.)

You read this correctly. We also wrote: 

   It is strongly recommended that routers which connect enterprises to
   external networks are set up with appropriate packet and routing
   filters at both ends of the link in order to prevent packet and
   routing information leakage. An enterprise should also filter any
   private networks from inbound routing information in order to protect
   itself from ambiguous routing situations which can occur if routes to
   the private address space point outside the enterprise.

I consider this quite explicit. I also consider this still very valid.

Imho the PMTU argument is moot. This should not be an issue at all other
than on the edges these days.  Should it nonetheless be an issue it 
can be done in the boundary routers which have interfaces numbered 
public address space. I do not know all the details here, so if 
I am wrong in detail, please tell me.

Daniel


Re: it's 1918 in bologna

2003-07-11 Thread Daniel Karrenberg

On 10.07 19:56, Randy Bush wrote:
  note the 37. address.  cute, eh?  and i thought omphaloskepsis
  was greek!
  Someone is going to have fun when tat part of 37/8 gets assigned and used.
 
 as the us military is blocking overseas access to more and more address
 space, i guess non-american isps can use that space with impunity.
  ^
  
Do they publish a list? ;-)


EOF, Amsterdam, September - Call for Presentations

2003-07-10 Thread Daniel Karrenberg

[apologies for duplicates, hint: they have the same message-id]

Hi Network Operations Folk,

the holiday period is starting! A good time to consider preparing
a presentation at the European Operators Forum (EOF) to be held
during the 46th RIPE meeting in Amsterdam on September 1st and 2nd.

We would like to have as many practical, hands-on presentations
as possible this time. Remember: They do not have to be long. 
We prefer an stand-up interesting 10 minute presentation over 
a well prepared 90 minutes explanation of something not so 
interesting to operators.

Find some information about presenting below and think about all
those experiences this year that might be interesting to 
other operators.

For the EOF Coordination Group.
Daniel Karrenberg

--

The EOF

The European Operators Forum (EOF) exists for the exchange of Internet
operations experience.  It has evolved from the information exchange
part of the early RIPE meetings to provide an open forum outside of the
work programme of the working groups and the RIPE plenary.  The EOF aims
to attract presentations relevant to network operators, practical
hands-on reports, outlines of future developments and small tutorials. 
Product marketing presentations are not appropriate, user experience
reports are.  The EOF programme is assembled by an informal coordination
group that is always looking for new people who are able to help by 
attracting interesting presentations and supporting presenters.  
Contact: Daniel Karrenberg [EMAIL PROTECTED]


Presenting at the EOF

The EOF wants to attract practical hands-on experience reports. 
We aim to make turning interesting experience into a presentation
as easy as possible. Consider the following:

- presentations do not have to be long
  Something interesting can be said in as little as 10 minutes. 
  This limits the time spent to prepare material and often is a good way
  to start for first-timers.

- support is available
  We will do our best to support you in preparing your presentation.
  If you want, we can help structuring your material, help to polish 
  language and arrange for a test-run of your presentation. We can also
  try to arrange for someone from the same country or region to support
  you if that is helpful. We can also help you find someone else to
  present your material in case you cannot make it to the meeting.
  In short: If you have something intersting to say, we will help you do it!
  Contact Daniel Karrenberg [EMAIL PROTECTED] for more information.

- no product marketing presentations
  The EOF is *not* an appropriate forum for product marketing presentations.
  User experience reports which are presented by users are definitely relevant.
  In-depth technical presentations or tutorials are also possible.

We expect to finalise the program in early August.  We will get back to you
then with scheduling details.  In the meantime please provide the
information below.  We place special emphasis on the abstract which
should contain references to related material already available if
possible.  Please send this to eof-coord at-sign ripe.net. 

- Author(s)
- Speaker
- (Working) Title 
- Abstract
- Draft Presentation (if available)
- Relation to other known work and/or presentations if known
- Time Requested

It would be helpful if the abstract was written such that potential
attenders will learn what to expect from the presentation, i.e.

The presentation will describe our experiences with the
Red Packet Washer (http://www.netdet.net/RPW/).  We have been using the
device for half a year now.  It helps us deliver more hygienic datagrams
to our customers and peers.  We will discuss problems with packet   
discolouring as well as increased throughput to our upstreams due to
decreased clogging by dirty micrograms.  We will compare performance
with the hand-scrubbing of packets which we used previously.  Currently
we are optimising device management and getting bugs resolved.  We will
strive to include the latest experiences in our report.

is much better than

The presentation will describe the Red Packet Washer made by
Network Detergents.

More information about the meeting can be found at
http://www.ripe.net/ripe/meetings/ripe-46/index.html

Should you have questions, please do not hesitate to contact me by
e-mail at any time.  During July and August my response time may be
slightly longer than usual due to the holiday period. 

Thanks

Daniel


Re: it's 1918 in bologna

2003-07-10 Thread Daniel Karrenberg

On 10.07 12:19, Randy Bush wrote:
 ...
 
 note the 37. address.  cute, eh?  and i thought omphaloskepsis
 was greek!

Someone is going to have fun when tat part of 37/8 gets assigned and used.

Daniel


From http://www.quinion.com/words/weirdwords/ww-omp1.htm :

OMPHALOSKEPSISI pronunciation

Contemplating one's navel as an aid to meditation.

This word seems to be relatively new, at least the Merriam-Webster
Word of the Day column claims it to have been invented only in the
1920s.  It turns up in only a few dictionaries and seems to be a word
that survives more for the chance to show off one's erudition than as
a real aid to communication.  



Re: Mark Allman: Internet measurement: what next?

2003-07-09 Thread Daniel Karrenberg

On 08.07 14:59, Jack Bates wrote:
  The RIPE-NNC tests are much more related to 
 what I was refering to, although they are limited in many reguards.

If you tell us what limits you want removed we may work on that!

We are definitely working towards making the results generally
available; see http://www.ripe.net/ripe/docs/ripe-271.html for details
of that proposal.  So far we have had very positive reactions on this
although some ISPs are worried about being exposed in comparison to
competitors who do not participate. 

We will also add quite detailed measurments of DNS servers for the root
and TLDs.  Data has been taken for several months now. A beta version of 
the resulting products will be available soon. 
 
I have been thinking about a multi-tier measurement network, adding
probes that do not have dedicated hardware and high precision clocks,
but rather conisist of just a software package. These could be deloyed
more easily.

Daniel Karrenberg
RIPE NCC


Metoo Was: Pesky spammers are using my mailbox

2003-06-04 Thread Daniel Karrenberg

On 03.06 13:44, Dominic J. Eidson wrote:
 
 I'm having a feeling that someone harvested a bunch of adresses, possibly
 from NANOG, and is using them as the sender address in pretend-to-be KLEZ
 spams.. I have received several bounces lately, several of them appearing
 to be KLEZ, all with me as the original sender 

Just to add another data point:

The same thing started happening to me a few days ago.  I do not know
any of the recipients of the bounces but some people I *do* know advised me
they are getting them.  I cannot say whether this is really KLEZ or not,
not enough data.  

Daniel



Re: BGP to doom us all

2003-03-04 Thread Daniel Karrenberg

On 28.02 18:13, Barry Raveendran Greene wrote:
 
 Now - show me an operational environment on the Internet were this authorization
 chain is _working_ today. RIRs and RADB do not count. As you mention before,
 those databases and keeping them up to date are a pulling teeth exercise.
 
 ...
 
 My opinion is that lazy operational practices are the single biggest threat to
 the Internet. What's the point of building security and robustness into a system
 when people choose not to turn it on?

RIRs do count and the infrastructure to set up the chain is there. 
Address assignment and allocation is a quite formal and well recorded
process these days. 

The address *allocationassignment* databases are in good shape for
about the last 8 years.  The fact that they are not in good shape for
assignments from the good old days is true.  But this is being
actively worked on and one should not blow it up out of proportion. 

Deploying technologies like SBGP would of course provide additional
incentives to record allocations and assignments and the resulting
signing of certs even better. 

Daniel


Re: Bell Labs or Microsoft security?

2003-01-29 Thread Daniel Karrenberg

On 29.01 03:32, Sean Donelan wrote:
 ... Multics security. Bell Labs answer: Unix. Who needs all that extra
 security junk in Multics. .

[reader warning: diatribe following]

Gee, there once were a handflul of people;
their principle goal was to make an OS for their own use.

They did it in such a way that it could be developed by its users while
they used it.  Creeping featurism was held down successfully, at least
initially ;-(.  It ran on platforms orders of magnitude cheaper than
what Multics ran on at the time.  It taught a lot of people about
programming style.  I hope I learned some things from it.  And they
wrote up the shortcomings of the security architecture concisely at the
time this began to matter.  They understood stuff that M$ with its
creeping featurism, low support cost defaults, undocumented API of the week 
cannot possibly begin grok and deal with because of ETOOBIG.

Now you and I use it because it does the job better than anything else.
Then you blame them for not designing in today's requirements 30 
(not 20!) years ago.  Give them a break ...

Daniel

PS: Worm? Virus? Who wrote this up concisely first?

PPS: Plan 9 anyone?



Re: Important Informational Message - root.zone change

2002-11-04 Thread Daniel Karrenberg

At 12:59 AM 11/5/2002, Sean Donelan wrote:
Since its been 5 years since the hints/cache boot file has changed,
it may be useful to remind people an immediate change to your
local configuration files is not required.  You don't need to
slashdot internic.net tomorrow morning trying to download the file.

As long as 1 listed IP address responds with the current list of root
servers, the server doesn't even need to be a root server itself, your
name server should figure out who are the current roots.  In the 1980's
and 1990's when the hints/cache file changed regularly, some people when
years without updating it.  Or only updated it when they upgraded their
name server code.

Don't Panic.

Well said!

I am quite disappointed that ICANN has not included similar language in
their announcement. They know better. 

Daniel




Re: WP: Attack On Internet Called Largest Ever

2002-10-23 Thread Daniel Karrenberg

At 07:50 AM 10/23/2002, Jamie C. Pole wrote:
It's a terrible thing when the most competent assessment of an attack
comes from a company spokesperson, rather than someone just a little more
technical...

In my reality the shop floor is not allowed to comment on something 
that is seen as vital to a corporation's interests at all. This 
in order not to destroy carefully crafted statements by the spokespeople 
vetted by the lawyerpeople. Such statements tend to be designed to
hide the bad news and amplify whatever snippets of good news can be found.

The *perceived* affluence of *comptetent* technical people has an effect on this:
It makes the shop floor *much less* likely to talk even to peers for fear of 
their jobs.

Daniel




RE: WP: Attack On Internet Called Largest Ever

2002-10-23 Thread Daniel Karrenberg

[Longish diatribe. I just use my share of bandwidth here in
larger packets. I hope you will consider S/N large enough]

At 04:51 PM 10/23/2002, Joe Patterson wrote:
would it cause problems, and more importantly would it solve potential
problems, to put some/most/all of the root servers (and maybe gtld-servers
too) into an AS112-like config? 
Is it a problem that's even worth looking at? 

It is definitely worth exploring. As David Conrad pointed out,
the technology is there. Also it is very appealing in terms
of DDoS resistance and general distributedness that works so
well for the Internet.

 Is it a solution that's worse
(for some reason I haven't noticed yet) than the problem?

The problem is making absolutely sure that the root zone 
that is served is authentic. For AS112 this is 
not really important because the queries it syphons off 
are all bogus anyways. So I could not care less if they
received bogus answers. For the root this is an entirely 
different matter! Of course if we had DNSSEC widely deployed
it would be a no-brainer. But I am afraid that is going to 
take a long time; I hope it happens before DNS itself 
becomes obsoleted.

So with the lack of DNS security the problem 
could be mitigted by routing security, i.e one could 
have some trust in the place the information comes from
instead of having the information itself authenticated.
However there is no such thing as routing security either. 

The best we can do in the absence of pertinent security
technology is to try to distribute things carefully;
always making sure that ISPs, and end-users if they wish,
have current and usable information to determine 
themselves which DNS servers and which routes to them
they trust. While doing this we also must maintain 
clearly the responsibility of the server operators
to serve the authentic unique root zone and to
provide a consistent service with good performance.

At the same time there is the ever increasing number
of self appointed people suggesting to run root servers
for a variety of motives, usually even good intentions;
however with the potential to change the content of
the root zone *without accountability* or even without
telling the users of those servers. 

Those who know me will testify that I am a very grass roots,
bottom-up oriented person suspicious of centralisation and
hierarchies. But the prospect of having multiple differing
instances of the root zone in the Internet makes me very 
uncomfortable. In fact it would mean that we will have
no Internet any longer but different networks,
that one cannot trust any longer that a hyperlink will
end up in a single place, that a server is really the one
one intends to talk to etc. pp. Unfortunately we do not have
the security techologies deployed yet that will alleviate
this problem. So we have to keep things together for some
time or end up with no Internet left.

Daniel




Re: More federal management of key components of the Internet needed

2002-10-23 Thread Daniel Karrenberg

At 07:05 AM 10/24/2002, Alan Hannan wrote:
  It worked for airline security.

Oh, did it now?

Just to paraphrase Seans very professional language:
Before the US government proposes to unilaterally 
take responsibility for a particular service it should 
consider its track record of  providing parts of 
that particular service in the past. 
Not to mention that the service serves the World and 
not just the US.

Daniel





Re: IRR listing of IANA-reserved, a question..

2002-09-04 Thread Daniel Karrenberg


Speaking for myself too:

I have been wanting an *authoritative* *single* listing of unallocated address space
for at least 6 years. Note that this is at a finer granularity than the IANA
allocations list and it would have much more frequent changes than the IANA list
as address space is allocated to local registries.

However it could include a more coarse data set that changes less frequently for those
that do not want or need the higher granularity.

The only way to make this happen is for the RIRs to collect this data among themselves
and publish it regularly. Because of the possible ramifications of errors in this list
it is not as simple to do that reliably as it may seem at first glance; but it should
be done.

I know that the RIRs have efforts underway to publish such authoritative lists. 
I do not know the exact status of this work. But I fully agree with your requirement
for a *single* *authoritative* list.

Of course I would use it in the routers I operate. However these are not significant
to many peoiple these days.

Daniel

PS: I do not care at all about the format as long as it is readily machine parseable.

Daniel