Subject: Re: [netlmm] Lack of session indication

From: "Koodli, Rajeev" <[email-masked]>
Date: Mon, 11 Aug 2008 14:55:10 -0400

Hi Vijay,

> 
> Or we could define a new status code '3' that would say "Missing Proxy
> Binding Cache Entry".
> 
> Using an "Unsolicited Node Echo Reply" (or an unsolicited Heartbeat
> Response) seems wrong semantically. Of course, both would work.
> 

[RKo:>] Why is it wrong semantically? We did not encounter this scenario
earlier. At this stage, given that this is not addressed in the base
PMIP specification, path management ID is the right place to specify
this, and I wish to keep the number of messages exchanged to minimal
(two, in draft-koodli-netlmm-path-and-session-management) and
self-contained. 

-Rajeev

> Comments?
> 
> Vijay
> 
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Koodli, Rajeev
> > Sent: Monday, August 11, 2008 7:57 AM
> > To: Shi Xiaoyan
> > Cc: [email-masked]
> > Subject: Re: [netlmm] Questions for
> > koodli-netlmm-path-and-session-management
> >
> > Hello Xiaoyan,
> >
> >
> >
> > Yes, we will clarify that in the next version.
> >
> > I think we can also use GRE Keys for the same purpose.
> >
> >
> >
> > Regards,
> >
> >
> >
> > -Rajeev
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From: Shi Xiaoyan [mailto:[email-masked]]
> > Sent: Sunday, August 10, 2008 8:29 PM
> > To: Koodli, Rajeev
> > Cc: [email-masked]; 'tanshiyong'
> > Subject: Questions for koodli-netlmm-path-and-session-management
> >
> >
> >
> > Hi,Rajeev
> >
> >
> >
> > In section 3:
> >
> >
> >
> >    Due to a full or partial failure, a node may no longer have
session
> >    information (i.e., BCE) for some MN.  When a packet from
> > its peer for
> >    such a MN is received (e.g., LMA receives a packet from a MAG),
the
> >    node SHOULD immediately send a U-NERP message containing the MN-
> >    Identifier.  This informs the peer of the absence of a BCE
> > for the MN
> >    identified by the MN-Identifier.
> >
> >
> >
> > Data packets between LMA and MAG are IP-in-IP encapsulated.
> > When LMA recieves a data packet without matching BCE, LMA
> > only obtain the inner source IP address. It means that LMA
> > don't know which MN the data packet belongs to  and LMA only
> > know there is not a BCE matching the inner source IP.
> >
> >
> >
> > So, I think the U-NERP should be identified by home address
> > (HoA, inner source IP).
> >
> >
> >
> >
> >
> > Regards,
> > Xiaoyan
> >
> >
> >
> >
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Mon, 11 Aug 2008 15:19:03 -0400

> 
> I am fine with the "lack of session indication" message being
specified
> in the path management draft. Anyway, nothing can be added to the
PMIPv6
> base specification at this point. It has already completed the AUTH48
> stage.

[RKo:>] yes, okay.
> 
> BTW, Binding Error is part of the MIPv6/PMIPv6 stack. It is not a new
> message.
> 

[RKo:>] I understand.

> Using path management messages for this is semantically wrong, IMO.
The
> reason is that the path management messages are used for checking path
> reachability and restart of PMIPv6 end points. They are not specific
to
> a particular mobile node's session. We already have a message for
> indicating lack of a binding, i.e., the Binding Error message. I am
> suggesting re-using that message.

[RKo:>] This involves the debate of what is "path management". In
addition to the restart and reachability, it also includes MN-specific
error handling. At least that should be the intent if we also wish to
satisfy stage 3 requirements in 3GPP. 

-Rajeev

> > "This email message and any attachments are confidential information
of
> Starent Networks, Corp. The information transmitted may not be used to
> create or change any contractual obligations of Starent Networks,
Corp.
> Any review, retransmission, dissemination or other use of, or taking
of
> any action in reliance upon this e-mail and its attachments by persons
or
> entities other than the intended recipient is prohibited. If you are
not
> the intended recipient, please notify the sender immediately -- by
> replying to this message or by sending an email to
> [email-masked] -- and destroy all copies of this
message
> and any attachments without reading or disclosing their contents.
Thank
> you."

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 11 Aug 2008 17:48:59 -0400

> satisfy stage 3 requirements in 3GPP. 

Would 3GPP mind if we define MN-specific error indication using the
Binding Error message? :)

It shouldn't matter to them.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 11 Aug 2008 22:29:53 -0700 (PDT)

Hi Rajeev,

On Mon, 11 Aug 2008, Koodli, Rajeev wrote:

>
> Hi Sri,
>
>> Lets step back a bit and explore this scenario when we would need
>> this.
>>
>> a.) MAG deregistered the session
>> b.) LMA terminated the session
>> c.) LMA rebooted
>>
>> For #a, MAG would take out the BUL entry and policy routes fro
>> the MN's HNP. So, the LMA should not see this tunneled packet
>> and hence no need for additional error message.
>
> [RKo:>] Okay, but the MAG may receive a packet from LMA for the MN.
>

hmm ... If the MAG has performed de-registration procedure with the
LMA, the states should be cleared on both the peers. All the explicit
session termination events on the LMA or MAG or the normal dereg
procedures on the MAG, should always clear the session states on both
the peers. If this does not work reliably, any new signaling messages
will suffer the same.

>> For #c, its not session specific. We need either a notification
>> message, other mechanism such as restart-counter, or other
>> mechanism.
>>
>
> [RKo:>] After LMA reboots, packets can continue to arrive for a MN from
> the MAG until the re-start counter cycle syncs up. In order to reduce
> this potentially long delay, we defined an error message to be sent
> immediately upon recovery (see Unsolicited Node Echo Reply message in
> draft-koodli-netlmm-path-and-session-management). This should work, but
> not entirely reliable - packets may still arrive for a MN. In such a
> case, the LMA informing the MAG is expected to force the MAG to clean up
> state and re-issue binding registration. A similar mechanism for 3G
> exists - see 3GPP spec TS 23007, Section 10). The node behaviors must be
> specified although a mechanism such as Unsolicited Node Echo Reply
> (U-NERP) can reduce the chances of receiving packets for a MN without a
> BCE.
>
> What we need is a message from LMA to MAG with "no binding exists for
> HoA/HNP or for GRE Keys", which are present in the data packet itself.
> We can do that also with a U-NERP message.
>

I've not analyzed this scenario or the proposed solution in detail.
Some how we need an indication to the peer on the state loss.

Sri

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 12 Aug 2008 13:31:45 -0400

> the peers. If this does not work reliably, any new signaling messages

[RKo:>] My bad. I was thinking of the analogue of what we have been
discussing - LMA receiving packets for a MN when no BCE exists. 

> Some how we need an indication to the peer on the state loss.

[RKo:>] Yes, we need to capture this.

-Rajeev

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 Aug 2008 11:41:59 -0700 (PDT)

Hi Vijay,
  My comment inline below.

Regards,

Behcet

----- Original Message ----
From: Vijay Devarapalli <[email-masked]>
To: "Koodli, Rajeev" <[email-masked]>; Sri Gundavelli <[email-masked]>; Basavaraj Patil <[email-masked]>; Hesham Soliman <[email-masked]>; Ahmad Muhanna <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, August 13, 2008 12:46:50 PM
Subject: Re: [netlmm] Lack of session indication

Hello all,

I am confused by this email thread. Not sure what was concluded. 

[behcet] I am also confused.
What does the "session" indicate here? Are we talking about OSI Layer 5, the session layer? I am also referring to the session management draft draft-koodli-netlmm-path-and-session-management. Is the session between MAG and LMA?

We need to conclude on whether the LMA should silently drop the tunneled
packets or send a message to indicate absence of the binding cache
entry.

IMO, if there is an unsolicited Heartbeat Response (or an unsolicited
Node Echo Reply) message sent by the LMA after it reboots and looses
PMIPv6 session state and if there is a binding revocation message from
the LMA to the MAG whenever a binding is removed, then we eliminate all
possible cases of ending up in a situation where the MAG thinks there is
a BCE when there isn't one at the LMA. The unsolicited Heartbeat
Response or the binding revocation could be lost, but then we start
dealing with extreme corner cases. The LMA dropping the tunneled packets
is sufficient. More so, since there is a cost associated with triggering
a control plane message from the data plane for the MN-specific
indication.

Let me know if folks agree/disagree with this.

Vijay

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 13 Aug 2008 14:55:23 -0400

Hi Sri,

> 
> > or send a message to indicate absence of the binding cache
> > entry.
> 
> A resounding NO to this, I thought.

[RKo:>] Perhaps from you :-)

> 
> As I see it, the gap/scenarios are:
> 
> 1.) Failure in LMA-MAG path, detection
> 2.) Inconsistent binding states on the LMA/MAG for the following
>      reasons
>     a) MAG performed a dereg procedure
>     b) LMA/MAG trigerred a revocation procedure
>     c) LMA/MAG rebooted
> 
> Nothing is required for #a. States are cleared on both the ends.
> So is for #b with the use of revocation message.
> 
> For #c, we need a mechanism for the peers to detect the peer rebooted
> and all the sessions are gone. We need this indication. The missing
> pieces are #1 and #2c.  No need for reacting to tunneling messages
> etc, thats not required.
> 

[RKo:>] We don't need to "react to tunneling messages". However, absence
of a BCE is still an issue. I hope we do not have to deal with it, but
we need to cover the case. At least not covering this case is not fully
clear.

Regards,

-Rajeev
 
> >> From: Koodli, Rajeev [mailto:[email-masked]]
> >> Sent: Tuesday, August 12, 2008 10:32 AM
> >> To: Sri Gundavelli
> >> Cc: Vijay Devarapalli; Shi Xiaoyan; [email-masked]
> >> Subject: RE: Lack of session indication
> >>
> >>
> >>
> >> "This email message and any attachments are confidential
> >> information of Starent Networks, Corp. The information
> >> transmitted may not be used to create or change any
> >> contractual obligations of Starent Networks, Corp.  Any
> >> review, retransmission, dissemination or other use of, or
> >> taking of any action in reliance upon this e-mail and its
> >> attachments by persons or entities other than the intended
> >> recipient is prohibited. If you are not the intended
> >> recipient, please notify the sender immediately -- by
> >> [email-masked] -- and destroy all copies of
> >> this message and any attachments without reading or
> >> disclosing their contents. Thank you."
> >>
> >

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 13 Aug 2008 18:03:05 -0400

Hi Sri,

For some reason, I didn't get your reply directly..

I am not suggesting that the datapath signal the control plane upon loss
of every packet. We don't want to do that. An indication along the lines
of ICMP unreachable (in the kernel) or an event that's triggered upon
loss of some configurable number of packets could be couple of options. 

-Rajeev

> From: Basavaraj Patil [mailto:[email-masked]]
> Sent: Wednesday, August 13, 2008 12:17 PM
> To: Sri Gundavelli; Koodli, Rajeev
> Cc: Vijay Devarapalli; Hesham Soliman; Ahmad Muhanna; Shi Xiaoyan;
> [email-masked]
> Subject: Re: Lack of session indication
> 
> 
> Sri,
> 
> I guess it is possible to have an LMA in a state which loses a BCE of
an
> MN
> for whatever reason. This is a scenario which may be remote, but
> nonetheless
> exists. An error message to the MAG would address this problem with no
> significant impact IMO.
> 
> -Raj
> 
> 
> On 8/13/08 1:59 PM, "Sri Gundavelli" <[email-masked]> wrote:
> 
> > Hi Rajeev,
> >
> >
> >
> > On Wed, 13 Aug 2008, Koodli, Rajeev wrote:
> >
> >>
> >> Hi Sri,
> >>
> >>>
> > To make sure, for data path message, if there is no binding, you are
in
> > favour of sending a signaling error message ?
> >
> > I'm not able to see when we would end up with this case, if we solve
> > the #1 and #2 (a,b and c) cases from my prev email. Unless, I'm
missing
> > some other scenario.
> > Regards

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 29 Aug 2008 12:50:32 -0400

Hi Ahmed,

> > [RKo:>] The packets are coming from a MAG with which the LMA
> > has trust relationship - this is typically the case in an
> > operator environment.
> > The notification from the LMA should follow the same security
> > model used to secure all signaling between the LMA and the
> > MAG. The MAG may choose to renew the binding or de-register
> > the binding.
> 
> [Ahmad]
> I am not sure what the trust relationship between the MAG and the LMA
> has to do with the scenario at hand. This trust relationship is
> meaningful when there is a SA that is used to protect the traffic in
> question, data traffic. 

[RKo:>] Trust relationship defines the security model, which in turn is
enforced using SA.

> As long as the traffic is not secured that trust
> relationship has no value here. 

[RKo:>] It is entirely up to the trust relationship/security model what
type of security is employed. For instance, some deployments are
perfectly fine using data origin authentication whereas others may
require encryption.
 
> Unless we are assuming that there is a
> specific deployment here that we have in mind and goes beyond this
trust

[RKo:>] I don't understand how you can implement a security mechanism
without assuming a trust model. So, I don't follow the above sentence.

Regards,

-Rajeev

> relationship. In that case, I have the following two comments:
> 
> 1. More details on such deployment is helpful in order to identify
what
> is applicable and what is NOT.
> 
> 2. If the MAG and the LMA has a trust relationship that allows the LMA
> to react with a signaling control message when receiving an unsecured
> data packet, then why not use that trust relationship to exchange
> control signaling between the MAG and LMA, e.g. PMIP signaling,
without
> the need for a MAG-LMA SA to start with.
> 
> Regards,
> Ahmad
> 
> >
> > Regards,
> >
> > -Rajeev
> >
> > >
> > > Cheers,
> > >
> > > Jonne.
> > >
> > >
> > > On 8/14/08 4:41 AM, "ext Sri Gundavelli" <[email-masked]>
wrote:
> > > >> I am not suggesting that the datapath signal the control
> > plane upon
> > > loss
> > > >> of every packet. We don't want to do that. An indication
> > along the
> > > lines
> > > >> of ICMP unreachable (in the kernel) or an event that's
triggered
> > upon
> > > > Doing this data plane is complex. Its better to handle this
> > scenarios
> > > > in the context of general session management, IMO.
> > > >
> > > >
> > > > Thanks
> > > > Sri
> > > >
> > > >
> > > --
> > > Jonne Soininen
> > > Nokia Siemens Networks
> > > Tel: +358 40 527 46 34
> > > E-mail: [email-masked]
> > >
> >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 29 Aug 2008 12:47:02 -0500

Hi Rajeev,

One of the trust definition that I have looked at recently in the
context of security architecture is as follows: 

"Generally an entity can be said to 'trust' a second entity when the
first entity makes the assumption that the second entity will behave
exactly as the first entity expects all the time"

At any rate, please see some comments below.

Regards,
Ahmad

> Sent: Friday, August 29, 2008 11:51 AM
> To: Muhanna, Ahmad (RICH1:2H10); Soininen Jonne (NSN 
> FI/Espoo); ext Sri Gundavelli
> Cc: [email-masked]
> Subject: RE: [netlmm] Lack of session indication
> 
> 
> Hi Ahmed,
> 
> > > [RKo:>] The packets are coming from a MAG with which the LMA has 
> > > trust relationship - this is typically the case in an operator 
> > > environment.
> > > The notification from the LMA should follow the same 
> security model 
> > > used to secure all signaling between the LMA and the MAG. The MAG 
> > > may choose to renew the binding or de-register the binding.
> > 
> > [Ahmad]
> [RKo:>] Trust relationship defines the security model, which 
> in turn is enforced using SA.

[Ahmad]
If that the understanding, I am fine, let us continue.

> [RKo:>] It is entirely up to the trust relationship/security 
> model what type of security is employed. 

[Ahmad]
We need to understand the details of this trust model in order to make
sure what we are defining is a secure protocol not a defected one nor
one which is specific for certain deployment that is still unknown, at
least for me.

> For instance, some 
> deployments are perfectly fine using data origin 
> authentication whereas others may require encryption.

[Ahmad]
What you just said is that data path MUST have some kind of security. I
agree that data path MUST be secure. I also agree, as you listed, there
are different levels of security. However, we MUST define and understand
the minimum requirement for this data path security to make sure that we
have a secure protocol. If any deployment would like to add on top of
that, sure that is a +.

>  
> > Unless we are assuming that there is a specific deployment 
> here that 
> > we have in mind and goes beyond this
> trust
> 
> [RKo:>] I don't understand how you can implement a security 
> mechanism without assuming a trust model. So, I don't follow 
> the above sentence.
> 
> Regards,
> 
> -Rajeev
> 
> > > > >> loss of some configurable number of packets could be 
> couple of
> > > options.
> > > > >>
> > > > >