Subject: Re: [Seamoby] CARD between Routers - will CT do?

From: "Hemant Chaskar" <[email-masked]>
Date: Thu, 16 Jan 2003 04:24:23 +0000

Hi Daichi:

I do not think that establishment of SA between ARs should be within scope 
of CARD. We should start from pre-requisite that SA can be established 
between ARs. When ARs belong to same domain, this is simple. When they 
belong to different domain it is harder. In either case, there can be 
variety of ways to establish SAs - pre-shared key, domain specific 
certificates, AAA, credentials exchanged during SLAs or any other means. Why 
should CARD put any restriction on mechanism used to establish SA?

So, instead of

                      <--Interworking-->
                             |
         Intra-domain CARD   |       Inter-domain CARD
               protocol      |          protocol
         --------------------|------------------------------
         Intra-domain SA     |       Inter-domain SA
           mechanism         |          mechanism
        (CARD specific?)     |       (CARD specific?)

I am saying that, if possible, we should try,

                       CARD protocol
         ----------------------------------------------
                              |
         Intra-domain SA      |      Inter-domain SA
            mechanisms        |         mechanisms
        current/future best   |   (current/future best
            practices)        |          practices)

At this point, I cannot vouch for security of MN-report-based CARD approach. 
But, could you describe what kind of attacks do you think MN-report-based 
CARD is vulnerable to? In draft-trossen-seamoby-dycard-00.txt, we have shown 
that certain simple mechanisms can foil security attacks in MN-report-based 
CARD (To the least, if MN tells new AR arbitrary IP address as address of 
old AR, it can be detected). Also, the side effect of attacks, if any, does 
not adversely affect good MNs. But, of course, we could have missed some 
attack possibilities.

Hemant

>From: Daichi Funato <[email-masked]>
>To: [email-masked]
>CC: <[email-masked]>, <[email-masked]>, <[email-masked]>
>Subject: Re: [Seamoby] CARD between Routers - will CT do?
>Date: Wed, 15 Jan 2003 19:10:15 -0800
>
>Hi Hemant,
>
> > Hemant --> I think we can start protocol design under the assumptions 
>that
> > (i) old and new ARs can establish SA between them, (ii) they are willing 
>to
> > participate in CARD protocol. Then, there may not be any need for 
>intra-domain
> > / inter-domain classification.
>
>What kind of security mechanisms are you assuming?
>I think we should not leave the security mechanisms out of the scope.
>
>Especially, MN-report-based CARD is vulnerable to an attacker.
>How to protect the communication is an essential part of CARD, I think.
>Actually, IEEE IAPP includes a security mechanism by itself.
>Do we neglect that part in CARD?
>
>IMHO, if CARD can provide secure keys for ARs, these can be used by CT
>and FMIP as well. This is another type of capability discovery.
>What do you think?
>
>Best regards,
>Daichi
>
>-------------------------------------------------------------
>Daichi Funato <[email-masked]>
>DoCoMo Communications Laboratories USA, Inc.
>
>Confidential Note:
>Privileged/Confidential Information may be contained in this e-mail
>and any attachment to it. Unless you are the addressee indicated in
>this e-mail, please notify immediately the sender by reply e-mail
>that you have received this in error and delete it from your system.
>You may not use, copy or deliver this e-mail or any information
>contained in this e-mail to anyone.  Thank you very much.
>-------------------------------------------------------------
>
>_______________________________________________
>Seamoby mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/seamoby

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 16 Jan 2003 09:58:19 -0800

>          Intra-domain CARD   |       Inter-domain CARD
I also prefer one CARD protocol that works for inter-domain and intra-domain
operations.
We need to analyze security threats on CARD in details and find out security
requirements and solutions.
To discuss the security threats, first of all, we need to identify the
discovery mechanisms we want to consider.
There were two proposals before the design team was formed.
To continue discussion on security issues, I am looking for proposals on
base discovery mechanisms from the design team.
If the design team has the same proposals from the existing two proposals,
then we can start security analysis of the discovery mechanisms.
Regards,

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 16 Jan 2003 09:58:19 -0800

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Thu, 16 Jan 2003 09:48:47 -0800

What do you mean by an SA? An IPSec SA? If so, how do you propose to have the
routers use that for checking that the AP L2 addresses provided by the MN map
into IP addresses that are authorized to route on the service provider's
network?

Note that the IESG is requiring that the Security Considerations of all protocol
drafts describe, precisely, how the protocol will be secured. It is no longer
sufficient to say "use IPSec" or "use AAA". Requiring other protocols is OK, but
it must be specified precisely how those protocols are used for securing the
protocol in question.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 16 Jan 2003 09:48:47 -0800

jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 16 Jan 2003 10:21:58 -0800

Speaking with my service provider hat on...

Like I said, I think you will have a hard time persuading service providers to
utilize an interdomain protocol if it requires them to expose their internal
routing topology. I think they are likely to configure to simply reject any
information provided by the MN that does not correspond to routers in their
domain. There are some limited cases where it may be of use, two providers that
are subsidiaries of the same company for example, but they are not worth
spending time on right now.

I think we ought to concentrate on the intraprovider case, then revisit the
interprovider issue when we are done. Otherwise, we are likely to get bogged
down in the details of how to do something that, in the end, no service provider
wants. Let's make it *simple* first, then add things as it becomes apparent that
they are needed.

If there is some doubt about this, I can discuss it with our operations people
and have one of them come on the list with an opinion.

Perhaps other service providers on this list can speak up? Are there any on the
list?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 16 Jan 2003 10:21:58 -0800

jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 16 Jan 2003 09:29:53 -0800

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 16 Jan 2003 09:29:53 -0800

Eunsoo