headers
Alper Yegin | 1 Mar 2004 01:43

RE: Comments on kempf-mip6-bootstrap

Hi Jim,

> >    The current IKEv1-based dynamic key exchange protocol described
in
> >    [5] has no integration with backend authentication, authorization
and
> >    accounting techniques unless the authentication credentials and
trust
> >    relationships use certificates.
> >
> > Isn't this an implementation issue? For example can't I use LDAP to
> > retrieve the keys for a MN when my HA receives an IKE request? Well,
> > there isn't a RADIUS or Diameter application for this scenario,
maybe
> > this is what you mean. But I think this doesn't require integration
of
> > IKE with RADIUS/Diameter.
> >
> 
> AAA and the HA can communicate auth/authz information via LDAP.
There's an
> issue of how the MN identifies itself to the HA independently of its
home
> address. IKEv2 helps with these problems, as you note above. There is
> still
> an issue with accounting records, however, even if IKEv2 is used.

What is the accounting issue? HA should simply collect some counters,
and any centralized accounting server should be able to query HA via
SNMP.
(Continue reading)

Permalink | Reply | 2 comments |
headers
James Kempf | 1 Mar 2004 01:53

Re: Comments on kempf-mip6-bootstrap


> What is the accounting issue? HA should simply collect some counters,
> and any centralized accounting server should be able to query HA via
> SNMP.
>

Sure. But it might be cleaner for the HA to be able to issue its own
accounting records directly into the AAA system, as opposed to using a
gateway. Fewer moving parts.

> I think this is a different discussion than what this I-D should be
> addressing. We should discuss it under another thread.
>

OK. But, isn't there a connection? The HA might want to use IKEv2 to check
auth/authz for mobility service via the AAA system.

> > I'm not sure I understand your point. Could you clarify?
>
> For example, the problems encountered in using dynamically allocated
> home addresses with IKEv1 would also be applicable to the VPN solution.
> Or, discovering and having dynamic keys with a Home agent is equivalent
> to doing those with a VPN gateway. So I think you'd encounter the
> similar problems with the VPN solution, hence bootstrapping off of a VPN
> solution is more like moving the problem around.
>

Yes, that's true. I think the idea here is that if a VPN gateway exists and
is also an HA, the mobility service could somehow "upgrade" a VPN SA to a
Mobile IP SA if the user suddenly decided it wanted to move, rather than
(Continue reading)

Permalink | Reply | 1 comment |
headers
Henrik Levkowetz | 1 Mar 2004 02:11

Re: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof


Bar-bof details:

We have a proposed time and place for this bar-bof: 

	Tuesday morning 7:00  - in the seating area outside Emerald.  

Possibly we can use Emerald if more people turn up than the area can
hold.

The first idea of having it Monday night at 10:00 has been scrapped as
some key persons who are newly arrived from the states will be dead on
their feet at that time. 

	Henrik

Wednesday 25 February 2004, Henrik Levkowetz wrote:
> 
> Proposal of a bar-bof
> ---------------------
> 
> With the coming (we hope) of heterogenous deployment of IPv4 and IPv6
> access and transport networks, and Mobile Nodes with MIPv4 and/or MIPv6
> capability and IPv4 and/or IPv6 stacks, the question has been raised
> of how to best run Mobile IP in such circumstances, and some solutions
> has been proposed.  
> 
> The "trivial cases" of MIP4 carrying IPv4 in an all-IPv4 network, and
> MIP6 carrying IPv6 in an all-IPv6 network are covered in the MIPv4 and
> MIPv6 standards.  But by one way of counting, that still leaves about 6
(Continue reading)

Permalink | Reply | 2 comments |
headers
Erik Nordmark | 1 Mar 2004 02:45
Picon

Re: comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt

> It is also related to charging for mobility service. The access network
> provider might want to charge differentially for users that move and those
> that want to stay at a fixed location.

The distinction between "mobilty" and "mobile IP" is critical here.

I don't think the access network can charge differently for
mobility without help from the home AAA support. For instance,
the access network here in the Lotte hotel can't know that
a day ago I was in California.

You can try to charge extra for mobile IP, but wouldn't that mean that
folks would use mobility at other layers e.g. client-only protocols
that don't need reachability at a fixed IP address?

Given that we want to increase deployment of mobile IP,
since it is a platform for interesting upper layer services, having
the access provider charge more for mobile IP seems counterproductive.

That doesn't prevent the home provider to charge for maintaining the fixed
IP address precence and tunneling, but you actually want those charges to
be small to drive deployment.

   Erik
Permalink | Reply | 4 comments |
headers
Jari Arkko | 1 Mar 2004 03:38
Picon
Picon

mipv6 base draft status


A brief update before the meeting. The base specification has been under
a very lengthy processing at IANA, but as of last week, they have
completed the IANA actions. (This lengthy wait for IANA is by the way
not just our problem, it has affected many other specifications at the
IETF too. Apparently there some people have left for a maternity leave
and some new ones come in etc.)

The status at the RFC Editor web site says still "IANA", but this
may be because the RFC editors have not yet processed the result
from IANA and/or they maybe here for the meeting.

I'll be monitoring the situation and will ping the relevant
parties to make sure that things move forward. Hopefully we
are very soon in AUTH48, at which time I'll make a few minor
editorial modifications that people have suggested over the
months.

--Jari
Permalink | Reply | 0 comments |
headers
Jari Arkko | 1 Mar 2004 04:44
Picon
Picon

comments on draft-haddad-mipv6-omipv6-01.txt


Hi Wassim and others,

I have reviewed this document. I think its excellent that you are
working on optimizations. I think we need them, and there appears to
be at least some level of consensus on that in the group as well. I
also like your approach in the sense that it does not expect to use
any security infrastructure, I think that is the right thing to do.
And I think that you have also managed to avoid potential CPU DoS
issues that are inherent in Diffie-Hellman- based schemes, which is
good.

But you mention that your intent is to provide a more secure signaling
scheme than RR is. However (and perhaps I'm missing something
obvious), it seems that the proposed use of Diffie-Hellman has
security impacts which actually make it less secure than standard
RR. My concerns are listed below; after that there are some suggested
modifications which can make your protocol more secure.

"Kilroy was here first" -attack

   If I have understood correctly, in OMIPv6, any change to the binding
   cache must be authenticated via the derived shared secret. It is
   even not possible to rerun RR and OMIPv6 without proving the
   possession of the shared secret.

   As a result, once a shared secret is established, it is hard for
   other parties to change the binding. This is normally a positive
   thing, however, it becomes negative if it happens that the initial
   DH exchange was compromised and is now in control of the binding.
(Continue reading)

Permalink | Reply | 2 comments |
headers
James Kempf | 1 Mar 2004 05:04

Re: comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt

> The distinction between "mobilty" and "mobile IP" is critical here.
>
> I don't think the access network can charge differently for
> mobility without help from the home AAA support. For instance,
> the access network here in the Lotte hotel can't know that
> a day ago I was in California.
>
> You can try to charge extra for mobile IP, but wouldn't that mean that
> folks would use mobility at other layers e.g. client-only protocols
> that don't need reachability at a fixed IP address?
>

I was thinking of an access network provider that wanted to charge more for
a client that changed its address "frequently" (where frequently is somewhat
ill defined) as opposed to one that kept the same address for a long
session.

Mobile IP has certain fixed per node costs in terms of signaling that are
definitely not there for a node that gets a lease on its DHCP address and
hangs on to it until the lease expires. That would be the justification for
charging more.

> Given that we want to increase deployment of mobile IP,
> since it is a platform for interesting upper layer services, having
> the access provider charge more for mobile IP seems counterproductive.
>

Like I said, people's opinions about whether or not this is desirable can
vary. :-) But I don't think the IETF should be engineering the protocol to
favor one business model over another (see draft-iab-e2e-futures-txt for a
(Continue reading)

Permalink | Reply | 3 comments |
headers
Henrik Levkowetz | 1 Mar 2004 06:18

Re: [Mip4] REVISED: MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof

I've gotten a bit of pusback about the early hour of the bar-bof, so the
time has been changed:

REVISED Bar-bof details:

	Monday evening 22:00  - in the seating area outside Emerald.  

Possibly we can use Emerald if more people turn up than the area can
hold.

	Henrik

Wednesday 25 February 2004, Henrik Levkowetz wrote:
> 
> Proposal of a bar-bof
> ---------------------
> 
> With the coming (we hope) of heterogenous deployment of IPv4 and IPv6
> access and transport networks, and Mobile Nodes with MIPv4 and/or MIPv6
> capability and IPv4 and/or IPv6 stacks, the question has been raised
> of how to best run Mobile IP in such circumstances, and some solutions
> has been proposed.  
> 
> The "trivial cases" of MIP4 carrying IPv4 in an all-IPv4 network, and
> MIP6 carrying IPv6 in an all-IPv6 network are covered in the MIPv4 and
> MIPv6 standards.  But by one way of counting, that still leaves about 6
> combinations (14 if you count NAT-PT versions) which may occur in
> practice which are not covered by the current standards.  A number of
> drafts (some mentioned below) has been written, proposing solutions
> to some of these cases.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francis Dupont | 1 Mar 2004 07:00
Picon
Picon

Re: bootstrap problem definition

 In your previous mail you wrote:

   >  - dynamic home agent address discovery is a security nightmare: I agree
   >    we should not rely on it.

   I agree that its a security problem, but its also possible that a future
   protocol would be capable of providing home agent discovery without the
   problems ;-)

=> IMHO this future protocol will at least take a long time to appear...

   >  - (3.1.1. Dyn H <at>  Assignment) dynamically assigned is not the opposite
   >    of statically configurated. And there are known extensions (widely
   >    implemented but not standardized) of IKEv1 to support dynamically
   >    assigned "internal" addresses.

   Ok. In IKEv2 this supposed to change, as there will be a standard.

=> the draft is clearly about IKEv1 only.

   Once more you have to have policy entries in place.

=> in fact this argument is not true: many IKE implementations support
dynamic policy entries which are built according the negociated
traffic selectors and authorization, or, perhaps even more common,
according the assigned "internal" address of the mobile initiator.

   >  - (3.2.1 AAA) Even I agree that IKE should be clearly integrated with
   >    an AAA system your statement that it can work only with certificates
   >    is not true.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Francis Dupont | 1 Mar 2004 08:04
Picon
Picon

Re: MIPv6 issue (IPsec/IKE interaction)

 In your previous mail you wrote:

   We saw an interesting problem occur when we tested MIPv6 with IPsec/IKE:
   when the MN does a L3 move at the start of phase 2 SA negotiation with
   the HA, IKE Quick Mode does not complete.

=> IKE is supposed to recover on timeouts even usually it takes time.

  It may be our problem, it may
   be a spec issue. In any case, it is probably a good MIPv6 interop
   scenario. Please refer to attached packet capture
   "quickModeFailsAfterMove.pcap" which has filtered out everything except
   for the IKE messages.

   We saw this issue happen during our testing, because we set the policy
   lifetime (in seconds) to 120 seconds, the phase 1 ISAKMP and phase 2
   IPsec SAs were re-keyed very frequently (every 90 seconds or so). 

=> with such aggressive timings you should use very short timeouts too!

   When we tested, we had the MN register with the HA from a foreign link
   (K-bit in BU set to 1), this setup the phase 1 ISAKMP and phase 2 IPsec
   SAs between the MN and HA. Then we had the MN move home. The SAs are
   maintained while the MN is home. Then we had KameCN start a FTP MGET of
   a large file from the MN (MN is FTP server). During this FTP, we had the
   MN move to foreign link. Refer to packet #7 in
   "quickModeFailsAfterMove.pcap", what is happening is that the MN is
   rekeying its phase 2 IPsec SAs (Quick Mode exachange), but it starts
   this *AFTER* it has moved to the foreign link so it is sending these
   from its care-of address 3ffe:ffff::20b:dbff:ffe94:83fc. The HA doesn't
(Continue reading)

Permalink | Reply | 1 comment |

Gmane