Subject: [netext] Review of draft-ietf-netext-redirect-03.txt

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 9 Aug 2010 16:22:59 -0700

Hello,

I reviewed draft-ietf-netext-redirect-03.txt and have a few comments.
I think these comments should be addressed before the document can be
sent to the IESG.

- This document tries to re-define runtime assignment of LMA to mean
the redirect functionality from rfLMA to r2LMA. I don't believe that
is correct. For example, when the MAG talks to AAA server on a per-MN
basis to figure out which LMA to use, that is also runtime assignment
of the LMA. Anytime, the MAG is not configured with the LMA
information, and the MAG picks the LMA on a per-MN session basis, it
is run-time assignment. I suggest picking "LMA redirection
functionality" to describe this new feature. If you want to re-define
it, please mention that in the context of this document, it means
option 1, where the BCE is created on r2LMA in the initial PBU/PBACK
exchange itself. No additional PBU is required. And define redirect to
mean option 2, where the BCE is not created on r2LMA until the MAG
sends an explicit PBU to r2LMA. Currently, the document is hard to
read, since it uses these two terms interchangeably.

- There is some text in various sections that talks about rfLMA
processing the ESP header, stripping it out and then send the PBU sans
any security information to the r2LMA. When the rfLMA does this, the
IP header changes completely (destination address, source address,
length, IP header checksum, UDP checksum, etc..) Are you sure you are
just forwarding the PBU to the r2LMA? :) You do point out in place
that the rfLMA is sort of a ProxyMAG. Perhaps you should just make
that explicit, i.e., the rfLMA acts like a proxyMAG to the LMA. I
understand why you would want to leave rfLMA's behavior vague, but
this is going to come up during the IESG review.

- There is a requirement in section 3 for the SAs to be setup in
advance. How does the MAG know the list of LMAs in a LMA cluster or a
re-direction domain. Doesn't this change dynamically, when lets say,
someone inserts an additional blade in a chassis or removes one?

- In section 1, you talk about DNS-based load balancing. That
paragraph didn't make sense to me. DNS-based load balancing typically
means round robin, right? I don't think anyone would deploy a system
where the LMAs constantly update the zone's DNS server with their
current load. That would be crazy.

A few minor comments.

>  o  Support for IPv6 anycast addressing [RFC4291]: the current PMIPv6
>     specification does not specify how the PMIPv6 protocol should
>     treat anycast addresses assigned to mobility agents.  For example,
>     a blade architecture LMA may appear to the routing system as
>     multiple LMAs with separate unicast IP addresses and with one or
>     more "grouping" anycast addresses.  A MAG could then initially
>     send a PBU to an anycast LMA address and receive a PBA from an
>     anycast LMA address.

Wouldn't the response come back from a unicast address?

>  Redirection Domain
>
>     A group of LMAs that consist of at least one rfLMA and one or more
>     r2LMAs.  A rfLMA is allowed to redirect mobility sessions only to
>     r2LMAs that belong to the same redirection domain.

I think, this should be expanded to say it can include multiple blades
in a single network element, multiple physical network elements,  and
multiple LMAs distributed geographically.

>  The LMA MUST NOT include the Redirect mobility option in the PBA and
>  perform the redirection, unless the MAG indicated the redirection
>  functionality support in the corresponding PBU using the Redirection-
>  Capability mobility option.

I think you need to add another paragraph before this that says the
MAG SHOULD include the redirection capability mobility option in the
PBU if it supports redirection. A related comment, I think "MAY" is
the wrong keyword. You should be "SHOULD". You have used "MAY" in many
places to describe MAG's behavior on including the redirect capability
mobility option.

>  MAGs and LMAs MUST support the redirection functionality only during
>  the initial PBU/PBA exchange that creates a new mobility session.

Please refer to RFC 5142 for mid-session redirect here. Otherwise
someone might write a new draft to address the missing functionality
"hinted" in the above paragraph. :)

>  If a PMIPv6 domain deployment with a redirection requires that a
>  rfLMA has to modify a received PBU in any way e.g., by changing the
>  destination IP address field of the outer IP header, then the
>  security mechanism (such as possible authentication options) used to
>  protect the PBU must not cover the outer IP header on those parts
>  that might get modified.

Aren't you changing more than the destination address on the PBU?
Otherwise how does r2LMA differentiate between a PBU that was
forwarded from rfLMA and a PBU that was received from the MAG
directly? Its not clear to me.

> Alternatively, the rfLMA can do all
>  required security mechanism processing on the received PBU and remove
>  those security related options from the PBU that would cause the
>  security check to fail on the r2LMA.

It looks like this is the only option to me.

Hope that helps.

Vijay

---

From: jouni korhonen <[email-masked]>
Date: Wed, 11 Aug 2010 00:36:50 +0300

Hi Vijay,

Thanks for the review. See my comments inline.

> read, since it uses these two terms interchangeably.

I think I can align the terminology i.e. change 'redirection' to 'runtime assignment'.. except in mobility option names.

> just forwarding the PBU to the r2LMA? :) You do point out in place

Hmm.. do you have a better terminology to suggest instead of forwarding?

> that explicit, i.e., the rfLMA acts like a proxyMAG to the LMA. I

This depends heavily on the collocation properties of the "LMA" as described in Section 5.3 last paragraph. I do not see a reason to make it more explicit as it is at the moment.

> this is going to come up during the IESG review.

I can imagine that :(

> someone inserts an additional blade in a chassis or removes one?

Could you point the specific text? Section 5.3.2 says:

   o  If there is no SA between the MAG and the r2LMA, the MAG MAY treat
      the PBA as if the binding update failed and log the event.  The
      MAG SHOULD initiate a dynamic creation of the SA between the MAG
      and the r2LMA (note that the dynamic creation of the SA is outside
      ... 

The MAG has to have a SA with the rfLMA (preconfigured or dynamically created), or otherwise it would not be able to send the initial PBU to the rfLMA in the first place (this is not different from RFC5213).

> current load. That would be crazy.

Well..I've seen similar solutions been proposed (for real) so there are people with these ideas. Furthermore, round-robin is not the only DNS-based load balancing approach. It just happens to be there in e.g. bind as an build-in option.

> Wouldn't the response come back from a unicast address?

No. The first PBA comes back from the anycast address. This makes the security processing way simpler.

> multiple LMAs distributed geographically.

Ok. How about:

   Runtime Assignment Domain

      A group of LMAs that consist of at least one rfLMA and one or more
      r2LMAs.  A rfLMA is allowed to redirect mobility sessions only to
      r2LMAs that belong to the same redirection domain. The rfLMA and one or
      more r2LMAs may consist of multiple blades in a single network element,
      multiple physical network elements,  or multiple LMAs distributed
      geographically.

> places to describe MAG's behavior on including the redirect capability

Right, agree about the use of SHOULD instead of MAY.

Section 5.1 already contains the common MAG related behavior, which says the above (with MAY at the moment though). I do not think we need to repeat that text in Section 5.2.

> "hinted" in the above paragraph. :)

 Ok, will add a reference to Section 3 as well.

> directly? Its not clear to me.

There is the "e.g.". I did not list all possible fields that might get altered. How about:

   If a PMIPv6 domain deployment with a redirection requires that a
   rfLMA has to modify a received PBU in any way e.g., by changing the
   destination IP address or any other field of the outer IP header,
   then the security mechanism...

> It looks like this is the only option to me.

If the (selected) security solution does not cover the outer transport IP header, then rfLMA can modify the IP header as much as it want and the security check on the r2LMA would not fail. Not that it would immediately make sense to have such security solution, but it definitely is possible.

> Hope that helps.

Thanks!

- Jouni

> 
> Vijay
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext