Subject: Re: Possible IAB workshop on routing and addressing participants?

From: [email-masked]
Date: Thu, 15 Jun 2006 15:18:32 EDT

Some notes  inline. 
- The difficulty in changing provider due to
PA/CIDR addressing schemes 

HH:Why is the (primary )AS# not part of the destination address ?  

- The lack of effective  multi-homing support
HH: ...then multi-homing would become a  non-issue.

- Limited  capability to protect against either
the  spoofing of individual host IP addresses or
entire IP address blocks   
HH:IMHO: just the other way around.All anti-spoofing protocols just  
document: we are unable to do any better routing than Dijkstra.  If a packet arrives 
where Dijkstra does not let us expect it to  arrive...

- The limited  ability to secure the routing
system  itself, and
 
HH:For the same reason.

(ii).     Produce a prioritized list of requirements, all
of which must be met by a next generation routing
and addressing architecture. A sample list might
include (in no particular order):  

-  Retaining the connectionless datagram model of
IP routing
HH: I have been in favor of connections  for many years but  meanwhile have 
realized that pure IP forwarding can outperform any connection-TE  . Not only 
RSVP but also ATM and what is left over:MPLS. Where  is  IP Forwarding TE 
today? No WG for this :-( 
TE is not a synonym for MPLS !
 
The IETF
- Allow users (small  and large) to freely switch
between  providers without substantial service
interruption 

- Include survival of  higher-layer connections
and associations  when connectivity to
individual providers  changes 

HH:Can this be clarified?

- Allow both users and ISPs  to influence path
selection according to  traffic management and
classification  requirements

- Provide better support for  mobility and nomadicity

HH: Just remember the ATM Forum solutions!

-  Provide architected instrumentation facilities

HH:Yes, for ICANN itself.

- Allow at least one-to-many  multicast
HH:None of the existing multicast solutions can be taken seriously.Its only  
playing games. None is able to transmit soccer world  championship  matches.

- Prevent source  address spoofing
HH: At first enable better routing than  Dijkstra

- Provide a rational  economic basis for deployment
HH: especially for multicast.

- Secure the routing  infrastructure, including
the  authentication of updates and the
unauthorized injection of information into the
routing system  

- Define  scalability requirements for a next
generation routing system 
HH:replace BGP ! replace IPv6 !

Heiner  Hummel    

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 15 Jun 2006 16:38:20 -0400

We need to distinguish between layer-8 problems and technical
problems.  No amount of protocol work will solve some layer-8
problems.

> HH:Why is the (primary )AS# not part of the destination address ?  

In effect it is.  The address prefix is inherited from the provider,
unless a customer is large enough to have PI addresses.

Adding the AS number leaves you with the exact same problem.  To
change providers you'd have to change the end system addresses to
change the AS number which is exactly the problem.

Clearly NAT is not the solution.

DHCP helps.  Not having sysadmins that wire in IP addresses as a means
to support security helps.

With DHCP and dynamic DNS with DHCP is this just a technically solved
problem with dumb end users using persolution techniques too widely.

> HH: ...then multi-homing would become a  non-issue.

Multihoming is an issue but for small end sites like a small business,
it is impossible to multihome.  Just calling your MSO and ILEC and
asking for CATV IP and DSL IP won't get you the redundancy you want.

For that matter getting them to do a competent job of providing
DNS-inverse is hard enough.  Look at my subnet for an example - DNS
forward and inverse lookups don't match nothing I tell SBC aka AT&T so
far has helped.  Last answer I got was - we don't do DNS inverse for
DSL.

> where Dijkstra does not let us expect it to  arrive...

There was discussion among providers to filter SA based on routes for
that address being advertised for known single homed customers.  Some
may do this but not enough.  The closer to the core the harder it is
to be sure not to break things.  As I mentioned above the closer to
the edge the lower the clue factor of the providers (and often
customer).  So the practice is not widespread.

> - The limited  ability to secure the routing

Check the work of the RPS WG.  Providers have not registered in a RR
and made use of an RR in sufficient number.  For providers who use the
RR there is some improvement.  At the very least that provider can be
made immune to route spoofing of its own customers and of peers that
also use the registry.

Some of the proposals to try to solve the problem with crytographic
authentication embedded in the routing information have proven
infeasible (or at least impractical) at ISP scale so far.

> TE is not a synonym for MPLS !

Please get real.

> HH:Can this be clarified?

Don't nuke open TCP connections on provider transition.  IE: having
DHCP dole out new addresses after failover doesn't cut it.  That is
about as good as a small business could do if using IP offerings
intended for consumers and clueless small business.

> classification  requirements

This is a bad idea.  QoS has proven to be an unsellable service in an
Internet which is already quite good if the QoS will cost more.

> HH: Just remember the ATM Forum solutions!

You must be joking.

> HH:Yes, for ICANN itself.

The requirement seems like it touches on Layer-8 problems rather than
any technical issue.

You comment doesn't seem related.

> HH:replace BGP ! replace IPv6 !

btw- This isn't the meeting, its a call for comments on the
invitation.

Curtis