Weekly posting summary for multi6 <at> ops.ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 33.33% |    3 | 33.68% |     9141 | brc <at> zurich.ibm.com
 11.11% |    1 | 13.28% |     3603 | gih <at> telstra.net
 11.11% |    1 | 13.07% |     3548 | erik.nordmark <at> sun.com
 11.11% |    1 | 11.13% |     3020 | ww <at> styx.org
 11.11% |    1 | 10.65% |     2891 | sra <at> hactrn.net
 11.11% |    1 | 10.62% |     2882 | lear <at> cisco.com
 11.11% |    1 |  7.58% |     2056 | iljitsch <at> muada.com
--------+------+--------+----------+------------------------
100.00% |    9 |100.00% |    27141 | Total

Grunchweather Associates provides this automatic summary on an at-whim
basis at the request of the MULTI6 WG chairs.  Your mileage may vary.
We decline responsibilities, all shapes, all sizes, all colors.
If this script produces broken output, you get to keep both pieces.

Please respond if attending June 14 MULTI6 meeting

Everybody,

The announcement for the interim meeting is attached again below.
Please reply to me (NOT the list) if you plan to attend. (The people
who already said yes to this date don't need to reply again.)

Geoff Huston's draft on the architectural analysis will be posted
very shortly. Discussion on the list will be very welcome, of course,
and this will be a major topic at the meeting.

I'd also like to tell you that as well as assistance from our host,
the IPv6 Summit, the direct costs of our meeting will be sponsored
by Autonomica AB in Sweden. Thanks Kurtis!

    Brian Carpenter
    co-chair

Re: Please respond if attending June 14 MULTI6 meeting

RE: Please respond if attending June 14 MULTI6 meeting

RE: F1000 requirements?

Erik,

The desire (requirement) is to have international addressability/routing without revealing the
existence of internal nodes or network topology except to a select (controlled) group of outsiders -- and
only then on a "need to know" basis. No conditions are placed on how this can be achieved. 

--Eric

-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark <at> sun.com]
Sent: Tuesday, April 27, 2004 7:30 AM
To: Fleischman, Eric
Cc: Multi6 List
Subject: F1000 requirements?

Eric,

Some clarifying questions about this to helpme understand what you see
as the requirements:

> 2) Our security people are currently enamored by NATs as a security
> mechanism. I am aware of what the IETF's security people think about this
> and I myself have worked in the real time multimedia arena since the
> mid-90s, so you know what I think about it (i.e., NATs hinder real time
> communications). But there you have it: a community that currently plans to
> deploy NATs regardless. What would help people like me to educate our
> security people would be if the IETF came up with an Informational RFC for
> how we can do NAT-like things without NATs within IPv6. That is, our
> security people use NATs as a part of a larger defense-in-depth strategy to
> completely hide our internal networking environment from anybody on the
> "outside". E.g., we don't want people on the "outside" to be able to learn
> the IP address of an Oracle server in a data center.

The example shows hiding an individual IP address which I understand
(and is easy to do using the larger IPv6 address space).
Do you also care significantly about hiding the subnet numbers i.e.
prevent an external entity from comparing bit 49 through 64 in two
of your IPv6 addresses to see if they are located on the same subnet?

Some multihoming proposals (such as NOID) use the DNS to provide the
mapping between the set of IPv6 addresses assigned to a node.
Would such an approach cause a problem for hiding the Oracle server
in your example? Couldn't the Oracle server be assigned an obfuscated
domain name (<very long string of random digits/characters>.example.com)
and only your partners would be told the domain name to use?

   Erik

RE: F1000 requirements?

    > From: "Fleischman, Eric" <eric.fleischman <at> boeing.com>

    > The desire (requirement) is to have international addressability /
    > routing without revealing the existence of internal nodes or network
    > topology except to a select (controlled) group of outsiders

Let me understand this more fully. Are there a set of entities outside with
whom which you wish to communicate, but whom you *do not* want to have
knowledge of your network topology?

If so, that would imply that the information that those parties would have to
have about the local host at your site they were talking to would have to
come in two parts: i) a location as to where your whole site is (relative to
the topology of the network as a whole), and ii) an opaque token of some sort
which would have to be translated to give the location of the local host
within your network.

If there are no such entities, I'm not sure what the problem is: you don't
give anyone outside the address (which would reveal your network topology) of
the local host unless they are in the set which is authorized to know about
your network - but in that case there's no problem. From which I conclude
that probably there are such entities.

If so, are you willing to pay the translation overhead (which I don't see how
to avoid - you don't want to give them detailed information about the
location of the local host, ergo that information [which you have to have, to
get the packets to the local host] has to be added after it leaves the
source) on each packet?

	Noel

RE: F1000 requirements?

Noel,

You have stated our intention well. The intention is indeed to provide an address to authorized outsiders
that does not reveal internal network information.

Currently (with IPv4) the "translation overhead" you allude to is a NAT. Can Multi6 provide for an
alternative mechanism or will NATs remain for IPv6?

--Eric

-----Original Message-----
From: Noel Chiappa [mailto:jnc <at> mercury.lcs.mit.edu]
Sent: Monday, May 03, 2004 1:26 PM
To: multi6 <at> ops.ietf.org
Cc: jnc <at> mercury.lcs.mit.edu
Subject: RE: F1000 requirements?

    > From: "Fleischman, Eric" <eric.fleischman <at> boeing.com>

    > The desire (requirement) is to have international addressability /
    > routing without revealing the existence of internal nodes or network
    > topology except to a select (controlled) group of outsiders

Let me understand this more fully. Are there a set of entities outside with
whom which you wish to communicate, but whom you *do not* want to have
knowledge of your network topology?

If so, that would imply that the information that those parties would have to
have about the local host at your site they were talking to would have to
come in two parts: i) a location as to where your whole site is (relative to
the topology of the network as a whole), and ii) an opaque token of some sort
which would have to be translated to give the location of the local host
within your network.

If there are no such entities, I'm not sure what the problem is: you don't
give anyone outside the address (which would reveal your network topology) of
the local host unless they are in the set which is authorized to know about
your network - but in that case there's no problem. From which I conclude
that probably there are such entities.

If so, are you willing to pay the translation overhead (which I don't see how
to avoid - you don't want to give them detailed information about the
location of the local host, ergo that information [which you have to have, to
get the packets to the local host] has to be added after it leaves the
source) on each packet?

	Noel

RE: F1000 requirements?

Eric, 

I have one question about this requirement and I hope you can 
help me understand it:

I assume F1000 companies, indeed all companies, have 
firewalls. So why is it important to hide addresses?

Hesham

 > The desire (requirement) is to have international 
 > addressability/routing without revealing the existence of 
 > internal nodes or network topology except to a select 
 > (controlled) group of outsiders -- and only then on a "need 
 > to know" basis. No conditions are placed on how this can be 
 > achieved. 
 > 
 > --Eric
 > 
 > -----Original Message-----
 > From: Erik Nordmark [mailto:Erik.Nordmark <at> sun.com]
 > Sent: Tuesday, April 27, 2004 7:30 AM
 > To: Fleischman, Eric
 > Cc: Multi6 List
 > Subject: F1000 requirements?
 > 
 > 
 > Eric,
 > 
 > Some clarifying questions about this to helpme understand 
 > what you see
 > as the requirements:
 > 
 > > 2) Our security people are currently enamored by NATs as a security
 > > mechanism. I am aware of what the IETF's security people 
 > think about this
 > > and I myself have worked in the real time multimedia arena 
 > since the
 > > mid-90s, so you know what I think about it (i.e., NATs 
 > hinder real time
 > > communications). But there you have it: a community that 
 > currently plans to
 > > deploy NATs regardless. What would help people like me to 
 > educate our
 > > security people would be if the IETF came up with an 
 > Informational RFC for
 > > how we can do NAT-like things without NATs within IPv6. 
 > That is, our
 > > security people use NATs as a part of a larger 
 > defense-in-depth strategy to
 > > completely hide our internal networking environment from 
 > anybody on the
 > > "outside". E.g., we don't want people on the "outside" to 
 > be able to learn
 > > the IP address of an Oracle server in a data center.
 > 
 > The example shows hiding an individual IP address which I understand
 > (and is easy to do using the larger IPv6 address space).
 > Do you also care significantly about hiding the subnet numbers i.e.
 > prevent an external entity from comparing bit 49 through 64 in two
 > of your IPv6 addresses to see if they are located on the same subnet?
 > 
 > Some multihoming proposals (such as NOID) use the DNS to provide the
 > mapping between the set of IPv6 addresses assigned to a node.
 > Would such an approach cause a problem for hiding the Oracle server
 > in your example? Couldn't the Oracle server be assigned an obfuscated
 > domain name (<very long string of random 
 > digits/characters>.example.com)
 > and only your partners would be told the domain name to use?
 > 
 >    Erik
 > 
 > 
 > 

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is 
strictly prohibited.  If you are not the intended recipient please contact
the sender and delete all copies.
========================================================

Fwd: I-D ACTION:draft-huston-multi6-architectures-00.txt

				

FYI.

kurtis -

Begin forwarded message:

> From: Internet-Drafts <at> ietf.org
> Date: den 3 maj 2004 21.54.11 MET
> To: i-d-announce <at> ietf.org
> Subject: I-D ACTION:draft-huston-multi6-architectures-00.txt
> Reply-To: internet-drafts <at> ietf.org
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
>
> 	Title		: Architectural Approaches to Multi-Homing for IPv6
> 	Author(s)	: G. Huston
> 	Filename	: draft-huston-multi6-architectures-00.txt
> 	Pages		: 31
> 	Date		: 2004-5-3
> 	
> This memo provides an analysis of the aspects of multi-homing support
>    for the IPv6 protocol suite. The purpose of this analysis is to
>    provide a taxonomy for classification of various proposed approaches
>    to multi-homing. It is also an objective of this exercise to  
> identify
>    common aspects of this domain of study, and also to provide a
>    framework that can allow exploration of some of the further
>    implications of various architectural extensions that are intended  
> to
>    support multi-homing.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-huston-multi6-architectures 
> -00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request <at> ietf.org with the word unsubscribe in the body of  
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> 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-huston-multi6-architectures-00.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:
> 	mailserv <at> ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-huston-multi6-architectures-00.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.
> Content-Type: text/plain
> Content-ID:	<2004-5-3161429.I-D <at> ietf.org>

[Fwd: I-D ACTION:draft-huston-multi6-architectures-00.txt]

-------- Original Message --------
Subject: I-D ACTION:draft-huston-multi6-architectures-00.txt
Date: Mon, 03 May 2004 15:54:11 -0400
From: Internet-Drafts <at> ietf.org
Reply-To: internet-drafts <at> ietf.org
To: i-d-announce <at> ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Architectural Approaches to Multi-Homing for IPv6
	Author(s)	: G. Huston
	Filename	: draft-huston-multi6-architectures-00.txt
	Pages		: 31
	Date		: 2004-5-3
	
This memo provides an analysis of the aspects of multi-homing support
    for the IPv6 protocol suite. The purpose of this analysis is to
    provide a taxonomy for classification of various proposed approaches
    to multi-homing. It is also an objective of this exercise to identify
    common aspects of this domain of study, and also to provide a
    framework that can allow exploration of some of the further
    implications of various architectural extensions that are intended to
    support multi-homing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-huston-multi6-architectures-00.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

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-huston-multi6-architectures-00.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:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-huston-multi6-architectures-00.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.

--

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM