Subject: Re: [netlmm] Questions for koodli-netlmm-path-and-session-management

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

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: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 11 Aug 2008 13:49:35 -0400

Hi Rajeev and others,

This reminds me of an offline discussion I had.

Currently the PMIPv6 specification says the LMA must silently drop
tunneled packets from a MAG if there is no corresponding binding cache
entry. This follows from RFC 3775 that says the home agent should
silently drop tunneled packets from the mobile node if there is no
corresponding binding cache entry. We didn't pay too much attention to
this when we were working on the PMIPv6 spec.

IMO, it is wrong for the LMA to silently drop the packets. There should
be some sort of indication sent back to the MAG. This should be rate
limited of course. Otherwise the LMA becomes susceptible to DoS attacks.

For the indication, perhaps we should the Binding Error Message that is
defined in RFC 3775. The purpose of the Binding Error message is to
indicate problems with bindings on the HA/LMA/CN. We could use the
existing status '1'. RFC 3775 says

   1 - Unknown binding for Home Address destination option

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.

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,
> 
>  
> 
> 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
> 
>  
> 
>

---

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

Hi Vijay,

Thanks for starting this thread.

Couple of points:

1. This issue is not specific to PMIP6 tunnels, but a general tunneling
issue, applicable to 2473. When a tunneled packet is received with a
incorrect inner source (receieved packets has the source same as
the locally owned prefix), the receiver should apply the general ingress
filtering rules and should drop the packet.

2. I think the LMA's behaviour of silently dropping the packet should
be ok. This will ensure there are no DOS attacks. To your comment that
we can rate-limit this, will require tracking and additional complexity
in the data path.

3. Use of a control message such as Binding Error for a data packet
is debatable. It requires new hooks between the control and the data
mgmt elements (if implemented seperately). If we still want to send
some notification, ICMP error is probably the way to go and not a MIP
control message and specially in the absence of security (optional
security for data path).

4. We followed the 3775 guidance and which I think is correct.

Bottom line, we should update this behavior, if we are violating
any tunneling specs. Also, 2473bis should probably venture into this
in bit more detail along with the other code point issues.

At the same time, I also see some value in MAG detecting this error
case, but the approach is the question.

Sure, we need more discussions on this.

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 11 Aug 2008 13:29:30 -0500

Hi Vijay,

> this when we were working on the PMIPv6 spec.

Dropping the packets when there is no BCE is the right thing to do. I don't
see a downside to this behavior. I don't see the LMA behavior being any
different in the context of PMIP6 from that of a MIP6 HA.

> be some sort of indication sent back to the MAG.

This does help the MAG reset its state for the MN. But there is no harm done
if there is no error received from the LMA.

> This should be rate

If we decide to send an error message from the LMA, then the new status code
makes sense. 

-Raj

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 11 Aug 2008 11:39:18 -0700

Hi Sri,

> we can rate-limit this, will require tracking and additional complexity

You can rate-limit on how many binding error messages you send.

> control message and specially in the absence of security (optional

ICMP error does not make sense. We are not dealing with some part of the 
message that the receiver does not understand. This is more about the 
lack of binding cache entry when the other end thinks that there is a 
binding cache entry. The binding error message would use the same 
security mechanism that is in use for the PBU/PBAck messages. I hope we 
don't digress by discussing security issues. They are not relevant here.

> 4. We followed the 3775 guidance and which I think is correct.

Disagree. RFC 3775 implicitly assumes that every mobile node, as soon as 
the MIPv6 stack is started, creates a binding with its home agent. So 
when the home agent receives a tunneled packet with a corresponding 
binding cache entry, it was considered some sort of DoS attack and as a 
result dropped the packet. In PMIPv6, it is not the same. It is 
typically an error condition on the MAG that should be fixed ASAP.

> in bit more detail along with the other code point issues.

No, I don't think we need to add anything to 2473bis. Each protocol that 
makes use of tunneling, should decide how the error conditions are 
handled. I don't think 2473bis can anticipate all the error conditions 
or the scenarios in which tunneling is used.

> Sure, we need more discussions on this.

I am interested in figuring out what message we should be using to 
indicate the lack of a session/binding.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 11 Aug 2008 11:42:57 -0700

Hi Raj,

> different in the context of PMIP6 from that of a MIP6 HA.

IMO, there is a a difference. Please see my response to Sri.

> if there is no error received from the LMA.

It might take too long for the MAG to discover this. If the LMA sends an 
explicit indication, the MAG would try to correct this by sending a 
Proxy BU and creating a new binding.

BTW, this would be an optional extension. We can't add this to the 
PMIPv6 base specification anyway at this point. This extension, if the 
NETLMM WG agrees to it, would be specified in the Path Management document.

Vijay

---

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

Hi Vijay,

On Mon, 11 Aug 2008, Vijay Devarapalli wrote:

> message that the receiver does not understand. This is more about the lack of 
> binding cache entry when the other end thinks that there is a binding cache 
> entry. The binding error message would use the same security mechanism that 
> is in use for the PBU/PBAck messages. I hope we don't digress by discussing 
> security issues. They are not relevant here.
>

When we are defining a message that gets activated for a data message,
we should not shy-away from discussing security issues.

Any case, I still think the tunnel peer dropping the packets silently
is the right thing.

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.

For #b, LMA would send a revocation message to MAG. MAG should
not be sending tunneled packets. No need for additional error
message, we already have revocation message.

For #c, its not session specific. We need either a notification
message, other mechanism such as restart-counter, or other
mechanism.

In what other cases other than the above, the session would magically
disappear, assuming we solve #c ?

Sri

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 11 Aug 2008 14:31:48 -0500

Hi Vijay,

On 8/11/08 1:42 PM, "ext Vijay Devarapalli" <[email-masked]> wrote:

> It might take too long for the MAG to discover this.

But is that a problem?
The MN might discover that it does not have connectivity and initiate
reachability detection (NUD). The MAG itself does not have to do anything
specific for proper operation.

> If the LMA sends an

Now you are assuming that the fact that the LMA does not have a BCE is an
error which causes the MAG to send a PBU. The LMA may have cleared the BCE
for various reasons (lifetime expired for example and not having received a
refresh... Just an example... Don't take it literally).

If the LMA has deprecated the BCE and the MAG is unaware of it, what would
cause the MAG to send a new PBU? The UE initiating NUD?

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 11 Aug 2008 14:39:59 -0500

Vijay,

> typically an error condition on the MAG that should be fixed ASAP.

I don't see why you consider the non-existence of the BCE at the LMA and
receiving a packet from the MAG an error condition that is specific to
PMIP6. Even in MIP6, the HA may deprecate the BC for the MN (without
explicitly informing the MN) in which case any packets received from the MN
(or from a malicious source) are dropped. The MN can however reinitiate the
binding in the case of MIP6, which is the only issue in the case of PMIP6.

> indicate the lack of a session/binding.

Generic notification ;) ?

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 11 Aug 2008 13:15:36 -0700 (PDT)

> Generic notification ;) ?

I agree :) But, probably the restart counter business should be
sufficient in this case. For now I think, this should be fine.

I think, we need to step back and see when we would have a need
for this event. Please see my earlier email on the scenarios
related to this state. I cant think of the case, when we might
need this, if we solve case #c using restart counter or other
means.

Sri

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 12 Aug 2008 08:56:46 +1000

I agree with Sri on all points. In addition, using an insecure message like
a binding error can have the same serious security consequences of ICMP
errors, which is not desirable, given that we don't have to do it.

Hesham

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 12 Aug 2008 08:45:05 -0500

> > ICMP error does not make sense. We are not dealing with 
> some part of 
> > the message that the receiver does not understand. This is 
> more about 
> > the lack of binding cache entry when the other end thinks 
> that there 
> > is a binding cache entry. The binding error message would 
> use the same 
> > security mechanism that is in use for the PBU/PBAck 
> messages. I hope 
> > we don't digress by discussing security issues. They are 
> not relevant here.
> >
> 
> When we are defining a message that gets activated for a data 
> message, we should not shy-away from discussing security issues.

[Ahmad]
I agree with Sri here. 
Of course, it is a security issue. Otherwise, why do we need to have a
secure mobility signaling to start with. As I understand this issue, the
pCoA is bound to the pHoA after the successful exchange of a secure
PMIPv6 signaling. The LMA does not accept packets for a specific pHoA
except from the registered tunnel, i.e. pCoA. If an attacker is able to
trigger a signaling message via an unsecured data path, then it is a
security issue that needs to be addressed carefully.

IMO, this only happens when the MAG and the LMA are out of sync with
respect to a specific session, because the MAG is not supposed to
forward the data for that pHoA through the tunnel to start with unless
there is a binding for that PHoA with the pCoA. If that is the case,
then we could use Binding Revocation to indicate to the MAG that this
BCE does not exist and needs to be registered. But I still believe that
will open the door for a possible DOS attack and the most appropriate
and correct behavior for the LMA is "to silently drop the packet" as
already documented and, IMO, we should not do anything else.

> 
> Any case, I still think the tunnel peer dropping the packets 
> silently is the right thing.
> 
> Lets step back a bit and explore this scenario when we would 
> need this.
> 
> 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.
> 
> For #b, LMA would send a revocation message to MAG. MAG 
> should not be sending tunneled packets. No need for 
> additional error message, we already have revocation message.
> 
> For #c, its not session specific. We need either a 
> notification message, other mechanism such as 
> restart-counter, or other mechanism.
> 
> In what other cases other than the above, the session would 
> magically disappear, assuming we solve #c ?
> 
> 
> Sri
> 
> 
> 
> 
> 
> 
> 
> 
> 
>