headers
Mark Townsley | 1 Mar 2010 11:16
Picon
Favicon

Re: Draft input requested for draft-azinger-additional-private-ipv4-space-issues-02


Nice overview, thanks for putting this together Marla and Leo. I have 
just 3 suggestions at the moment:

1. You might mention that some equipment relies upon, potentially 
hard-coded, rules for RFC1918 space. A number of 6to4 implementations, 
firewalls, etc. You touched on this with CPE default configuration, but 
I think it is a bit more broad than that (the firewall example was used 
in a presentation to the int-area in the past, IIRC). The issue with 
6to4 is that a typical 6to4 implementation might consider an IPv4 
address from a "new private IPv4" address range embedded in an IPv6 
address as global, creating black holes for the 6to4 user in areas where 
the Ipv4 address was not reachable. Worse, this would show up as "IPv6 
not working" to someone not versed in what was happening with IPv4, 
further hindering deployment of IPv6.

2. In section 3:

    For instance, it is often technically feasible to use NAT or
    even multiple layers of NAT within the networks operated by
    residential users or corporations where peer to peer communication is
    not needed.    Where peer to peer communication is needed or where
    services or applications do not work properly behind NAT, globally
    unique address space is required.

Certainly, "peer to peer communication" happens through multiple NATs, 
even if it is a lot of work.

I think the more important issue to highlight in place of this is 
build-up of "per-flow" state in equipment and associated
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Townsley | 1 Mar 2010 12:06
Picon
Favicon

Re: DHCP-based subscriber authentication


I won't be able to attend the upcoming IETF (if all continues to go 
well, I will be taking care of my new daughter slated to arrive in the 
next couple of weeks instead!).

If I were to be there, I'm sure that during discussion I would try and 
point out the irony of how much WG time and effort has been put into 
this, while still dancing around whether it is an official WG item. If 
only all of our official WG documents were guaranteed so much WG attention.

Given the interest-level from operators, running code available, and WG 
time spent, I think that it is high time to call a fig a fig and publish 
what has been done here.  If there is no consensus on making this a 
standards track work, classify it as Informational or Experimental. 
Informational would seem to fit the bill best, and if the dhc WG wants 
to continue to avoid making a call, this could be handled by a willing 
AD shepherding it through the IESG with all appropriate disclaimers, and 
then some, applied.

Personally, I'd rather see the dhc WG take on the work officially, and 
continue to provide the guidance it already has (including weighing in 
on all the various similar proposals that are popping up). Continuing in 
this grey-area of working on the document, but not really working on the 
document, just makes us look more interested in document labels than 
engineering.

- Mark

On 2/19/10 7:35 PM, Ralph Droms wrote:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ted Lemon | 1 Mar 2010 19:54

Re: DHCP-based subscriber authentication

Mark, the problem we have is that there's no consensus in the DHC working group at the moment to take up the
work, and no consensus to drop it, which, as you observe, is a recipe for wasting a lot of cycles on a
non-working-group item.

And unfortunately the work, as it stands, is pretty broken in what it does to the DHCP protocol state
machine.   The fact that you have running code doesn't ameliorate that - I've seen plenty of protocols that
are fundamentally broken but that can be made to work when people who understand the goal are working
together to write interoperable implementations.   That doesn't mean that someone reading the spec could
make an interoperable implementation that would work dependably.

So this leaves us in the awkward situation where it would probably be beneficial for us to work on it, because
we could make it less broken, but we don't have consensus to work on it, so we can't make it less broken.   So we
basically have the choice between publishing a document describing something that's very broken, or not
publishing the document.

I'd much rather that one of our options was to fix it.   If you have any suggestions for how we could get to that,
I'd like to hear them.
Permalink | Reply | 0 comments |
headers
IESG Secretary | 1 Mar 2010 20:00
Picon
Favicon

IETF Workshop on Broadband Home Gateways

During the 76th IETF meeting, the Transport Area sponsored a Broadband
Home Gateway BoF, called HOMEGATE. Since that time, interested IETF
participants have been working to narrow the scope of the draft charter
and to reach out to other Standards Development Organizations (SDOs) to
ensure that the planned work is complimentary and not overlapping with
their respective work.

To further that goal, the IETF's Transport and Internet Areas intend to
co-sponsor a two-day workshop on HOMEGATE between IETF-77 and IETF-78.
This workshop is slated to take place on April 20-21, 2010 in London,
England.

In order to reserve a properly sized meeting facility, it is important
for interested people to indicate their interest in attending AS SOON AS
POSSIBLE. Please do so at http://event.pingg.com/HomeGateLondonMtg

NOTE: Due to potential venue limitations and the desire to allow
participants from different stakeholder groups to be represented, physical
attendance may need to be limited. Attendance will be confirmed at a later
time (and certainly early enough for people to book reasonably priced
travel accommodations). Remote listening or participation facilities of
some sort will be available to all.

PLEASE INDICATE YOUR INTEREST NOW if you wish to attend this interim
meeting in person: http://event.pingg.com/HomeGateLondonMtg

In addition:

- You can find the HOMEGATE wiki at
http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ed Jankiewicz | 3 Mar 2010 18:36

Re: Rethink on Mobile IPv6

While I support the philosophy that IPsec and IKE(v2) are the core 
security solution for most IP layer requirements, I agree with your 
contention that it is a heavyweight solution presenting a barrier to 
entry for mobility devices.  The only thing that keeps me from agreeing 
without reservation is that any alternative method must peacefully 
coexist with RFC4877.  In other words, it should be possible for a HA 
and MN to detect/negotiate whether MIP6lite or RFC4877 is supported.  
Thus it becomes a choice for the end-user:  build a network with the 
appropriate level of security (none, MIP6lite, RFC4877) by selecting the 
products that support the required level.  Ideally a HA would support 
both to accommodate both types of MNs.

Also, to be truly useful, MIP6lite must be simple, modular and timely - 
i.e. solve the basic problem soon with "better than nothing" security, 
with the ability to be extended with more protection, perhaps even up to 
the level of RFC4877, as needed.  We don't need yet another long process 
attempting to solve all the problems before anything happens, but 
something well-defined and constrained to enable an entry-level secure MIP6

I don't know if I have much to offer in contribution, but this is 
something I would be interested in, and support as a reviewer as it 
evolves.  If done in a timely fashion, it would remove an obstacle to 
the wider adoption of MIP6 with a reduced but appropriate level of security.

Might I suggest sMIP6 (simple/secure MIP6) as a name? 

Ed J.
On 3/3/2010 10:55 AM, Basavaraj.Patil <at> nokia.com wrote:
> Mobile IPv6 (RFC3775) has been an RFC since 2004, and Dual-stack
>
(Continue reading)

Permalink | Reply | 31 comments |
headers
Laganier, Julien | 3 Mar 2010 19:22

FW: request for help in developing a tool that may be helpful to WG chairs

FYI -

-----Original Message-----
From: wgchairs-bounces <at> ietf.org [mailto:wgchairs-bounces <at> ietf.org] On Behalf Of Scott O. Bradner
Sent: Wednesday, March 03, 2010 7:36 AM
To: wgchairs <at> ietf.org
Subject: request for help in developing a tool that may be helpful to WG chairs

IETF working group chairs;

We are developing an open-source tool for monitoring the status and
progress of conflicts in on-line working groups (WG).  The tool works by
analyzing the WG mailing list.  When developed, this tool should be
helpful to WG chairs trying to understand the status of WG discussions
(how close to consensus is the WG, what is the distribution of
participation, etc).

As part of the development process we have been using a prototype tool
to analyze IETF WG mailing list archives to determine the amount of
conflict and how effective this conflict is being (has been) resolved.
As the first step, we need to understand the relationship between the
conflicts in a working group and the structure of the communication
network in that group. While having conflicts is not necessarily a bad
thing for a working group effort, some conflicts can escalate into
disasters. We are interested in finding the communication patterns
related to the evolution of group conflicts. Results from this study
will provide the base for the development of the tool that helps working
group chairs to decide when to intervene with an internal conflict
before it becomes irreversibly negative as well as being a tool that may
help determine where there is consensus on a particular topic.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hannes Tschofenig | 3 Mar 2010 20:57
Picon

Re: [MEXT] Rethink on Mobile IPv6


I agree that a discovery procedure is useful BUT
>
>
> I agree 100%!  Without something that can actually interoperate "out 
> of the box" with another vendor's systems, it becomes almost 
> impossible _to deploy in a large heterogeneous systems space where you 
> have no control of the link's other end.
> _
>

This is not necessarily true. There no absolute need to have 
interoperability between the MN and the HA unless you want a Mobile IP 
client to work with a random HA. There are examples today where this is 
also desired but not necessary to get a huge amount of deployment, such 
as IM clients and VPNs. If you look around what different SDOs have done 
with mobile IP then you will notice that everyone came up with different 
key derivation mechanisms (some call it "bootstrapping"). This pure fact 
makes Mobile IP clients non interoperable beyond SDOs.

If you make it sufficiently easy to install the client software then an 
operator can very easily ship a client to you.

Just some random thoughts....

Ciao
Hannes
Permalink | Reply | 0 comments |
headers
Wassim Haddad | 3 Mar 2010 21:30
Picon
Favicon

Re: Rethink on Mobile IPv6

Hi Raj, 

Mobile IPv6 (RFC3775) has been an RFC since 2004, and Dual-stack Mobile IPv6
(RFC5555) since 2009. Implementations of the protocol has been lacklustre to
say the least. Several SDOs have considered MIP6 and DSMIP6 as a solution
for interworking and mobility between different access technologies and only
3GPP has adopted it in a very limited manner for Rel 8 (for use on the S2c
interface) with the likelihood of it being actually deployed quite low
(IMO).

While there are many reasons that can be attributed to the lack of
implementations and use, one that I would like to raise is the the concern
with the overly complex security model that MIP6/DSMIP6 relies on today.
MIP6/DSMIP6 requires IPsec and IKE/IKEv2 (RFC3776/4877) to secure the
signaling between the MN and HA. The fundamental purpose of
MIP6/DSMIP6 is to provide mobility to hosts. At a very high level the
MIP6/DSMIP6 protocol boils down to the ability to setup a tunnel between the
MN and HA and update the MN tunnel end-point whenever there is a change in
the associated IP address (CoA). The signaling to establish the tunnel needs
to be secure. But using a protocol like
IKEv2 and IPsec to achieve this security is just an overkill. It increases
the complexity of the implementation as a result of many factors that have
been captured in I-D:
draft-patil-mext-mip6issueswithipsec and discussed in the MEXT WG meetings. 

Given the objective of the protocol is to enable IP mobility for hosts, it
should focus on doing that well in a manner that makes it easy to
implement/adopt/deploy/scale. My opinion as a result of implementation
experience is that MIP6/DSMIP6 can be significantly simplified, especially
the security architecture. The protocol as specified currently in
(Continue reading)

Permalink | Reply | 10 comments |
headers
Alper Yegin | 4 Mar 2010 11:45

RFC 4285 (was RE: [MEXT] Rethink on Mobile IPv6)


> We've already seen what happens when we produce half cooked
> security proposals tailored to a specific SDO's needs (read: RFC 4285).

What are the issues with RFC 4285? Is it written somewhere, or can someone
summarize please?

I agree with IKE/IPsec being an overkill for MIPv6.
RFC 4285 addresses that.
WiMAX architecture already uses it.

The missing piece in IETF world for RFC 4285 is the bootstrapping of keys.
WiMAX architecture handles this its own way. We could be talking about a
generic solution to that in IETF.

Alper
Permalink | Reply | 0 comments |
headers
Wassim Haddad | 4 Mar 2010 18:48
Picon
Favicon

Re: [MEXT] Rethink on Mobile IPv6

Hi Behcet, 

I agree that basic MIP6 should not have RO feature, just like PMIPv6.
I think in basic MIP6 we should define an IP entity close to MN, like AR.
Again like PMIPv6.

=> What would be the real difference with PMIPv6 in this case?

Regards,

Wassim H.

----- Original Message ----
> From: "Basavaraj.Patil <at> nokia.com" <Basavaraj.Patil <at> nokia.com>
> To: wassim.haddad <at> ericsson.com; mext <at> ietf.org
> Cc: int-area <at> ietf.org; rdroms <at> cisco.com
> Sent: Wed, March 3, 2010 6:24:23 PM
> Subject: Re: [Int-area] [MEXT] Rethink on Mobile IPv6
> 
> 
Wassim,

On 3/3/10 2:30 PM, "ext Wassim Haddad" <>
ymailto="mailto:wassim.haddad <at> ericsson.com" 
> href="mailto:wassim.haddad <at> ericsson.com">wassim.haddad <at> ericsson.com>
> wrote:

> => Does this mean that you want also to take out the 
> RO mode or you want to
> simplify it?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane