Re: [Mip6] Summary of Justification for AlternativeAuthenticationOption

[Gopal Dommety <[e-mail]>]

James,


I don't see the issue with mandating in the RFC that both mechanisms should 
be supported on the HA.
If someone chooses to ignore the standard they will do it at their own risk.


I was simplifying the positions...apologies for the mis-representation.

thanks,
-Gopal


At 01:41 AM 9/25/2004 -0700, James Kempf wrote:
>Raj,
>
>Whether we agree is not the point, the point is that Gopal's email was
>ostensibly a summary of the discussion on the list, and I believe it missed
>an important point that I brought up, namely that IETF cannot mandate
>whether an operator enables their HA to accept both kinds of traffic or not,
>and if we standardize two ways of doing the same thing - even if we mandate
>that the HA support both - an operator can decide to support only one
>causing an interoperability problem.
>
>Additonally, I believe Gopal's summary misrepresented my position. My
>position is not one of unqualified support for the authentication option. It
>is:
>
>- We should select either IPsec or the authentication option (RFC 1958, if
>there's two choices for the same functionality, choose one).
>
>- Since we have already standardized IPsec and the authentication option is
>only of interest to cdma2K operators, we should process the authentication
>option as an informational draft and *NOT* an Internet standard.
>
>I hope that makes my position clearer. I hope, in the future, that the WG
>chairs will strive to be a little more accurate and objective when
>performing concensus calls.
>
>             jak
>
>----- Original Message -----
>From: <[e-mail]>
>To: <[e-mail]>; <[e-mail]>; <[e-mail]>
>Sent: Friday, September 24, 2004 8:51 AM
>Subject: RE: [Mip6] Summary of Justification for
>AlternativeAuthenticationOption
>
>
>
>James,
>
>I disagree with the need for having such a mechanism in view of the fact
>that an HA is expected to support both the authentication schemes
>mandatorily.
>
>-BPa
>
> >
> > Gopal,
> >
> > I believe you missed the need for some mechanism to allow an
> > MN to determine
> > which authentication technique to use. Without this, there is an
> > interoperability problem, because the MN cannot infer simply from the
> > failure of the signaling that it should try the other method.
> >
> >             jak
> >
> > ----- Original Message -----
> > From: "Gopal Dommety" <[e-mail]>
> > To: <[e-mail]>
> > Sent: Thursday, September 23, 2004 2:55 PM
> > Subject: [Mip6] Summary of Justification for Alternative
> > AuthenticationOption
> >
> >
> > > Hello All,
> > >
> > >              I am attaching a summary of the discussion
> > that took place on
> > > justification of an alternate authentication mechanism.
> > Please let me
> > know if
> > > I have left out any important issue in the summary. I could
> > have also
> > mis-read
> > > people opinions, so if there is a correction please let me
> > know. I will
> > > send a follow-up
> > >   email with the next steps.
> > >
> > >
> > > Thanks,
> > > -Gopal
> > >
> > >
> > > Summary
> > > =======
> > >
> > > The WG has been engaged in a discussion over the last week on the
> > > topic of standardizing an authentication date suboption based
> > > mechanism for the purpose of registering an MN with its HA via the
> > > BU/BAck messages.
> > > To summarize the discussion in brief:
> > > 1. The I-D draft-patil-mip6-whyauthdataoption-00.txt was used as the
> > >     baseline for the discussion
> > > 2. Opinion was expressed that the I-D was more inclined in
> > justifying
> > >     why the use of  IKE was a problem for setting up the
> > MN-HA IPsec SA
> > >     and not really providing sufficient justifications for an
> > >     alternative scheme to the use of IPsec for securing the
> > signaling
> > >     messages between the MN and HA
> > > 3. There were a few people who expressed strong views of
> > keeping IPsec
> > >     as the only means for MIP6 security between MN and HA
> > (Francis and
> > > Hesham (?))
> > > 4. There were others who claimed the need for an alternate option to
> > >     MIP6 including one operator who plans to deploy the protocol in
> > >     their network (Raj, James Kempf, Alpesh, Gopal, Kuntal,
> > Vijay, Michael
> > Roe)
> > > 5. There was also a note from an implementers perspective on the
> > >     challenges of integrating MIP6 with IPsec (Michael Roe)
> > > 6. There was discussion about the problem of replay attacks and the
> > >     need for key refreshment
> > > 7. IKEv2 is expected to provide a solution to the problem of setting
> > >     up dynamic SAs in networks that rely on AAA
> > infrastructures. While
> > >     IKEv2 itself has been approved, the details of how IKEv2 is used
> > >     with MIP6 are still being worked out in an I-D that is not ready
> > >     yet.
> > > 8. There was an opinion that the bootstrap work being done in the WG
> > >     would address the needs of the environment claimed in I-D
> > >     draft-patil-mip6-whyauthdataoption-00.txt
> > >
> > >
> > > _______________________________________________
> > > Mip6 mailing list
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/mip6
> > >
> >
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/mip6
> >


_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6