Subject: I-D ACTION:draft-ietf-multi6-multihoming-requirements-04.txt

From: [email-masked]
Date: Mon, 07 Apr 2003 07:10:10 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF.

	Title		: Goals for IPv6 Site-Multihoming Architectures
	Author(s)	: B. Black, V. Gill, J. Abley
	Filename	: draft-ietf-multi6-multihoming-requirements-04.txt
	Pages		: 9
	Date		: 2003-4-4
	
Site-multihoming, i.e. connecting to more than one IP service
provider, is an essential component of service for many sites which
are part of the Internet.  Existing IPv4 site-multihoming practices
provide a set of capabilities that it would ideally be accommodated
by the adopted site-multihoming architecture in IPv6, and a set of
limitations that must be overcome, relating in particular to
scalability.
This document outlines a set of goals for proposed new IPv6
site-multihoming architectures.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-requirements-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-multi6-multihoming-requirements-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-multi6-multihoming-requirements-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 8 Apr 2003 09:20:53 +0200

All,

Me and Sean will give people the time to (re-)read this document, and  
in two weeks issue WG last call on this. I hope this should not be to  
controversial...:-)

- kurtis -

On måndag, apr 7, 2003, at 13:10 Europe/Stockholm,  
[email-masked] wrote:

> 	"FILE  
> /internet-drafts/draft-ietf-multi6-multihoming-requirements-04.txt".
> 	
> Content-Type: text/plain
> Content-ID:	<[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Apr 2003 09:48:01 +0200

I think this is about ready to ship. Just a few points, essentially
editorial except for the very last one.

> Abstract

The second sentence is very hard to understand, contains at least one
grammatical error, and distracts from the main message. I would simply
delete it.

...
> 3.2.2 Impact on Routers
> 
>    The solution may require changes to IPv6 router implementations, but
>    these changes must be either minor, or in the form of logically
s/must/should/
>    separate functions added to existing functions.
> 
>    Such changes should not prevent normal single-homed operation, and
>    routers implementing these changes must be able to interoperate fully
s/must/should/
>    with hosts and routers not implementing them.
> 
> 3.2.3 Impact on Hosts
> 
>    The solution should not destroy IPv6 connectivity for a legacy host
>    implementing RFC 2373 [3], RFC 2460 [5], RFC 2553 [6] and other basic
s/2373/3513/
>    IPv6 specifications current in November 2001. That is to say, if a
s/November 2001/April 2003/
>    host can work in a single-homed site, it must still be able to work
s/must/should/
>    in a multihomed site, even if it cannot benefit from
>    site-multihoming.
> 
>    It would be compatible with this requirement for such a host to lose
s/requirement/goal/
>    connectivity if a site lost connectivity to one transit provider,
>    despite the fact that other transit provider connections were still
>    operational.

...

> 3.2.7 Multiple Solutions
> 
>    There may be more than one approach to multihoming, provided all
>    approaches are orthogonal (e.g. each approach addresses a distinct
s/(e.g./i.e./
>    segment or category within the site multihoming problem. Multiple
>    solutions will incur a greater management overhead, however, and the
>    adopted solutions SHOULD attempt to cover as many multihoming
s/SHOULD/should/
>    scenarios as possible.
s/scenarios/scenarios and goals/

> 
> 4. Security Considerations
> 
>    A multihomed site should not be more vulnerable to security breaches
>    than a traditionally IPv4-multihomed site.
 
Should we add "or a single-homed IPv6 site"?

    Brian

---

From: Sean Doran <[email-masked]>
Date: Wed, 16 Apr 2003 13:54:58 +0100

On Wednesday, Apr 16, 2003, at 08:48 Europe/London, Brian E Carpenter 

> Should we add "or a single-homed IPv6 site"?

Site multihoming has costs.  One of the obvious possible side-effects
of being multihomed is an increase in potential vulnerabilities.  I 
would prefer
to see them documented than precluded (the known space in which a 
solution
may be found is already too small) or denied.

I think the goal of being no worse for a site than multihoming using 
IPv4
is admirable and at least mostly tractable.

	Sean.

---

From: Joe Abley <[email-masked]>
Date: Wed, 16 Apr 2003 09:39:55 -0400

On Wednesday, Apr 16, 2003, at 03:48 Canada/Eastern, Brian E Carpenter 

> grammatical error, and distracts from the main message. I would simply

Very happy to do so, and I apologise for my hideous wordcrime.

>>    these changes must be either minor, or in the form of logically

fixed

>>    routers implementing these changes must be able to interoperate 

fixed

>>    implementing RFC 2373 [3], RFC 2460 [5], RFC 2553 [6] and other 

fixed

> s/November 2001/April 2003/

fixed already

>>    host can work in a single-homed site, it must still be able to work

fixed

>>    It would be compatible with this requirement for such a host to 

fixed

>>    approaches are orthogonal (e.g. each approach addresses a distinct

Arrgh, fixed.

>>    adopted solutions SHOULD attempt to cover as many multihoming

fixed

> s/scenarios/scenarios and goals/

good idea

> Should we add "or a single-homed IPv6 site"?

Is that reasonable? Or does the addition of an entry-point to a 
single-homed site make it inherently more vulnerable, in some small way?

In response to some other private feedback, I also added the following 
sentence to the security section:

     <t>Any changes to routing practices made to accommodate multihomed
       sites should not cause non-multihomed sites to become more
       vulnerable to security breaches.</t>

Comments on that would be appreciated.

Thanks, Brian.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Apr 2003 16:55:04 +0200

Joe Abley wrote:
...
> Comments on that would be appreciated.

I think that is good. I'll certainly concede to you and Sean
on my own suggestion, but I fear we will get pushback from
the IESG if we produce a solution that does weaken security.

    Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Apr 2003 17:13:36 +0200

> Comments on that would be appreciated.

Security breach != DoS ?

---

From: Joe Abley <[email-masked]>
Date: Wed, 16 Apr 2003 11:19:58 -0400

On Wednesday, Apr 16, 2003, at 11:13 Canada/Eastern, Iljitsch van 
Beijnum wrote:

>> In response to some other private feedback, I also added the 
>> following sentence to the security section:
>

Your point is that other non-multihomed sites are more vulnerable to 
DoS attacks from me because I am multi-homed?

I don't think that's the case; whether or not I decide to DoS another 
site seems orthogonal to the number of ways I have of launching one.

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Apr 2003 17:24:51 +0200

> DoS attacks from me because I am multi-homed?

My point is that ingress filtering between ISPs may be problematic with 
some routing approaches. This is a problem, but not enough to forego 
these approaches, IMO.

---

From: Sean Doran <[email-masked]>
Date: Wed, 16 Apr 2003 16:48:38 +0100

On Wednesday, Apr 16, 2003, at 15:55 Europe/London, Brian E Carpenter 

>>        sites should not cause non-multihomed sites to become more

"or the core"  -- so perhaps 'other parts of the Internet, including 
non-multihomed sites'.

> the IESG if we produce a solution that does weaken security.

There will be even more immediate pushback (i.e., well before IESG)
if we can't justify any trade-offs between utility and security which 
favour
the former.   Hopefully a compelling justification will lessen any 
pushback,
assuming any new vulnerabilities / weaknesses are known to exist in
whatever work emanates from here.

	Sean.