ietf
[Top] [All Lists]

Re: [PART-II] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10

2009-09-02 17:26:29
HI--I think we're almost closed on this Part II --remaining comments below:

On Aug 29, 2009, at 2:14 AM, Ahmad Muhanna wrote:

[...]

Does the potential guess-ability of a sequence number have
security implications?

[Ahmad]
Not at all. Packet must pass IPsec authentication first.

But remembering that IPSec is only a should, does that answer change if IPSec is not used? I guess the question is around what damage would be done if it was guessed.



[...]




-- S7.2, paragraph 2: "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
local mobility anchor and mobile access gateway, it prevents
any of them from processing a Binding Revocation message that
was not constructed by an authorized party."

I have trouble parsing this sentence.

(You did not respond to this one.)

[Ahmad]
We basically wanted to say that since the MAG and LMA are both allowed
to send BRI and receive BRA, IPsec will enable the peer to detect if a
man in the middle, for example, reflected a BRI message that it has
initiated back to the peer and consequently silently drop that BRI
message. In the broader sense, we wanted to say that IPsec enables any
of the peers to detect if the received BRI is coming from an
unauthorized party and consequently ignore without processing it.

I hope we got it right:)

I think if you replace the ".. allowed
to receive and possibly send a Binding Revocation Indication
or Binding Revocation Acknowledgement for different cases" with "...allowed
to send BRI and receive BRA", it would be easier to read.


[...]

-- 4th bullet: "unless an Alternate Care-of Address mobility option is included"

In which case you do what?
[Ahmad]
Thanks! It is a long story:)

What it means here is the following:
The destination IP address of the packet is set to the care-of
address.
However, if the home agent include an Alternate care-of
address option
in the BRI, the destination IP address MUST NOT be set to
the care-of
address.

When the home agent is able to include an Alternate Care-of
Address in
the BRI? ONLY when the mobile node sends a BU message with the
Alternate
Care-of address included in the BU. If the MN include the Alternate
Care-of address inside the BU, the source IP address of the packet
carrying the BU is different than the IP address inside the
Alternate
Care-of address.

NOW: It depends on the home agent implementation:
1. The home agent can send the BRI message to the care-of address
regardless, if this care-of address received as the source IP
address of
the packet carrying the BU or inside the BU in the Alternate Care-of
address option.

2. If the home agent saves the source address of the packet
carried
the
BU in addition to the MN care-of address in the MN BCE,
then the home
agent can send the packet that carries the BRI message to
the source
IP
address of the packet that carried the BU.

3. Depends on implementation of the home agent, the home agent may
send
the BRI to the MN care-of address all the time.

The key point here is: If the HA include the Alternate
care-of address
inside the BRI, then the destination IP address of the
packet carrying
the BRI is set to the source IP address of the packet that
carried the
BU.

Are all of those choices interoperable?
[Ahmad]
Yes.

Okay.



But in any case, I think you need at least some guidance. Right now,
you have a conditional MUST without an "else" clause for that
condition. A simple ..., in which case, the destination
address SHOULD
(or MAY) be set to <something>.

[Ahmad]
Here is the new text:

"
  o  The care-of address for the binding MUST be used as the
     destination address in the packet's IPv6 header, unless an
     Alternate Care-of Address mobility option is included in the
     Binding Revocation Indication.  If an Alternate Care-of Address
     option is included in the Binding Revocation Indication message,
     the destination address in the packet's IPv6 header SHOULD be set
     to the source IP address of the packet that carried the latest
     successful Binding Update with the Alternate Care-of address
     included.
"

Okay, that helps.

[...]



Also, the language here sounds more like
you are talking about the initiator. The responder validates
these are true, but does not set the values, correc"t"
[Ahmad]
True. Will reword it.


[...]


-- Bullet 5:

Why not MUST?
[Ahmad]
Good question. Since the sub-bullets include the proper normative, I
believe we can remove "SHOULD" and rely on the sub bullet normative
text.

"
 o  If the Global (G) bit is NOT set, the local mobility
anchor uses
    the included mobility options to identify the impacted mobile
    node binding as follows:
"


Hmm, I don't see any normative statement in that sub-bullet.
(The all-
caps NOT is in a condition clause, not a normative statement--and
therefore probably should not be all-caps.)

[Ahmad]
Are you saying the text in the sub-bullets is not normative?

Ah, I see you were talking about the bullets subordinate to the bullet you quoted--nevermind.

(But the NOT in "bit is NOT set" really should not be capitalized).

[...]

Thanks!

Ben.


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>