Subject: RE: [mobile-ip] LMM requirements: security issue

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 4 Sep 2002 14:07:08 +0200

=> Same here ! 

  > 
  > Just wanted to mention that Nested MIP also supports these 
  > apparently
  > conflicting requirements because once again it is the MN 
  > that registers the
  > Regional address (RoA) into the global HA.
  > 
  > There is also the option for the MN to register via the 
  > Regional Mobility
  > Agent (RMA) which I guess has some similarities to your 
  > extended mode Hesham
  > in its security implications..

=> This sounds different. The security issue with Extended
mode was that it is something like an FA, sharing a single
address between multiple nodes. This does not work in the 
"new MIPv6" with RR. The change is possible by making it 
have one address per MN.  

  > 
  > I for one though would suggest that the LMM requirements 
  > are somewhat harsh
  > in that a MN SHOULD be able to use end to end security and 
  > employ a direct
  > MIP BU, but MAY alternatively go via a trusted intermediate 
  > element, and use
  > a chain of trust that maybe in place between these elements 
  > either as a
  > supplement or a replacement to the e-e security approach.

=> For several reasons (one of them is absolute simplicity)
I would keep the LMM requirements as it is for security. 
We don't _need_ to not make it e2e and it certainly won't
make things more secure, so I don't see why it shouldn't
remanin e2e. 

Hesham

---

From: "Alan O'Neill" <[email-masked]>
Date: Wed, 4 Sep 2002 21:45:54 -0400

-----Original Message-----
From: Hesham Soliman (EAB) [mailto:[email-masked]]
Sent: 04 September 2002 21:37
To: 'Alan O'Neill'; Hesham Soliman (EAB); [email-masked]';
[email-masked]
Subject: RE: [mobile-ip] LMM requirements: security issue

  > A bit late I know due to a bout of flu..

=> Same here ! 

AWO> We must be working to hard :-)

AWO> Ah yes..I see that.

AWO> Nested doesn't need this slackening off so I am also happy to leave as
is, I just felt that we maybe were being overly cautious here when I am sure
their are deployment situations in which a chain of trust is preferred.
Happy to drop though..

Alan

---

From: "Alan O'Neill" <[email-masked]>
Date: Wed, 4 Sep 2002 22:06:24 -0400

Couple of interesting points here Theo,

1) On the ingress filtering point with the RCoA/RoA as a source address, you
have to reverse tunnel back to the LMM (MAP/RMA) because I believe that
there is somewhere in the IPv6 architecture an assumption that the source
address MUST always be toplogically correct.

I personally feel this is overly harsh and topologically incorrect addresses
should be allowed both to give us efficient multicast forwarding on foreign
networks, and to avoid this mandatory reverse-tunnelling via regional
elements. I have a draft on how this can be done that is about to appear. 

2) The Nested tunnelling and multiple addresses in HMIP and Nested MIP
represent a result of looking at a range of requirements and determining
that these overheads represent the best overall solution. Alternative
approachs to LMM end require much nastier or costly side-effects I can
assure you, and doing nothing is not an option commercially. Additional
tunnelling through the core network is not a big issue to operators and
compression can be used over the expensive access links. The LCoA allocation
is a non-issue, and the fact that a MN has one or more HoAs at third party
providers is a business issue. The RCoA/RoA is providing local internet
access in the visited domain as well as facilitating forwarding of remote
access traffic from the third party HAs whilst enabling the third party HAs
to be isolated from the rapid mobility dynamics in the visited domain. This
is the only address that is mandated which represents a real cost to the
operator..the HoAs are optional (0 to M in Nested) and related to the
commercial service needs of the user.

-----Original Message-----
From: Theo Pagtzis [mailto:[email-masked]]
Sent: 04 September 2002 23:00
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mobile-ip] LMM requirements: security issue

Hi Greg,

 some comments in line..

The LMM agent (MAP) then treats the
> address specially, but doesn't interfere with packets sent and received
> from this address.

ok..but the defence of the RCoA from the "remote" HA function in the LMM
agent would create a nested tunnel..right? If RO capability is not
active at the real HA that implies a permanent nested (double) tunnel.
Isn't that fattening up the header overheads..?

> 
> All packets bound for this address are proxy neighbour discovered,
> and sent on, just in the same way that a home agent in MIPv6 does.
> No packets are received and processed by the LMM agent as its own.
> It's a router with host-specific dynamic tunnels to the MN's LCoA.
> 
> The idea is that the address is not the MAP's, it's the MN's, but
> managed by the MAP.
> 

> Reverse tunnelling can be provided as an advertised service by the MAP.
> If there is such a binding/SA pair with the MN, it can send packets
> with the RCoA as source address, in order to get around ingress
> filtering.
> 
> This just means that the packets are sent
> [Src:LCoA,Dest:MAP,Payload[Src:RCoA,Dest:CN,Payload:Y]]
> 
> and decapsulated by the MAP (which explicitly allows this
> type of tunnel).
> 
> the MAP, which has done a proxy DAD for the RCoA on its link
> knows that it may send the de-encapsulated packet out onto the
> link.
> 
> the packet looks like:
> 
> [Src:RCoA,Dest:CN,Payload:Y]
> 
> This is equivalent of MIPv6 reverse tunnelled services provided by
> HA's, if no route optimization is used.

I thought we agreed at some point that packets sent out by the MN are
_NOT_ routed through the LMM agent, I thought we said that a requirement
is that dynamic routing would prevail...at the very least for the return
path between the MN-CN.

i.e. there is no need for a reverse tunnel between the MN and the LMM
agent.

Has that changed???

> 
> on access networks where MN's may use the RCoA as a packet source
> address, location privacy is accomplished trivially by the MN.

That assumes that ingress filtering is not happening on these access
networks. How is the MN going to know that there is not ingress
filtering so as not use the RCoA as the source address? Even more how
would it know that there is not ingress filtering so as not to require
the reverse tunnel??

> 
> As you see, in neither the CN->MN nor the MN->CN direction does
> the LMM agent treat the packets as it's own. It is a dynamic tunnel
> server, which uses bindings to determine
> 
> > I fear that privacy of the MN and interference of the LMM in the
> > security binding of the MN are a bit conflicting since LMM is all about
> > interference (i.e. the link between MN/CN is attributed privacy through
> > indirect interference of the LMM agent)
> >
> >
> > Isn't that the case?
> 
> I'd say that the security and privacy provided by tunneling
> has actually been removed through the route optimization
> interactions in MIPv6.  The ability of the MN to select an
> LMM agent which can provide these services (based on the
> removal of the RO requirements in the access network) are
> a re-instatement of those capabilities.

well if a full blown "visited" Home Agent resumes the role of the LMM
agent, then the remote Home Agent MUST not offer route optimisation if
availability of LMM capability is to be effected. In such case, only the
"root" Home Agent (i.e. the one on the home net) may offer RO
capabilities. 

> 
> In those situations where the CN doesn't need RO capabilities
> in MIPv6, the same services can be provided with a HA.
> In every case, the HA does not interfere with any communications
> between the MN and CN, except to provide dynamic tunnels for a home
> address (which is the real address of the node).
> 
>  From my point of view, in HMIPv6, the RCoA is the real address
> of the MN.  The LCoA is just an address it found on the visited
> network.

The _real_ address of the MN, is and will always be the on-link care of
address. Now you suggest you may want to abstract that address with a
RCoA obtained from the prefix of the LMM agent sitting on the edge of
the defined net domain. This RCoA is further abstracted by the home
address of the MN..

So for every on-link CoA an RCoA must exist plus the tunnel from the
defence of the RCoA (local to the LMM agent) towards that on-link CoA.
That means that for a million subscribers you are going to need three
million addresses for the LMM function...(home,RCoA, LCoA) ...is that
acceptable?

> Greg

-- 

thanks

theo

---

From: "Alan O'Neill" <[email-masked]>
Date: Wed, 4 Sep 2002 22:13:45 -0400

Hesham,

I would state it this way. 

For a million customers you need a million RCoA/RoA addresses so they get
local access service in the visited domain. The existance of third party HAs
and associated HoAs with which the MN is roaming, and with which the MNnis
undertaking remote access is a separate issue. A MN could have 0 to M such
active HoAs requiring additional addresses justified by the associated
roaming revenues.

Nested is specifically designed to enable this clean separation and to
support the aggregation of multiple HoAs during hand-off..Maybe HMIP makes
different assumptions here ?

Alan.

-----Original Message-----
From: Hesham Soliman (EAB) [mailto:[email-masked]]
Sent: 04 September 2002 23:24
To: [email-masked]'; [email-masked]
Cc: [email-masked]
Subject: RE: [mobile-ip] LMM requirements: security issue

  > million addresses for the LMM function...(home,RCoA, LCoA) 

=> The first and third addresses above are not a requirement
of the LMM function although they are used by it and by the
MIPv6 base spec. Only RCoA is required by LMM
as an addition to the existing MIPv6. So for a million
subscribers, LMM requires additional million addresses. 

Hesham

---

From: "Alan O'Neill" <[email-masked]>
Date: Thu, 5 Sep 2002 00:31:09 -0400

Greg,

May well be, but without doing the comparative work I think HMIPv6 might not
provide clean support for multiple HoAs per MN, or local access independent
of the presence of a global HA. There are many subtleties in there wrt AAA
service control and scalability.

But as I said I need to do the work and don't weant to upset Hesham et al
with the kind of wild, uninformed,  off the cuff statements that I just made
;-)

Alan

-----Original Message-----
From: Greg Daley [mailto:[email-masked]]
Sent: 05 September 2002 12:17
To: Alan O'Neill
Cc: [email-masked]
Subject: Re: [mobile-ip] LMM requirements: security issue

Hi Alan,

 > As an aside, given the many similarities between
 > HMIP and NestedMIPv6 architecture it might be
 > worth combining these. I'll try to document the
 > differences in requirements, architecture and
 > features between the two to see if this is
 > practical, and then have some discussions with
 > Hesham on this if he is supportive..

Hesham's definitely the person to talk to on that
one..

In my guess the advantages wouldn't be in MIPv6,
but in NEMOs.  Would it be better to talk about
it over there?

Greg

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 5 Sep 2002 19:37:51 +0200

I think the trust relationship between a MAP and a host must be the same
as
between any router in the foreign domain and the host.

It is not a replacement for the e2e trust relationship with the home
agent, nor
would I characterize it as a chain of trust, since it does not extend
back to
the home agent in any way. Or did you have something else in mind?

There is, of course, an issue about how the host verifies the trust
relationship
with the routers in the foreign domain in the first place. This is
currently an
open issue that the SEND BOF addressed. But assuming a mechanism for
that, the
trust relationship with the MAP can derive in some way from the trust
relationship with the routers, perhaps using the same mechanism but
requiring
additional steps (obtaining a certificate or key for the MAP through the
trusted
access router, etc.).

=> Exactly.

I'm sure this will need to be spelled out, in some amount of detail, in
the spec
before it will get IESG approval, but the important point now is that we
can
achieve agreement on what the general framework is for security between
the MAP
and the host, so we can fill in the details.

=> Agreed.

Hesham
            jak

----- Original Message -----
From: "Alan O'Neill" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; "Hesham Soliman (EAB)"
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, September 04, 2002 6:39 PM
Subject: RE: [mobile-ip] LMM requirements: security issue

> So the chain of trust as a supplement to e2e is fine in your book but
not as
> a replacement yes ?
> From: James Kempf [mailto:[email-masked]]
> Sent: 04 September 2002 02:16
> To: Alan O'Neill; Hesham Soliman (EAB); [email-masked];
> I think we want to maintain end-to-end security for MIPv6. It is
necessary
> for
> the IPsec SA used to secure binding update traffic, for example.
>
> The issue is the extra tunnel overhead, especially on the wireless
link,
> though
> also on any T1 links from the aggregation router to the access router.
> Header
> compression can help, but there are issues on handoff.
>
>             jak
>
> ----- Original Message -----
> From: "Alan O'Neill" <[email-masked]>
> To: "Hesham Soliman (EAB)" <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Sent: Monday, September 02, 2002 1:56 AM
apparently
> > conflicting requirements because once again it is the MN that
registers
> the
> > There is also the option for the MN to register via the Regional
Mobility
> > Agent (RMA) which I guess has some similarities to your extended
mode
> > I for one though would suggest that the LMM requirements are
somewhat
> harsh
> > in that a MN SHOULD be able to use end to end security and employ a
direct
> > MIP BU, but MAY alternatively go via a trusted intermediate element,
and
> use
> > a chain of trust that maybe in place between these elements either
as a
> > Any push-back on that ?
> > Sent: 26 August 2002 22:49
> > To: [email-masked]'; [email-masked]
> > Theo,
> >   > In addition to what I have mentioned previously I would
> >   > like to add that
> >   > I believe that two more requirements are conflicting about
security:
> >   >
> >   > In A:
> >   >    it is required that the LMM agent does not interfere with the
> >   > security bindings between the MN and the peers
> >   >
> >   > whereas on B:
> >   >
> >   >  it is required that the MN preserves location privacy under
LMM.
> >   >
> >   > I cannot see how one can maintain location privacy (B) of
> >   > the MN without
> >   > breaking the end-to-end principle (A) in terms of security
> >   > bindings.
> >
> > => These are requirements and are not meant to show how
> > it can be done. Of course we don't want to place impossible
> > requirements, but as Greg explained, this is already doable
> > to a large extent with the existing HMIPv6, so I don't think
> > it's impossible.
> >
> > Hesham
> >
>

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 5 Sep 2002 20:13:15 +0200

Alan,

No need to worry about upsetting me, that's not 
an easy task :). I'll try to save you some work. 

May well be, but without doing the comparative work I think HMIPv6 might
not
provide clean support for multiple HoAs per MN, 

=> That's not a problem in HMIPv6. Let me give you 
an example with Basic mode:
Assume a MN that has HoA_1 - HoA_9
If the MN wants them all directed to the same CoA/RCoA
it sends a single BU (S bit not set) to its HA with a single RCoA. 
If the home addresses belong to different HAs then separate
BUs need to be sent to the respective HAs, but the CoA/RCoA
is still the same. If the MN needs to direct traffic to 
different CoAs then this has to be handled per home address.
The whole process is independent of HMIPv6 because the 
MAP is completely unaware (in the basic mode case) of 
any home addresses.

Also, for more on this, see:

http://www.ietf.org/internet-drafts/draft-soliman-mobileip-flow-move-02.txt

or local access
independent
of the presence of a global HA. 

=> Dunno what you mean here.

There are many subtleties in there wrt
AAA
service control and scalability.

=> Same as above.

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 5 Sep 2002 20:16:16 +0200

> 1. My initial suggestion (the dirty way) in which
> the MAP scans through headers to see if an IPsec
> header exists.
>
> 2. Require the HA to add a RH to all packets going
> through an IPsec tunnel to the MN.
>
> 1) has the advantage of working without adding
> more requirements on the HA. 2) has the advantage of
> less scanning into the daisy chain for each packet.
>

Well, I don't like either option. Option 1) requires the MAP to snoop
the
packets, which is a very slow and time consuming operation. 

=> Sure.

Option 2)
requires
communication between the HA and the MAP.

=> No communication is needed, this is a requirement
on the HA to add a RH whenever sending packets to a 
MN through an IPsec tunnel. 

But, given the choice, I would go for 1). I think it may be a
scalability
problem to design in any dependencies between an HA in a foreign domain
and the
MAP. Besides, routers will need to scan headers anyway, so there may be
some
hardware to accelerate header snooping that could be applied to a MAP.

=> I'm happy with either one and I also don't like 
having to worry about backward compatibility
with "old" (a few months older!) HAs. 

Hesham

---

From: "Alan O'Neill" <[email-masked]>
Date: Thu, 5 Sep 2002 21:43:21 -0400

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: 06 September 2002 00:41
To: Alan O'Neill; Hesham Soliman (EAB); [email-masked];

I think the trust relationship between a MAP and a host must be the same as
between any router in the foreign domain and the host.

It is not a replacement for the e2e trust relationship with the home agent,
nor
would I characterize it as a chain of trust, since it does not extend back
to
the home agent in any way. Or did you have something else in mind?

AWO> I did have something different in mind but I think it best to leave
that discussion for another time as a draft is due out on the detailed
security aspects of Nested which will address this ok. Agree with your
comments in general.

There is, of course, an issue about how the host verifies the trust
relationship
with the routers in the foreign domain in the first place. This is currently
an
open issue that the SEND BOF addressed. But assuming a mechanism for that,
the
trust relationship with the MAP can derive in some way from the trust
relationship with the routers, perhaps using the same mechanism but
requiring
additional steps (obtaining a certificate or key for the MAP through the
trusted
access router, etc.).

I'm sure this will need to be spelled out, in some amount of detail, in the
spec
before it will get IESG approval, but the important point now is that we can
achieve agreement on what the general framework is for security between the
MAP
and the host, so we can fill in the details.

AWO> Absolutely..

            jak

----- Original Message -----
From: "Alan O'Neill" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; "Hesham Soliman (EAB)"

> So the chain of trust as a supplement to e2e is fine in your book but not
as
> I think we want to maintain end-to-end security for MIPv6. It is necessary
> for
> The issue is the extra tunnel overhead, especially on the wireless link,
> though
> > Just wanted to mention that Nested MIP also supports these apparently
> > conflicting requirements because once again it is the MN that registers
> the
Mobility
> > Agent (RMA) which I guess has some similarities to your extended mode
> Hesham
> > I for one though would suggest that the LMM requirements are somewhat
> harsh
direct
> > MIP BU, but MAY alternatively go via a trusted intermediate element, and
> use
> > a chain of trust that maybe in place between these elements either as a
> >   > I believe that two more requirements are conflicting about security:
> >   >
> >   > In A:
> >   >  it is required that the MN preserves location privacy under LMM.
> >   >

---

From: "Alan O'Neill" <[email-masked]>
Date: Thu, 5 Sep 2002 21:55:11 -0400

-----Original Message-----
From: Hesham Soliman (EAB) [mailto:[email-masked]]
Sent: 06 September 2002 03:43
To: 'Alan O'Neill '; [email-masked]' '
Cc: [email-masked] '
Subject: RE: [mobile-ip] LMM requirements: security issue

Alan,

AWO> Thanks. So this is also the same as Nested MIP then which is great.

or local access
independent

AWO> Let me do the analysis in detail ok and then I can be specific about
where the differences lie in my own mind rather than throwing out random
thoughts..

=> Same as above.

AWO> Same as above ;-)

Alan.