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

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

My comments were specifically about MIP signalling (for service invocation)
rather than routing security..

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

Alan,

I don't see the need for establishing security between the HA and the RMA
specifically for routing. Internet routing is logically divided into two
domains, interior and exterior. Any security for exterior routing is
established
between the border routers. The security within the domain and, by
extention,
between the border routers and the routers within the domain, is up to the
administrative entity controlling that domain. I don't think it would be
wise to
require that security to have to be extended by reaching out into the center
of
another administrative domain, so to speak, where the HA is located. The
logistical difficultities, whether AAA or PKI is used, of arranging this
(business requirements, etc.) and contractually arranging for what the
consequences are of a compromise, are too complex. Routing security should
be
strictly up to the administrative entity controlling the domain, and not
open to
anyone else.

The other applications you've brought up (service control, efficiency (?)
policy, regional handoff (?)) can be dealt with separately.

            jak

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

> James,
>
> One of the reasons that future versions of Nested (v4 or v6) have the
> registration routed via the LMM agent (the RMA) is so that the additional
> features requested by the MN are known to that box. This is critical for a
> range of commercially important reasons (service control, efficiency,
> policy) and also facilitates hand-off of the LMM agent (regional
hand-off).
>
> This then requires a chain of trust through MN-RMA-HA plus (as per the
other
> thread) the e2e security MN-HA. This would be one way for the use of AH to
> be detected if specifically requested or flagged in the MIPv6 signalling.
>
> Alan.
>
> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: 05 September 2002 10:58
> To: [email-masked]
> Cc: Hesham Soliman (EAB); [email-masked]; mobile-ip
> Subject: Re: [mobile-ip] LMM requirements: security issue
>
>
> Greg,
>
>
> > [about HMIPv6 Extended Mode]
> > >
> > >
> > > So what happens if AH tunnel mode is used?
> >
> >
> > In the situiation where AH and ESP are being used (say
> > from the HA to the MN for binding signalling), it would
> > be necessary to add a routing header outside the ESP or AH
> > header to gauarantee that the XMAP (Extended MAP) can
> > understand the packet.
> >
> > Note that this requirement is on the HA, which is
> > essentially unaware that an LMM is being used, and so is
> > a new requirement in MIPv6 (or a showstopper for current
> > extended mode ???).
> >
> > There already is a requirement to tunnel site-local
> > packets with a routing header for extended mode.
> >
>
> The other alternative is for the MAP to not decapsulate, as Hesham
> suggested.
> This requires some way for the MAP to know that an AH tunnel is in place.
>
>             jak
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 6 Sep 2002 09:48:28 -0700

Hi Alan,

> rather than routing security..

Then I guess I'm unsure exactly what role a regional agent would play in service
invocation.

The architecture I've had in mind is that the NAS or PAA is responsible for
admitting the mobile node onto the link. It conducts a transaction with the
local AAA server, which routes back to the home AAA server if the mobile is a
roamer. Part of that transaction may involve downloading a service profile for
the mobile. The service profile is available at the foreign AAA server for
various service agents to utilize, for example, the SIP proxy or CD network
caches, etc. Alternatively, if the home network doesn't want to download the
service profile,the service agents can query the local AAA server and the local
AAA server can route back to the home server for AAA. The regional agent doesn't
play any role here, it is just a routing proxy.

Right now, there is a disconnect between the AAA for network access and AAA for
service access in the IETF, due to the long hiatus in getting Diameter to Draft.
For single sign on, ideally one would like the network access authentication to
also provide authentication for services. The Liberty Alliance and Microsoft
Passport are working on service authentication. From a carrier's perspective, we
would really like to see single sign on derive from network access
authentication, but Liberty and Passport aren't going in that direction, so far
as I know, but we're talking with them about it.

Am I missing something w.r.t. the regional agent and service invocation? I read
through the NestedMIP specs and I recall a couple of mentions about this, but
nothing specific.

In any event, it might be a good idea at some point to write up some kind of
common architectural vision about how this should work, perhaps as a draft for
the AAA working group. We had something very specific for SIP a couple years
ago.

            jak

---

From: Michael Thomas <[email-masked]>
Date: Fri, 6 Sep 2002 10:20:54 -0700 (PDT)

James Kempf writes:
 > also provide authentication for services. 

   Why is this "ideal"? The entire point of the IP
   architecture is to not require all-in-one
   vertical applications/protocols... like
   ISUP. There are lot of ways to go about solving
   these problems; we shouldn't be prejudiced one
   way or the other. 

   The key here is to have the unifying elements
   of authentication built into the various
   protocols which require auth/authz. This
   include mundane stuff like straight password
   based protocols (CHAP, say), to Kerberos, PKI 
   and my personal fav Kerberos+PKI. Once those
   elements are built into the various protocols,
   it will be a lot easier to decide how to
   actually architect a network. The current
   situation with traditional AAA has some serious
   tail-wagging-dog syndrome, as in its proceeding
   from the premise "since this is all we have..."
   It's also suspiciously bellheaded -- like a
   HLR combover.

	Mike

---

From: "James Kempf" <[email-masked]>
Date: Fri, 6 Sep 2002 11:31:37 -0700

>    It's also suspiciously bellheaded -- like a

It is ideal because, quite frankly, the carriers want to avoid bankrupcy, an all
too common fate among telcom service providers these days. :-)  We would like to
see an IETF AAA architecture that can provide an *alternative* that will allow
charging and present the opportunity for incremental revenue. This doesn't mean
that everybody must follow that architecture, just that the alternative is
available. The HLR like architecture, of which you are rightly suspicious, is
not a viable alternative.

            jak