Subject: Re: [netlmm] Lack of session indication

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 11 Aug 2008 12:20:52 -0700 (PDT)

Hi Vijay,
  In which WG 2473bis is being standardized?

Regards,

Behcet

----- Original Message ----
From: Vijay Devarapalli <[email-masked]>
To: Sri Gundavelli <[email-masked]>
Cc: [email-masked]
Sent: Monday, August 11, 2008 1:39:18 PM
Subject: Re: [netlmm] Lack of session indication

Hi Sri,

Sri Gundavelli wrote:
> 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.

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

> 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).

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.

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

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.

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

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

Vijay

> 
> Sri
> 
> 
> 
> 
> 
> On Mon, 11 Aug 2008, Vijay Devarapalli wrote:
> 
>> 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,
>>>
>>>
>>>
>>> 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
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

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

>   In which WG 2473bis is being standardized?

Most likely INT-area mailing list. It hasn't started yet. My
understanding is that we will be revising 2473 since there are
MTU-related issues due to tunneling.

Vijay