RE: [netlmm] Issue: Auth Option support

["Sri Gundavelli" <[e-mail]>]

Vijay/Raj,

I agree. Will make these changes.

Sri
 

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[e-mail]] 
> Sent: Sunday, September 09, 2007 7:47 PM
> To: Sri Gundavelli; 'Alper Yegin'
> Cc: [e-mail]
> 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.
> 
> 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