[Fwd: I-D ACTION:draft-haddad-mipv6-bub-01.txt]

Hi,

We have submitted a new updated version of the Binding Update 
Backhauling Proposal. It is available on:  

http://www.ietf.org/internet-drafts/draft-haddad-mipv6-bub-01.txt

Abstract:
Mobile IPv6 [1] defines two different modes to handle the 
mobility problem (i.e., mobile node moving accross different 
networks and changing its IP address). The two modes had been 
mainly designed for scenarios involving one mobile node and 
one static node (correspondent node). This document answers 
issues related to scenarios involving two mobile nodes (i.e., 
the correspodent node is also a mobile node). The document 
addresses also the double jumping problem where two mobile nodes 
move at the same time (i.e., switch to new subnets).
The document proposes a new mode called 'BUB' (Binding Update 
Backhauling) allowing a more secure, reliable and optimized 
exchange of Binding Updates (BUs) between two mobile endpoints.

 
Your comments are highly welcomed.

Regards,

Wassim H.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review,
use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error,

[Fwd: I-D submission]

-------- Original Message --------
Subject: I-D submission
Date: Mon, 16 Feb 2004 22:07:49 +0900
From: Glenn Mansfield Keeni <glenn <at> cysols.com>
Organization: Cyber Solutions Inc.
To: internet-drafts <at> ietf.org <internet-drafts <at> ietf.org>
CC: Sri Gundavelli <sgundave <at> cisco.com>, Ken Nagami <nagami <at> wide.ad.jp>,  KOIDE Kazuhide 
<koide <at> ediok.org>, Glenn <glenn <at> cysol.co.jp>
References: <4.3.2.7.2.20040129111245.037b2830 <at> mira-sjcm-3.cisco.com>
<401A53A4.80505 <at> cysols.com> 
<Pine.GSO.4.58.0401300906290.8330 <at> irp-view7.cisco.com> <401AEB1D.7050002 <at> cysols.com> 
<6.0.0.20.2.20040202110039.04899dc0 <at> gw.inetcore.com> 
<Pine.GSO.4.58.0402011932410.11604 <at> irp-view7.cisco.com> <402F117B.4060207 <at> cysols.com> 
<40302F5C.838F254D <at> cisco.com>

Hi,
     Attached please find the Internet-draft

         draft-ietf-mip6-mipv6-mib-01.txt

This is a work of the ietf-mip6-wg. I will appreciate it
very much if you can kindly post the draft to the archives.

      Thanks and Cheers

            Glenn

Problem Statement: Home Agent Reliability (new version)

Re: rr weaknesses?

Soliman Hesham wrote:

 > Having said all that, deep down ;), I don't take MiTM
 > attacks too seriously unless MiTM is on the same link
 > as the CN. So I think in theory RR is certainly weak,
 > but in practice it's vulnerability is probably limited
 > to attacks by neighbours on the CN's link.

This is roughly my feeling as well. And attacks by neighbors
on the link are already pretty bad (even with SEND).

 >  > True, but it would be useful to compare this to other attacks
 >  > that the same mitm can do. For instance, ARP spoofing, sending
 >  > TCP RSTs, messing with TCP ACKs, dropping packets.
 >
 > => Sure, I do think it is more vulnerable than the two
 > cases you mention above because: a) it is not limited
 > to the local link (the attacker need not be a neighbour)

All the attacks that I listed are possible for the whole
path, i.e. not just on the local link.

 > and b) the attacker can move and cause damage for some
 > time (albeit less 10 min). Also the attack is not

All of the attacks I mentioned also cause a disruption
that lasts longer than a single packet. Exactly how long...
depends on the specific attack.

 > limited to certain types of upper layers like TCP-based

Some attacks on plain IPv4/IPv6 are related to applications,
but not all. ARP/ND, ICMP, just dropping packets, looking
inside the packets, etc.

Then we have a couple of interesting cases regarding the
use of e2e security. When that is in place, be it RR/CGA/HIP,
attackers can at most cause denial of service, not more.
With IPsec e2e, presumably the RR signaling would be protected
as well => no attack. With TLS e2e, RR would still be vulnerable,
but as mentioned above the effect would be at most denial-of-service.
TLS, however, is denial-of-service vulnerable in any case.

 > attacks. So that's why it's more significant I think.
 > Also we have a cure for the equivalent of ARP spoofing
 > now in IPv6 (SEND).

In conclusion, I'd still like you or someone to write that
paper that describes the issues and compares them to the
issues with existing issues that mitms on the path can
cause. I mean its easy for us to make short comments on
the mailing list, but I think this matter is so important
that it needs to be described well. And be reviewed!

Don't get me wrong. I want to create new route optimization
security mechanisms that are better than RR. But I just think
there is a big difference in "nice to have" vs. "must have
because of serious problems". Clearly we have seen and will
see folks who claim the latter to market their method; it
would be extremely useful to understand where we are in
reality, however.

--Jari

Re: rr weaknesses?

 In your previous mail you wrote:

   This is roughly my feeling as well. And attacks by neighbors
   on the link are already pretty bad (even with SEND).

=> I agree, for instance a reflection attack works very well
(no defense at all).

   Then we have a couple of interesting cases regarding the
   use of e2e security. When that is in place, be it RR/CGA/HIP,
   attackers can at most cause denial of service, not more.
   With IPsec e2e, presumably the RR signaling would be protected

=> I believe you'd like to mean RO signaling.

   as well => no attack. With TLS e2e, RR would still be vulnerable,
   but as mentioned above the effect would be at most denial-of-service.
   TLS, however, is denial-of-service vulnerable in any case.

=> I agree, and as the RO signaling is at the network layer IPsec
is the solution of choice.

   Don't get me wrong. I want to create new route optimization
   security mechanisms that are better than RR.

=> IMHO we need stronger assumptions to do that. For instance (again)
if strong authentication is available for MN and CN, IPsec is a
solution.

   But I just think
   there is a big difference in "nice to have" vs. "must have
   because of serious problems". Clearly we have seen and will
   see folks who claim the latter to market their method; it
   would be extremely useful to understand where we are in
   reality, however.

=> I have a concern here: some documents or implementations can
make "better" RO security mechanisms impossible to use. We have
to be very careful as perhaps there are some such mechanisms not
yet discovered/invented.

Regards

Francis.Dupont <at> enst-bretagne.fr

PS: we should publish all the previous documents about the subject
as information RFCs ASAP (i.e., put them in the RFC editor queue
waiting for draft-24).

RE: rr weaknesses?

 > Then we have a couple of interesting cases regarding the
 > use of e2e security. When that is in place, be it RR/CGA/HIP,
 > attackers can at most cause denial of service, not more.

 > With IPsec e2e, presumably the RR signaling would be protected
 > as well => no attack. 

=> Not sure about this statement, when you say e2e you mean
MN - CN, right? In this case the RR signalling _may_ be protected
if all traffic is protected. But if the protection does not 
cover all traffic then of course the CN - HA path will still
be vulnerable even if the connections between the MN and CN 
are covered with IPsec. Of course RR + CGA is not vulnerable
to that.

   With TLS e2e, RR would still be vulnerable,

=> Yes. 

 > but as mentioned above the effect would be at most denial-of-service.
 > TLS, however, is denial-of-service vulnerable in any case.

=> Yes it's a DoS attack on IPsec/TLS protected traffic. 
But it's still another (new) DoS attack.

 > In conclusion, I'd still like you or someone to write that
 > paper that describes the issues and compares them to the
 > issues with existing issues that mitms on the path can
 > cause. I mean its easy for us to make short comments on
 > the mailing list, but I think this matter is so important
 > that it needs to be described well. And be reviewed!

=> I remember the DT wrote a long analysis on residual
threat of RR. That might be a good start. I still have 
the text file you got rid of it ;)

 > Don't get me wrong. I want to create new route optimization
 > security mechanisms that are better than RR. But I just think
 > there is a big difference in "nice to have" vs. "must have
 > because of serious problems". Clearly we have seen and will
 > see folks who claim the latter to market their method; it
 > would be extremely useful to understand where we are in
 > reality, however.

=> I don't have a strong opinion on needing a new 
mechanism. I just think that it's cautious to have 
a more secure option in case we missed something 
or some attacks became worse than we expected. If that
happens in future we might not have the time to standardise
one immediately (IETF is not getting any faster!). 
But I know this is a very paranoid argument that might 
not find much support.

Hesham

RE: rr weaknesses?

>  > Don't get me wrong. I want to create new route optimization
>  > security mechanisms that are better than RR. But I just think
>  > there is a big difference in "nice to have" vs. "must have
>  > because of serious problems". Clearly we have seen and will
>  > see folks who claim the latter to market their method; it
>  > would be extremely useful to understand where we are in
>  > reality, however.
> 
> => I don't have a strong opinion on needing a new 
> mechanism. I just think that it's cautious to have 
> a more secure option in case we missed something 
> or some attacks became worse than we expected. If that
> happens in future we might not have the time to standardise
> one immediately (IETF is not getting any faster!). 
> But I know this is a very paranoid argument that might 
> not find much support.

I think this thread is based on paranoia. I think the MIPv6
design team ignored the threats and security issues with RR
when this was work was done over a year ago. We seem to be
revisiting the same issues. The security issues that are being
discussed now are not new. These have been considered.

More secure means of accomplishing RO should be considered in
the WG for MIP6. But I would argue against dismissing RR as
being insufficient at this time. 

> 
> Hesham
> 

-Raj
> 

Re: Re: review of draft-dupont-mipv6-3bombing-00.txt

 In your previous mail you wrote:

   > => I have another simple suggestion: close the congestion window,
   > i.e., behave on hand-off of the peer as a packet was lost...

   This does not work for UDP streams.

=> it should work with congestion controlled streams.

   Thinking of TCP, I suppose some packets will always be lost during a
   handover---as long as we do not use something like an anticipated
   handover starting from the old care-of address with all its security
   implications. So TCP will go through slow start anyway. And beeing able
   to force TCP into slow start means that we intermix layers. Is this a
   good idea? (*)

=> if some packets will always be lost the answer is yes, if this
assumption is false no, but in any case as the path has changed
something should be done, i.e., upper layers should get the "hand-off"
event. BTW in experiments I saw very different behaviors between
TCP connections with different profiles (for instance telnet (interactive)
and FTP (bulk transfer)) so IMHO it's worth our attention.

Regards

Francis.Dupont <at> enst-bretagne.fr

Re: Re: review of draft-dupont-mipv6-3bombing-00.txt

 In your previous mail you wrote:

   I would also hope to avoid any TCP-specific solution.

=> but IMHO you believe in the usefulness of congestion control (.

   Regarding slow-start:

=> this was more a slow-restart.

   Mark Doll wrote:

   > Thinking of TCP, I suppose some packets will always be lost
   > during a handover

   This is not true.  With a simple context transfer approach
   that includes redelivery of (approx. 2) redundantly buffered
   packets, we can get terrific performance for voice.  With a
   few more buffered packets, probably video.

=> in this case you don't send a RR/RO signaling to the CN,
i.e., I agree but your argument doesn't apply.

   There has been a lot of discussion about cross-layer design
   recently.  I think it should be reframed as enabling one
   layer to acquire relevant information that _may_ be more
   efficiently provided by another layer.  I think it's a much
   better way for sane and simple designs to result.

=> this has been more about layer 2 / layer 3. In the case
we are talking about something should be done, perhaps not
what I proposed in addition to limit the sending buffer...

Regards

Francis.Dupont <at> enst-bretagne.fr

Re: bootstrap problem definition

I have many comments about your bootstrap I-D:
 - first the problems in the abstract and in the introduction
   are not the same: in the abstract the home environment is dynamic
   and the mobile node does not know it enough. In the introduction
   the only problem of the mobile node is that it has lost the context,
   in particular the IPsec one (no security association of any type).
   Of course the problem you described, what I call "dynamic bootstrap",
   is even harder.
 - (1. intro) with IKEv1 the MN does not need to have a statically
   defined home address and the reason you gave is wrong: the home
   address is unknown during the phase 1. I agree that a static home
   address is easier because it makes authorization rules static, but
   this is not a requirement, just the case you have a chance to get
   implemented (.
 - dynamic home agent address discovery is a security nightmare: I agree
   we should not rely on it.
 - (2. MIPv6 conf) all MN-HA mobility signaling (not communications) are
   required to be protected by IPsec.
 - (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.
 - Home prefix change is not a valid issue because the home agent can
   infer the new home address from the old one.
 - Same for duplicate address collision because the authorization stuff
   can, when it occurs, accept any address which is not in use or
   authorized for another client.
 - I don't understand the "addressing privacy" issue: the home address
   can be a RFC 3041 one. This even makes dynamic authorization easy
   (first come first served)...
 - (3.1.2 Dyn HA <at>  assignment) this is only about manual keying, isn't it?
   (note that IMHO the manual keying is very incompatible with dynamic
   bootstrap, I'd like to focus on the IKE case)
 - (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.
 - Interconnected PKIs are poor replacements for a real AAA infrastructure
   but they (can) work.
 - IMHO the main advantage of an AAA infrastructure is some security
   properties for the care-of address, perhaps this is the only way
   to get more than a return routability check (included in IKE which
   uses many messages in both ways .
 - NAI == USER-FQDN, the real issue is AAA and NAI are user oriented
   when IKEv1 is system oriented.
 - (3.2.2 Opp/Local discovery) The idea of using the DNS to get infos
   about the home was in a very old message of someone from Digital
   in this list (I can grep into my archive to find the reference).
 - (3.3.1 Dormant mode MN) IPv6 prefix change is a matter of weeks
   or months. IMHO the real issue is not with nodes in low power
   dormant mode, but with MNs which are used every X months (every
   IETF meetings for instance .
 - (4. scenarios) The first scenario (no pre-existing relationship)
   has a little chance to work with IKEv1 which requires strong
   mutual authentication and authorization.
 - the second one is interesting and should be shown to VPN server
   sellers. IMHO this can be a good extension to standard VPNs,
   and there is no home address assignment issue as VPN stuff in
   general includes an "internal" address management.
 - if I understand the third scenario, the idea is to use the local
   AAA system for access control to do some kind of "local mobility"?
 - I don't understand the fourth/last scenario: there is no way to
   "turn" security associations. And IMHO IPsec people will be very
   against any attempt to define this kind of things.
 - you should add a reference to AAA/MIPv6 requirement document
   (draft-le-aaa-mipv6-requirements-03.txt) which was resubmitted
   by Frank Le (our editor) as AAA gives all you'd like: care-of
   assignment, home agent assignment, home address assignment,
   security properties for all of them, including for the care-of,
   fast or very fast creation of the first IPsec SAs, etc.
   So the (to come) solution document about dynamic bootstrap should
   be only when an AAA infrastructure is not available/used (.

Regards

Francis.Dupont <at> enst-bretagne.fr