Subject: RE: PANA FAQ

From: <[email-masked]>
Date: Thu, 27 Jun 2002 13:35:58 -0500

Erik,

>
>> But this is not a problem introduced by PANA, or by the
>> "ND should take place after PANA" suggestion.
>> 
>> Doing ND after PANA doesn't make the system less secure.
>> It's easier (not always possible, like in your pre-paid card example)
>> to secure ND if it takes place after PANA, because of the initial
>> bootstraping via PANA.
>
>Yes, but those are also arguments for L2 authentication.
>I sense an undertone that PANA needs to be as good as L2 authentication
>(e.g. by being able to use it before IP addresses has been assigned)
>but will use IP packet formats for some perceived notion of "L2 independence".
>I don't think that PANA needs to compete with L2 authentication - I think
>it fills a different nitch.

PANA aims to fill in a different gap. So I agree with your view that
the niche that PANA is looking at is different from the L2
authentication mechanisms that are currently available. I really doubt
that PANA would be used for L2 authentication in networks that have
solutions today (802.1x, PPP). However PANA could still be useful in
these networks for authorizing access to resources (that require
users to identify before being provided access) or may be used as a
mechanism for periodic reauthentication of an existing connection that
was originally authenticated using an L2 mechanism.

So PANA does not aim to compete with the existing L2 mechanisms. I
believe it will complement the existing solutions. However I still do
not understand why PANA should have the limitation of not working
without a valid IP address. If a network is unwilling to provide
access (or L2 connectivity) without authenticating at L2, PANA would
be useless anyway. However if such networks do exist (I cannot give an
example of such at this time :( ) and the operator is willing to
provide L2 connectivity without authentication and will only provide
L3 connectivity if authentication is succesful, then there is no
reason to limit the scope of PANA in such networks.   

>And the problem with the desire to do this is that it makes it very
>hard (or impossible) to reuse existing IP protocols, since few if any
>work using unspecified address.

As stated previously by Alper and others, Mobile IPv4 currently allows
the MN to bootstrap with an unspecified address. 

>
>For example, if it turns out that e.g. PIC could be reused, the requirement
>that the protocol operate using unspecified addresses means that it couldn't
>be reused.

I agree. Maybe that would rule out the use of PIC or a clone of PIC
that could work with unspecified address can be developed.

>
>> Yes, CGA based techniques can be a candidate, but details might be
>> important. For example, do they work for IPv4?
>
>What does "ND" stand for in "the SEND BoF"?
>I haven't seen anybody suggesting a SEARP BoF.
>
>   Erik

-Basavaraj

> -----Original Message-----
> From: ext Erik Nordmark [mailto:[email-masked]]
> Sent: 12 June, 2002 10:30 AM
> To: Alper E. YEGIN
> Cc: Erik Nordmark; Yoshihiro Ohba; Thomas Narten; Patil Basavaraj
> (NET/Dallas); [email-masked]
> Subject: Re: PANA FAQ
> 
> 
> > But this is not a problem introduced by PANA, or by the
> > "ND should take place after PANA" suggestion.
> > 
> > Doing ND after PANA doesn't make the system less secure.
> > It's easier (not always possible, like in your pre-paid 
> card example)
> > to secure ND if it takes place after PANA, because of the initial
> > bootstraping via PANA.
> 
> Yes, but those are also arguments for L2 authentication.
> I sense an undertone that PANA needs to be as good as L2 
> authentication
> (e.g. by being able to use it before IP addresses has been assigned)
> but will use IP packet formats for some perceived notion of 
> "L2 independence".
> I don't think that PANA needs to compete with L2 
> authentication - I think
> it fills a different nitch.
> And the problem with the desire to do this is that it makes it very
> hard (or impossible) to reuse existing IP protocols, since few if any
> work using unspecified address.
> 
> For example, if it turns out that e.g. PIC could be reused, 
> the requirement
> that the protocol operate using unspecified addresses means 
> that it couldn't
> be reused.
> 
> > Yes, CGA based techniques can be a candidate, but details might be
> > important. For example, do they work for IPv4?
> 
> What does "ND" stand for in "the SEND BoF"?
> I haven't seen anybody suggesting a SEARP BoF.
> 
>    Erik
> 
>