RE: [netlmm] Issue: Auth Option support

"Alper Yegin" <alper.yegin@yegin.org> Mon, 10 September 2007 19:33 UTC

Return-path: <netlmm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUp0U-0007nD-3x; Mon, 10 Sep 2007 15:33:14 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUp0T-0007my-Ce for netlmm@ietf.org; Mon, 10 Sep 2007 15:33:13 -0400
Received: from mout.perfora.net ([74.208.4.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUp0S-00038s-KO for netlmm@ietf.org; Mon, 10 Sep 2007 15:33:13 -0400
Received: from [88.233.214.210] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IUp0G2MzU-0007TI; Mon, 10 Sep 2007 15:33:09 -0400
From: Alper Yegin <alper.yegin@yegin.org>
To: 'Vijay Devarapalli' <vijay.devarapalli@azairenet.com>
Subject: RE: [netlmm] Issue: Auth Option support
Date: Mon, 10 Sep 2007 22:32:46 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: Acfzva2V0HjGPcAAR7Gc0DPZRTrdUQAI0b/g
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
In-Reply-To: <46E55FF6.7090008@azairenet.com>
Message-Id: <0MKpCa-1IUp0G2MzU-0007TI@mrelay.perfora.net>
X-Provags-ID: V01U2FsdGVkX1//vM+0jDvtn0D0iXLq/exitYfrj+EItyRdHJ+ Cv/GWeFla7AZpoj4PbWqjMaoMafSCO+RClNWcJ9QnM/720a5Js 2p9I3z2GhZdBRok3IPx6A==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21be852dc93f0971708678c18d38c096
Cc: netlmm@ietf.org
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
Errors-To: netlmm-bounces@ietf.org

Vijay,

Where did you get that idea ("SHOULD" is not useful for achieving
interoperability) from? Definitely not in RFC 2129.

	1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that
the
	   definition is an absolute requirement of the specification.

	3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
there
	   may exist valid reasons in particular circumstances to ignore a
	   particular item, but the full implications must be understood and
	   carefully weighed before choosing a different course.


Alper 

> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]
> Sent: Monday, September 10, 2007 6:17 PM
> To: Alper Yegin
> Cc: 'Narayanan, Vidya'; 'Sri Gundavelli'; 'Julien Laganier';
> netlmm@ietf.org
> Subject: Re: [netlmm] Issue: Auth Option support
> 
> Alper,
> 
> When we need to ensure interoperability, we use "MUST" and not "SHOULD".
> 
> Vijay
> 
> Alper Yegin wrote:
> > For interop "SHOULD implement and use", or even "SHOULD use" (like
> Julien
> > explained) is fine. "SHOULD" means "you better know what you are doing
> if
> > you don't follow", and that's exactly the case.
> >
> > If both ends are using some other mechanism and they know what each
> other
> > supports, they should not have to worry about (and implement) the
> mechanism
> > in the base spec. This is what SHOULD is for.
> >
> > Alper
> >
> >
> >> -----Original Message-----
> >> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]
> >> Sent: Friday, September 07, 2007 10:27 PM
> >> To: Sri Gundavelli; Julien Laganier; netlmm@ietf.org
> >> Subject: RE: [netlmm] Issue: Auth Option support
> >>
> >> All,
> >> On this topic, I believe we must have a mandatory to implement
> mechanism
> >> specified for standards track publication.  We can leave the use at
> >> "RECOMMENDED" or "SHOULD", but, we need a "MUST" on what the LMA and
> MAG
> >> need to implement.
> >>
> >> I had run this by the security directorate at the Chicago meeting and
> my
> >> understanding is that as long as we have "MUST implement IPsec" and
> >> "SHOULD use IPsec", it would be fine.
> >>
> >> In other words, the SHOULD vs. MUST that we want to place on using
> IPsec
> >> can be discussed, but, the "MUST" on implementation is non-negotiable.
> >>
> >> This is inline with my understanding on what we need to state for a
> >> complete specification.  Given that channel security of signaling
> >> messages is mandatory, unless we have at least one common denominator
> >> that the MAG and LMA implementors will implement, we cannot ensure
> >> interoperability.  If they support multiple common mechanisms and chose
> >> to use something other than IPsec, that's fine - hence, the "SHOULD" on
> >> usage.
> >>
> >> Hope that helps.
> >>
> >> Thanks,
> >> Vidya
> >>
> >>> -----Original Message-----
> >>> From: Sri Gundavelli [mailto:sgundave@cisco.com]
> >>> Sent: Friday, September 07, 2007 10:10 AM
> >>> To: 'Julien Laganier'; netlmm@ietf.org
> >>> Subject: RE: [netlmm] Issue: Auth Option support
> >>>
> >>> Hi Julien,
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: julien laganier [mailto:julien.laganier@gmail.com] On
> >>> Behalf Of
> >>>> Julien Laganier
> >>>> Sent: Friday, September 07, 2007 5:29 AM
> >>>> To: netlmm@ietf.org
> >>>> Cc: Sri Gundavelli; 'Alper Yegin'
> >>>> Subject: Re: [netlmm] Issue: Auth Option support
> >>>>
> >>>> Hi Sri,
> >>>>
> >>>> On Thursday 06 September 2007, Sri Gundavelli wrote:
> >>>>> 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.
> >>>> Somehow, "MUST implement" and "SHOULD use" together seems a bit
> >>>> tautologic.
> >>>>
> >>>> To me "SHOULD use" is sufficient since it covers both of the two
> >>>> possibles cases:
> >>>>
> >>>> - deployment follows the SHOULD recommendation, it uses IPsec to
> >>>> protect PMIPv6, in which case it supports it, since it's
> >>> using it :),
> >>>> or
> >>>>
> >>>> - deployment ignores the SHOULD recommendation, does not
> >>> uses IPSec,
> >>>> in which case it is useless to implement it since it's not used...
> >>>>
> >>>> I'd prefer having "MUST protect integrity of signalling
> >>> messages, and
> >>>> SHOULD use IPsec ESP to protect integrity of those messages".
> >>>> We might
> >>>> also add "MAY use IPsec AH".
> >>>>
> >>>
> >>> I agree. I'm not against allowing other approaches. I'm only
> >>> concerned, if we can leave the draft saying, "MUST protect
> >>> integrity of signalling messages", with out specifying IPsec
> >>> or some other approach. If that will pass the security
> >>> review. We may have to state that IPsec MUST be used or some
> >>> other approach, say Auth-Option MUST be used. Not sure, if we
> >>> can leave this blank.
> >>>
> >>> Sri
> >>>
> >>>
> >>> _______________________________________________
> >>> netlmm mailing list
> >>> netlmm@ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/netlmm
> >>>
> >> _______________________________________________
> >> netlmm mailing list
> >> netlmm@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/netlmm
> >
> >
> > _______________________________________________
> > netlmm mailing list
> > netlmm@ietf.org
> > https://www1.ietf.org/mailman/listinfo/netlmm



_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm