Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd)

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jun 2004 23:10:54 +0200

On 18-jun-04, at 23:06, Pekka Savola wrote:

> IMHO, making sure that renumbering a network is as simple as it can be
> is a subject which is very much related to multi6 designs.. and IMHO
> an operational requirement if we wish to deploy a model where we might
> envision populating hosts on a site with multiple addresses.

> So, review of the v6ops document describing a renumbering procedure
> would be very much appreciated.  Please send the comments on v6ops
> list!

Ok, first comment is relevant to multi6:

Having two prefixes at the same time lands you squarely inside the 
domain of draft-huitema-... The draft now assumes that having both old 
and new addresses works, and this isn't an assumption you can just 
make. In the case of changing addresses where both address ranges come 
from the same ISP this could be the case, but I don't see how this 
would be a regularly occurring event (after the 6bone has been shut 
down). In the case that both prefixes come from different ISPs, the 
network essentially becomes multihomed periodically, so it suffers all 
the ingress filtering trouble that we've been discussing in multi6. The 
draft only talks about ingress filtering with regard to security, which 
IMNSHO is stupid because there are no attacks that are possible with 
spoofed addresses that aren't possible with unspoofed addresses. It's 
just that tracking the attacks down takes longer. The real issue is 
that you MUST deliver packets to the ISP that matches the source 
address or you have no connecitivity. There are three ways this can 
happen:

1. disable ingress filtering for one ISP and route everything over that 
ISP
2. use policy routing or some other source address based routing to 
route packets to the ISP matching the source address
3. have a flag day

Talking about flag days: I'm missing a discussion on making use of the 
possibility of deprecating a prefix when stateless autoconfiguration is 
used. This mechanism makes it possible to move all new (outgoing) 
sessions to a new prefix in a couple of minutes.

All in all I think this draft is suffering from lack of ambition. 
Either provide some real guidance rather than a bunch of truisms or 
drop the whole thing.

As I'm feeling generous today here's a partial list of suggestions in 
the area of renumbering that people usually only get to read after 
paying $40 or so:

- register the new addresses for authorative nameservers with all 
pertinent registries as soon as the nameservers are reachable over the 
new addresses
- there are two ways to change server addresses fairly painlessly: 
lower the DNS TTLs and do it at once, or run two addresses side by side 
for a while. The latter is usually more work but can be done without 
any interruption at all
- log (attempted) use of the old addresses to see whether everything 
has switched
- turn off the old addresses for a while to flush out the last users, 
then turn them back on again so those last users get to change over 
without too much network interruption
- when the old addresses are removed, do traceroutes in various places 
to see if they're really gone

---

From: Tim Chown <[email-masked]>
Date: Mon, 21 Jun 2004 09:16:46 +0100

On Mon, Jun 21, 2004 at 09:49:13AM +0200, Eliot Lear wrote:
> 
> One of us has missed the point.  Firewalls today filter packets based on 
> destination address.  While I would agree that filtering on a source 
> FROM the Internet would be foolish, different hosts on the perimeter may 
> require different levels of protection.  Regardless, those rules exist 
> today inside firewalls and would need to be changed, and that's what 
> we're saying.

It's probablymuch more common than you'd fear that sites use source address
based filtering in firewalls.   And of course that's the snag that the
firewall rules need updating (or at least reloading/resolving) on remote
site firewalls not just on the renumbering site.   There's also plenty of
examples of source IP based access controls in other places, e.g. in the
transport layer in TCP wrapper configuration files, or in the application
layer with, e.g., IP-based access control to web resources (publisher
material being a common one in academic circles - a big university is granted
access by it's whole Class B site block).

> Want to make it easier?  Great.  I'm all ears.  Perhaps that will be the 
> killer app for IPv6, but I doubt it.  My motivation was really to make 
> incremental progress on eliminating the need for site-local and natting.

I think the scope and motivation is very good :)

Tim

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Jun 2004 09:49:13 +0200

Iljitsch van Beijnum wrote:

> and new addresses works, and this isn't an assumption you can just make.

No, we assume that the network is in a nominal state prior to 
renumbering.  The issue you raise below would indicate that perhaps this 
*isn't* the case.  In which case your problems are bigger than renumbering.

> In the case of changing addresses where both address ranges come from 
> the same ISP this could be the case, but I don't see how this would be a 
> regularly occurring event (after the 6bone has been shut down). In the 
> case that both prefixes come from different ISPs, the network 
> essentially becomes multihomed periodically, so it suffers all the 
> ingress filtering trouble that we've been discussing in multi6. 

We make note of the fact that there is a linkage between the upstream 
ISP and the network.  What perhaps we should state is that upstreams may 
need to know about each other from anti-spoofing mechanism.

> The 
> spoofed addresses that aren't possible with unspoofed addresses. 

> It's 
> just that tracking the attacks down takes longer. The real issue is that 
> you MUST deliver packets to the ISP that matches the source address or 
> you have no connecitivity. There are three ways this can happen:
> 
> 1. disable ingress filtering for one ISP and route everything over that ISP

This configuration either exists prior to the renumbering events or it 
doesn't.  If it does it would need to be modified to match the new 
addresses.  The renumbering document does not attempt to solve the 
multi6 problem.

> sessions to a new prefix in a couple of minutes.

This is a best case scenario that assumes all the appropriate linkages 
for reverse dns lookups that almost assuredly don't exist, not to 
mention the TTLs that are present.  If what you wrote above was the 
general case I wouldn't have cared to get involved in such a document.

> 
> All in all I think this draft is suffering from lack of ambition. Either 
> provide some real guidance rather than a bunch of truisms or drop the 
> whole thing.

This draft's ambition is to document the process, and perhaps point out 
a few areas for improvement in the standards/development front.  I 
personally think it also shows that the problem is really no less 
complex than IPv4, and if we add the MULTI6 fun, we could make it moreso.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 21 Jun 2004 12:25:23 +0200

On 21-jun-04, at 9:49, Eliot Lear wrote:

>> The draft now assumes that having both old and new addresses works, 
>> and this isn't an assumption you can just make.

> renumbering.  The issue you raise below would indicate that perhaps 
> this *isn't* the case.  In which case your problems are bigger than 
> renumbering.

I don't understand what you're getting at.

My point is that if you have two prefixes from two ISPs (which I think 
is the most common situation in renumbering, and it's certainly common 
enough to be worthy of discussion in a renumbering draft) and both ISPs 
do ingress filtering (which is also something that can't be discounted) 
then "turning on" both prefixes at the same time without additional 
measures is going to lead to problems as packets routed to ISP A may 
have a source address from the prefix from ISP B (or vice versa) and 
thus be dropped due to ingress filtering.

> ISP and the network.  What perhaps we should state is that upstreams 
> may need to know about each other from anti-spoofing mechanism.

But what if the ISPs aren't prepared to cooperate? Not everyone is a 
fortune 1000 company.

>> The draft only talks about ingress filtering with regard to security, 
>> which IMNSHO is stupid because there are no attacks that are possible 
>> with spoofed addresses that aren't possible with unspoofed addresses.

> One of us has missed the point.  Firewalls today filter packets based 
> on destination address.  While I would agree that filtering on a 
> source FROM the Internet would be foolish, different hosts on the 
> perimeter may require different levels of protection.  Regardless, 
> those rules exist today inside firewalls and would need to be changed, 
> and that's what we're saying.

Yes, but this has very little to do with ingress filtering by ISPs, so 
the current text obscures the issue rather than illuminate it.

>> It's just that tracking the attacks down takes longer. The real issue 
>> is that you MUST deliver packets to the ISP that matches the source 
>> address or you have no connecitivity.

> addresses.

Nonsense. The existence of two prefixes at the same time is exclusively 
related to renumbering in non-multihomed networks, so it has no 
relation to the state of the network either before or after 
renumbering.

> This draft's ambition is to document the process, and perhaps point 
> out a few areas for improvement in the standards/development front.  I 

Actually it is much less complex unless people extensively use manually 
configured addresses. The problem with IPv4 is deciding on subnet 
sizes, merging subnets, avoiding overlap and so on. None of this is an 
issue with IPv6 since everything fits in a standard issue /64.

Obviously there is lots of other stuff that remains the same but what 
else is new.

> Want to make it easier?  Great.  I'm all ears.

There are some pages in my book about renumbering (in IPv4). Feel free 
to borrow from that (not the literal text, of course).

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 21 Jun 2004 17:38:11 +0200

[dropping multi6]

On 21-jun-04, at 13:25, Eliot Lear wrote:

> Okay, the confusion in this exchange stems from which "ingress" we 
> were talking about.

Shame we don't have better terminology here.

>>> We make note of the fact that there is a linkage between the 
>>> upstream ISP and the network.  What perhaps we should state is that 
>>> upstreams may need to know about each other from anti-spoofing 
>>> mechanism.

> Okay, I follow you.  The draft attempts to cover ground in two areas:

> 1.  That which can be done today;

> 2.  What needs to be fixed.  I believe you're arguing for a fix, and 
> perhaps some text in the draft would be good.

I wasn't arguing for a fix, although an automated way to open up 
ingress filtering by ISPs would be very useful here.

What I am arguing for is acknowledging this issue in the draft so that 
people know what they can do to work around this problem.

>> Actually it is much less complex unless people extensively use 
>> manually configured addresses. The problem with IPv4 is deciding on 
>> subnet sizes, merging subnets, avoiding overlap and so on. None of 
>> this is an issue with IPv6 since everything fits in a standard issue 
>> /64.

> We have saved network managers from requiring a set of spreadsheet 
> operations.  BFD.  The level of complexity is substantially the same.

Actually this is a big deal, as in IPv4 address management is so 
problematic that renumbering pretty much requires manual intervention. 
While I agree that all the other issues, such as the DNS and access 
filters, are also problematic, it's certainly within the realm of 
possibility to automate these issues.

> IPv6 was billed as a great self-configuring does-everything-but-eat 
> follow-on to IPv4.  Very little of that is true today.

Yes, when do we get to discover DNS resolvers automatically?

Other than that the situation isn't as bad as you make it seem.

> We'd like to identify the mechanisms that would improve matters, at 
> least for IPv6. Who knows?  Maybe for IPv4 as well.  For instance, 
> what you're looking for above is some way for providers to learn about 
> customers' alternative published connectivity, such as a more robust 
> and accurate RADB in order to configure ingress access-lists.  One 
> needs to understand who's authoritative for the information, and what 
> the keys are.  Certainly the keys are unlikely to be IP address 
> prefixes :-(

This is pretty much a non-issue as these filters can be created using 
unicast reverse path forwarding (uRPF). However, I agree that better IP 
address authorization information would be good, if we get this then we 
may be able to secure interdomain routing much better. (See S-BGP and 
soBGP, although neither of those is necessary if vendors implement 
better mechanisms to upload long prefix filters to routers.)

> As to whether the providers are willing to implement such a mechanism, 
> I can't say.  They will look for an easier way, and that easier way 
> today is a NAT that does source selection (policy routing).

I don't see the relation between NAT and policy routing. Both are 
harmful, though.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Jun 2004 13:25:51 +0200

Okay, the confusion in this exchange stems from which "ingress" we were 
talking about.

> thus be dropped due to ingress filtering.

Right, I agree.

> the current text obscures the issue rather than illuminate it.

Two different points.

> related to renumbering in non-multihomed networks, so it has no relation 
> to the state of the network either before or after renumbering.

Except of course for currently multihomed sites.

> configured addresses. The problem with IPv4 is deciding on subnet sizes, 
> merging subnets, avoiding overlap and so on. None of this is an issue 
> with IPv6 since everything fits in a standard issue /64.

IPv6 was billed as a great self-configuring does-everything-but-eat 
follow-on to IPv4.  Very little of that is true today.  We'd like to 
identify the mechanisms that would improve matters, at least for IPv6. 
Who knows?  Maybe for IPv4 as well.  For instance, what you're looking 
for above is some way for providers to learn about customers' 
alternative published connectivity, such as a more robust and accurate 
RADB in order to configure ingress access-lists.  One needs to 
understand who's authoritative for the information, and what the keys 
are.  Certainly the keys are unlikely to be IP address prefixes :-(

As to whether the providers are willing to implement such a mechanism, I 
can't say.  They will look for an easier way, and that easier way today 
is a NAT that does source selection (policy routing).

Eliot

---

From: Pekka Savola <[email-masked]>
Date: Thu, 24 Jun 2004 00:23:41 +0300 (EEST)

> thus be dropped due to ingress filtering.

I think the document as it is has two assumptions about this:

 (1) you either renumber inside an ISP, or

 (2) you multihome to at least two different ISPs, and may be:
   a) switching from the first to the second ("transitional 
multihoming")
   b) switching from the first to the third, but keeping the second

(1) requires no ingress filtering magic.  Either of options in (2) 
*already* require that there is a mechanism in place, like 
draft-huitema-multi6-xxx (e.g., source-based routing at the edges), to 
ensure the right packets go to the right place.  This requirement 
would exist without renumbering as well.

In your earlier mail, you wrote:

> The draft only talks about ingress filtering with regard to
> security, which IMNSHO is stupid because there are no attacks that
> are possible with spoofed addresses that aren't possible with
> unspoofed addresses.

Not quite so, or at least requiring a clarification.  Remember that
the *sites* should also check that no packets with their IP addresses 
are coming from the Internet to them, using their addresses.  This is 
also called "ingress filtering", but was probably not the nuance 
mentioned in the draft.

I think the point you're making is subtle, and I'm not sure if I 
understand it myself.  Doesn't ingress filtering by the ISP block the 
site from performing e.g., certain kinds of 3rd party bombing DoS 
attacks?  This is something that's prevented (from a particular 
direction) with ingress filtering.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings