More scribe volunteers needed for interim meeting

Hi,

For the interim MULTI6 meeting on June 14, we still need
more volunteers to act as jabber scribes.

We will also need a scribe for the regular minutes.

Thanks

    Brian
    co-chair

RE: More scribe volunteers needed for interim meeting

Brian,

I can be a secondary jabber subscriber.  I may want to be active in the
meeting, so I may have some gaps in the transmission.

John

))) Message sent using Nokia Access Mobilizer (((

--- Original Message ---
From: ext Brian E Carpenter <brc <at> zurich.ibm.com>
To: Multi6 <multi6 <at> ops.ietf.org>
Date: Tue Jun 01  15:11:14 EEST 2004
Subject: More scribe volunteers needed for interim meeting

Hi,

For the interim MULTI6 meeting on June 14, we still need
more volunteers to act as jabber scribes.

We will also need a scribe for the regular minutes.

Thanks

    Brian
    co-chair

       

Re: More scribe volunteers needed for interim meeting

Thanks John! That's exactly why we need several scribes...

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

John Loughney wrote:
> Brian,
> 
> I can be a secondary jabber subscriber.  I may want to be active in the
> meeting, so I may have some gaps in the transmission.
> 
> John
> 
> 
> 
> ))) Message sent using Nokia Access Mobilizer (((
> 
> --- Original Message ---
> From: ext Brian E Carpenter <brc <at> zurich.ibm.com>
> To: Multi6 <multi6 <at> ops.ietf.org>
> Date: Tue Jun 01  15:11:14 EEST 2004
> Subject: More scribe volunteers needed for interim meeting
> 
> 
> Hi,
> 
> For the interim MULTI6 meeting on June 14, we still need
> more volunteers to act as jabber scribes.
> 

Re: Thank you!

Re: Thank you!

I-D ACTION:draft-nordmark-multi6-threats-01.txt (Fwd)

The draft contains a changelog in appendix A.

>----------------Begin Forwarded Message----------------<

Date: Fri, 04 Jun 2004 16:15:45 -0400
From: Internet-Drafts <at> ietf.org
Subject: I-D ACTION:draft-nordmark-multi6-threats-01.txt
To: i-d-announce <at> ietf.org

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

	Title		: Threats relating to IPv6 multihoming solutions
	Author(s)	: E. Nordmark, T. Li
	Filename	: draft-nordmark-multi6-threats-01.txt
	Pages		: 25
	Date		: 2004-6-4
	
This document lists security threats related to IPv6 multihoming.
   Multihoming can introduce new opportunities to redirect packets to
   different, unintended IP addresses.

   The intent is to look at how IPv6 multihoming solutions might make
   the Internet less secure than the current Internet, without studying
   any proposed solution but instead looking at threats that are
   inherent in the problem itself.  The threats in this document build
   upon the threats discovered and discussed as part of the Mobile IPv6
   work.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-01.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-nordmark-multi6-threats-01.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-nordmark-multi6-threats-01.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.
>----------------End Forwarded Message----------------<

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

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 16.67% |    1 | 69.35% |    35115 | kurtis <at> kurtis.pp.se
 33.33% |    2 | 10.49% |     5310 | brc <at> zurich.ibm.com
 16.67% |    1 |  8.92% |     4516 | erik.nordmark <at> sun.com
 16.67% |    1 |  6.40% |     3243 | john.loughney <at> nokia.com
 16.67% |    1 |  4.84% |     2450 | sra <at> hactrn.net
--------+------+--------+----------+------------------------
100.00% |    6 |100.00% |    50634 | 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.

Re: I-D ACTION:draft-nordmark-multi6-threats-01.txt (Fwd)

And this is the version we will review at the interim meeting
on June 14, so please read it before then!

   Brian
   co-chair

Erik Nordmark wrote:
> The draft contains a changelog in appendix A.
> 
> 
>>----------------Begin Forwarded Message----------------<
> 
> 
> Date: Fri, 04 Jun 2004 16:15:45 -0400
> From: Internet-Drafts <at> ietf.org
> Subject: I-D ACTION:draft-nordmark-multi6-threats-01.txt
> To: i-d-announce <at> ietf.org
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Threats relating to IPv6 multihoming solutions
> 	Author(s)	: E. Nordmark, T. Li
> 	Filename	: draft-nordmark-multi6-threats-01.txt
> 	Pages		: 25
> 	Date		: 2004-6-4
> 	
> This document lists security threats related to IPv6 multihoming.
>    Multihoming can introduce new opportunities to redirect packets to
>    different, unintended IP addresses.
> 
>    The intent is to look at how IPv6 multihoming solutions might make
>    the Internet less secure than the current Internet, without studying
>    any proposed solution but instead looking at threats that are
>    inherent in the problem itself.  The threats in this document build
>    upon the threats discovered and discussed as part of the Mobile IPv6
>    work.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-01.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-nordmark-multi6-threats-01.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-nordmark-multi6-threats-01.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.
> 
>>----------------End Forwarded Message----------------<
> 
> 
> 

Comments on draft-nordmark-multi6-threats-01

Substantive comments:

> 1.1.  Assumptions
...
> 
>    This document doesn't assume that the application protocols are
>    protected by strong security today or in the future.  However, it is
>    still useful to assume that the application protocols which care
>    about integrity and/or confidentiality apply the relevant end-to-end
>    security measures, such as IPsec or TLS.

That's a narrow view of e2e security; I would add "and/or applications
level security."

> 2.  TERMINOLOGY
...
> 
>       interface   - a node's attachment to a link.

Is this intended to include virtual or pseudo interfaces
such as tunnel end points?

> 
>       address     - an IP layer name that contains both topological
>                     significance and acts as a unique identifier for an
>                     interface.

There may be multiple addresses per interface.

> 
>       locator     - an IP layer topological name for an interface or a
>                     set of interfaces.

There may be multiple locators per interface.

>       identifier  - an IP layer identifier for an IP layer endpoint
>                     (stack name in [NSRG]).  The transport endpoint is a
>                     function of the transport protocol and would
>                     typically include the IP identifier plus a port
>                     number.

Do we believe there may be multiple identifiers per interface or per host?

 > 3.1.  Application Assumptions
...
>    The second class of applications use existing IP source addresses
>    from outside of their immediate local site as a means of
>    authentication without any form of verification.  Today, with source
>    IP address spoofing and TCP sequence number guessing as rampant
>    attacks, such applications are effectively opening themselves for
>    public connectivity and are reliant on other systems, such as
>    firewalls, for overall security.  We do not consider this class of
>    systems in this document.

...because they are in any case fully open to all forms of network
layer spoofing.

>    The third class of applications receive existing IP source addresses,
>    but attempt some verification using the DNS, effectively using the
>    FQDN for access control. (This is typically done by performing a
>    reverse lookup from the IP address followed by a forward lookup and
>    verifying that the IP address matches one of the addresses returned
>    from the forward lookup.)  These applications are already subject to
>    a number of attacks using techniques like source address spoofing and
>    TCP sequence number guessing since an attacker, knowing this is the
>    case, can simply create a DoS attack using a forged source address
>    that has authentic DNS records.  In general this class of
>    applications is strongly discouraged, but it is probably important
>    that a multihoming solution doesn't introduce any new and easier ways
>    to perform such attacks.

But do we desire to make reverse lookup checks for multihomed sites
succeed, to avoid multihoming failures for hosts using the broken
technique?

>    Finally, the fifth class of applications use cryptographic security
>    techniques but without strong identity (such as opportunistic IPsec).
>    Thus data integrity with or without confidentiality is provided when
>    communicating with an unknown/unauthenticated principal.  Just like
>    the first category above such applications can't perform access
>    control since they do not know the identity of the peer. 

This is true *at network level* but they may well have applications
level strong identity and that may be necessary and sufficient.

Nits:

 > 2.  TERMINOLOGY
...
 >     FQDN        - Fully Qualified Domain Name

I would add a reference to RFC 1594, which seems to be the only place
that FQDN is defined

> 3.1.  Application Assumptions
> 
>    In the Internet today, the initiating part of applications either
>    starts with a FQDN, which it looks up in the DNS, or already has an
>    IP address from somewhere.  For the FQDN to IP address lookup the
>    application effectively places trust in the DNS.  Once it has the IP
>    address, the application places trust in the routing system
>    delivering packets to that address.  Applications that use security
>    mechanisms, such as IPsec or TLS, with mutual authentication have the
>    ability to "bind" the FQDN to the cryptographic keying material thus
--------------------------------------------------------------------^^
missing punctuation
>    compromising the DNS and/or the routing system can at worst cause the
>    packets to be dropped or delivered to an entity which does not posses
>    the keying material.

...
> 5.  GRANULARITY OF REDIRECTION
> 
>    Different multihoming solutions might approach the problem at
>    different layers in the protocol stack.  For instance, there has been
------------------------------------------------------------------^^^
grammar
>    proposals on a shim layer inside IP as well as transport layer
---------------^^
grammar
>    approaches.  

     Brian

Final reminder about interim meeting on June 14

Here is a final reminder about the meeting on June 14.
For jabber fans, we are hoping to have scribes operating.

We may well re-time the agenda on site, and please remember
that you are expected to read the three drafts beforehand.

     Brian and Kurtis
     co-chairs

Updated announcement and agenda for MULTI6 WG interim meeting
=============================================================

Date:  Monday June 14, 2004
Time:  09:00 - 17:00  PDT
Place: Loews Beach Hotel, Santa Monica, CA, USA

This is the same location as the North American IPv6 Summit;
see http://www.usipv6.com/ for full logistics and hotel discount 
code. (Of course, you may also wish to register for the Summit.)

There are many other hotels and plenty of restaurants nearby.

The room will hold about 100 people; The informal count of
attendees is about 30. 

Breakfast and lunch NOT provided. Coffee breaks planned
at 10:00 and 15:00 PDT, lunch break around noon.

An informal "Bar BOF" will be held in the late afternoon of Sunday 
June 13 to prepare for the main meeting. Location: somewhere in
Loews Hotel.

The goal of the meeting is to reach common ground on architectural
analysis and on the impact of various classes of solution. It is
*not* to discuss solutions in detail or to choose one of them.

Draft agenda (comments welcome).

1. IPR reminder, logistics, agenda bashing (co-chairs, 10 min.)

2. Charter review (co-chairs, 5 min.)
http://www.ietf.org/html.charters/multi6-charter.html

3. Review "Things to think about" draft (Eliot Lear, 45 min.)

http://www.ietf.org/internet-drafts/draft-lear-multi6-things-to-think-about-02.txt

4. Review threats draft (Erik Nordmark, 45 min.)

http://www.ietf.org/internet-drafts/draft-nordmark-multi6-threats-01.txt

5. Review + discuss future Architecture draft (Geoff Huston 
   by phone, co-chairs, 2 hours)

http://www.ietf.org/internet-drafts/draft-huston-multi6-architectures-00.txt

6. Open discussion on the impact of various categories of solutions
   (co-chairs, 1 hour)

7. Conclusions of meeting and where to move from here.

    Brian Carpenter & Kurt Erik Lindqvist, multi6 co-chairs