Subject: [MEXT] AD review of draft-ietf-metxt-binding-revocation

From: Jari Arkko <[email-masked]>
Date: Sat, 25 Jul 2009 17:13:06 +0300

I have reviewed this draft. It is basically in very good shape, but I 
did see a few minor issues which I would like to get corrected before 
last call.

Here are my detailed comments:

Section 5 talks about NATs and UDP encapsulation, but only with respect 
to proxy mobility. Client mobility case should be handled as well.

The list of fields after Figure 4 might be more readable if you included 
all fields, such as MH Type.

>    Indication message, the responder MUST constructs the Binding
MUST construct

>    Since some mobility entities, e.g., local mobility anchor and mobile
>    access gateway, are allowed to receive and possibly send a Binding
>    Revocation Indication or Binding Revocation Acknowledgement for
>    different cases, therefore, if IPsec is used to secure signaling
>    between the them, it prevents any possible man in the middle
>    reflection attack.
>   

Its not clear to me what attacks you are talking about here. Reflection 
attacks normally mean that the attacker sends a packet that a third 
party responds to and sends the response to the victim.

Perhaps you meant to say "... prevents the processing of a message not 
constructed by an authorized party"?

>    BCE that belong to a specific realm, e.g. @companyabc.com, that are

Please use example.com instead.

> wildcard
>    NAI, e.g. [email-masked], to identify all the mobile nodes BCEs
>    that need to be removed.
>   
You need to specify what the syntax of the wildcard format is. Note that 
'*' is a legal character in the username portion of a NAI [RFC4282], so 
I would recommend considering another syntax (such as @example.com).

I would like to change the retranmission procedure to use an exponential 
back-off, in a style similar to RFC 3775, Section 11.8. This procedure 
is both more friendly to other traffic in a congestion situation, as 
well as faster in resending a lost first packet.

Jari

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 27 Jul 2009 09:28:53 -0500

Hello Jari,

Thanks for the review and comments. Please see inline.

Regards,
Ahmad

> -----Original Message-----
> From: Jari Marko [mailto:[email-masked]] 
> Sent: Saturday, July 25, 2009 9:13 AM
> To: [email-masked]; [email-masked]
> Subject: AD review of draft-ietf-metxt-binding-revocation
> 
> I have reviewed this draft. It is basically in very good 
> shape, but I did see a few minor issues which I would like to 
> get corrected before last call.
> 
> Section 5 talks about NATs and UDP encapsulation, but only 
> with respect to proxy mobility. Client mobility case should 
> be handled as well.
[Ahmad]
Sure, we will address client MIP6 case.

> 
> The list of fields after Figure 4 might be more readable if 
> you included all fields, such as MH Type.

[Ahmad]
No problem. Will do.

> Its not clear to me what attacks you are talking about here. 
> Reflection attacks normally mean that the attacker sends a 
> packet that a third party responds to and sends the response 
> to the victim.
> 
> Perhaps you meant to say "... prevents the processing of a 
> message not constructed by an authorized party"?

[Ahmad]
I was thinking that if a man in the middle was able to capture a packet
which contains a BRI from the MAG, for example, the attacker will not be
able to send the packet back to the MAG as if it is coming from the LMA.
Thinking about this a little more, the consequences is not so critical
since if the MAG has sent a BRI to the LMA, it is already revoking the
MN session anyway. However, I was initially thinking even if the MAG
receives that packet and processes it as if it is coming from the LMA,
it is a problem, but IPsec prevents that since IPsec SA in
unidirectional with different SPIs. That why I mentioned it. If you
think it is not necessary, we can remove it.

> Please use example.com instead.

[Ahmad]
Sure.

> You need to specify what the syntax of the wildcard format 
> is. Note that '*' is a legal character in the username 
> portion of a NAI [RFC4282], so I would recommend considering 
> another syntax (such as @example.com).

[Ahmad]
Sure. Will fix it.

> 
> I would like to change the retranmission procedure to use an 
> exponential back-off, in a style similar to RFC 3775, Section 
> 11.8. This procedure is both more friendly to other traffic 
> in a congestion situation, as well as faster in resending a 
> lost first packet.
[Ahmad]
No problem, we can adopt an exponential back-off scheme similar to
RFC3775.
We will update the draft and post as soon as possible.

Thanks again.

Best Regards,
Ahmad

---

From: Jari Arkko <[email-masked]>
Date: Fri, 31 Jul 2009 22:39:37 +0300

Ahmad,

> Sure, we will address client MIP6 case.

OK

>> you included all fields, such as MH Type.

OK

> think it is not necessary, we can remove it.

Its not so much that this is unnecessary. I'm more concerned that the 
text focuses on a relatively weird corner case and without explaining it 
well.  And yet there's the more general issue that if you use IPsec to 
secure the packets, you can be sure that only an authorized party can 
have sent a particular message. So I would suggest focusing on the 
general property which covers even your special case.

>> another syntax (such as @example.com).

Ok. It would be good to see the change here, because unlike the other 
changes that I requested, this one may not be trivial. Perhaps the 
chairs can find some RADIUS and NAI capable reviewers to make sure the 
wildcard format doesn't have any unexpected side effects?

> We will update the draft and post as soon as possible.

Thanks

Jari

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 1 Aug 2009 01:29:40 -0500

Thanks Jari,
Please see inline.

> From: Jari Arkko [mailto:[email-masked]] 
> > [Ahmad]
> > I was thinking that if a man in the middle was able to capture a 
> > packet which contains a BRI from the MAG, for example, the attacker 
> > will not be able to send the packet back to the MAG as if 
> it is coming from the LMA.
> Its not so much that this is unnecessary. I'm more concerned 
> that the text focuses on a relatively weird corner case and 
> without explaining it well.  And yet there's the more general 
> issue that if you use IPsec to secure the packets, you can be 
> sure that only an authorized party can have sent a particular 
> message. So I would suggest focusing on the general property 
> which covers even your special case.

[Ahmad]
Sure; will modify the text to address the more general case.

> is. Note 
> >> that '*' is a legal character in the username portion of a NAI 
> >> [RFC4282], so I would recommend considering another syntax 
> (such as 
> >> @example.com).
> >>     
> >
> > [Ahmad]
> > Sure. Will fix it.
> >   
> 
> Ok. It would be good to see the change here, because unlike 
> the other changes that I requested, this one may not be 
> trivial. Perhaps the chairs can find some RADIUS and NAI 
> capable reviewers to make sure the wildcard format doesn't 
> have any unexpected side effects?

[Ahmad]
Good idea. 
Will post the text before publishing the draft, hopefully early next
week.
 
Regards,
Ahmad