RE: [netlmm] Issue: Auth Option support

["Alper Yegin" <[e-mail]>]

I agree.

It is OK for the base spec to define one mechanism (IPsec) used with one
model (per-MAG-LMA SA). But we shall not limit all deployments to those
choices.

Alper

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[e-mail]]
> Sent: Monday, September 10, 2007 6:03 PM
> To: Ahmad Muhanna
> Cc: Sri Gundavelli; Alper Yegin; [e-mail]
> Subject: Re: [netlmm] Issue: Auth Option support
> 
> Ahmad,
> 
> I don't believe the security model of using just one security
> association between the MAG and the LMA for protecting the proxy BU and
> Proxy BAck changes irrespective of whether IPsec or RFC 4285 is used. So
>   I don't agree with the suggested change.
> 
> Vijay
> 
> Ahmad Muhanna wrote:
> >
> >> Subject: Re: [netlmm] Issue: Auth Option support
> >>
> >> Sri,
> >>
> >> I agree with "SHOULD" for using IPsec and "MUST" for
> >> supporting IPsec on the MAG and the LMA.
> >>
> >> If thats the consensus, we need to modify a few sentences in
> >> the draft.
> >>
> >> In section 4, replace
> >>
> >>>    The signaling messages, Proxy Binding Update and Proxy Binding
> >>>    Acknowledgement, exchanged between the mobile access
> >> gateway and the
> >>>    local mobility anchor MUST be protected using IPsec
> >> [RFC-4301] and
> >>>    using the established security association between them.  The
> >>>    security association of the specific mobile node for which the
> >>>    signaling message is initiated is not required for
> >> protecting these
> >>>    messages.
> >> with
> >>
> >>     The signaling messages, Proxy Binding Update and Proxy Binding
> >>     Acknowledgement, exchanged between the mobile access
> >> gateway and the
> >>     local mobility anchor MUST be protected using security
> >> associations
> >>     established between them. The security association of the specific
> >>     mobile node for which the signaling message is initiated is not
> >>     required for protecting these messages.
> >>
> >> We need the MUST above since we have to say that the proxy BU
> >> and proxy BAck must be protected, irrespective of whether
> >> IPsec or some other mechanism is used.
> >
> > [Ahmad]
> > Hi Vijay,
> >
> > As far as I remember, the whole security concept of using a per-Node SA
> > for PMIPv6 was based on the use of IPsec. Although, I see why you
> > proposed the text but I still see a problem here. For example, the above
> > text allows the use of an authentication option similar to FA-HA AE to
> > secure the P-BU/P-BA.
> >
> > Now, since allowing a per-Node SA to be used in PMIPv6 was based on the
> > use of IPsec, I believe we clearly need to keep that as part of the spec
> > text.
> >
> > What about the following slight modification to what you just proposed:
> >
> >     The signaling messages, Proxy Binding Update and Proxy Binding
> >     Acknowledgement, exchanged between the mobile access gateway and the
> >     local mobility anchor MUST be protected using a security association
> >     established between them. If IPsec is used, the security association
> >
> >     of the specific mobile node for which the signaling message is
> > initiated
> >     is not required for protecting these messages.
> >
> > Thanks,
> > Ahmad
> >
> >> Add one sentence that says
> >>
> >>     The mobile access gateway and the local mobility anchor MUST
> >>     implement IPsec for protecting the Proxy Mobile IPv6 signaling
> >>     messages [RFC-4301].
> >>
> >> The paragraph that comes after already uses "SHOULD" for using ESP.
> >>
> >>>    IPsec ESP [RFC-4303] in transport mode with mandatory integrity
> >>>    protection SHOULD be used for protecting the signaling messages.
> >>>    Confidentiality protection of these messages is not required.
> >> Hope that is sufficient.
> >>
> >> Vijay
> >>
> >>
> >> Sri Gundavelli wrote:
> >>> I want some comments on this issue raised by Alper.
> >>>
> >>>
> >>> Also, if I interpret Sec 5.1 [3775], the IPSec is being
> >> mandated, only
> >>> the use of IPsec ESP is optional.
> >>>
> >>> --------
> >>> 5.1.  Binding Updates to Home Agents
> >>>
> >>>    The mobile node and the home agent MUST use an IPsec security
> >>>    association to protect the integrity and authenticity of
> >> the Binding
> >>>    Updates and Acknowledgements.  Both the mobile nodes and the home
> >>>    agents MUST support and SHOULD use the Encapsulating
> >> Security Payload
> >>>    (ESP) [6] header in transport mode and MUST use a
> >> non-NULL payload
> >>>    authentication algorithm to provide data origin authentication,
> >>>    connectionless integrity and optional anti-replay
> >> protection.  Note
> >>>    that Authentication Header (AH) [5] is also possible but
> >> for brevity
> >>>    not discussed in this specification.
> >>> -------
> >>>
> >>>
> >>> I'm confused, should the draft say
> >>>
> >>> "Both LMA and MAG MUST implement IPsec" and "all the signaling
> >>> messages SHOULD be protected using IPSec".
> >>>
> >>> Will this ok, when reviewed by the security folks ?
> >>>
> >>> or mandate IPsec for this specification and let other draft
> >> relax this
> >>> in the presence of an alternative approach ?
> >>>
> >>> Please comment.
> >>>
> >>>
> >>> Sri
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Alper Yegin [mailto:[e-mail]]
> >>>> Sent: Tuesday, August 07, 2007 1:41 AM
> >>>> To: 'Sri Gundavelli'; [e-mail]
> >>>> Subject: RE: [netlmm] Issue: Auth Option support
> >>>>
> >>>>> The issue was related to the use of MUST clause in specifying the
> >>>>> IPSec requirement for Proxy Mobile IPv6 protocol. Alper was
> >>>>> suggesting that we relax that requirement and potentially leave a
> >>>>> room for Auth Option support in future.
> >>>> Actually, I didn't mean it specifically for Auth Option. It can be
> >>>> anything.
> >>>> Given that the security is handled by a separate protocol,
> >> why lock
> >>>> it down to "IPsec", when some other protocol (Auth Option being one
> >>>> example) cannot
> >>>> be used.
> >>>>
> >>>>> But, as most people agreed and as supported by Jari, this can
> >>>> My understanding was the opposite, especially about Jari's
> >> statement.
> >>>>> always be changed in future when the support for new security
> >>>>> mechanisms such as Auth Option are defined for Proxy
> >> Mobile IPv6 and
> >>>>> that specific document can always modify this requirement.
> >>>>> So, no changes will be made to the document on this issue.
> >>>> What if Auth Option is good enough as written?
> >>>> What if a document in another SDO defines the alternative security
> >>>> mechanism?
> >>>>
> >>>> For the type of interop we are seeking in IETF, "MUST
> >> implement" is
> >>>> good enough. "MUST use" is not necessary.
> >>>>
> >>>> Alper
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Regards
> >>>>> Sri
> >>>>>
> >>>>> _______________________________________________
> >>>>> netlmm mailing list
> >>>>> [e-mail]
> >>>>> https://www1.ietf.org/mailman/listinfo/netlmm
> >>> _______________________________________________
> >>> netlmm mailing list
> >>> [e-mail]
> >>> https://www1.ietf.org/mailman/listinfo/netlmm
> >>
> >> _______________________________________________
> >> netlmm mailing list
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/netlmm
> >>



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