Subject: [Mipshop] AD review of draft-das-mipshop-andsf-dhcp-options

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Jun 2010 12:47:13 +0300

I have reviewed this draft.

It is basically in good shape and can move forward. I had one major
technical question which we can hopefully resolve easily with the help
of DHCP experts, and two relatively minor updates to the security
considerations text.

I will ask the DHC WG to review this draft as well, and would also like
to ask the authors to revise the draft according to the comments as
soon as possible.

Technical:

I am not particularly fond of the practice to define both address and
DNS versions of the same option, but I can live with that.

In case that the server cannot find any ANDSF Server satisfying
the requested Option Code, the server MUST return the ANDSF Option
by setting the Option Code to the requested Option Code and the
length of the Option to 0.

This seems to be in conflict with advice from RFC 3315:

If the client has included
an Option Request option in the Solicit message, the server includes
options in the Advertise message containing configuration parameters
for all of the options identified in the Option Request option that
the server has been configured to return to the client.

In other words, do we return empty options, or no options, for the
stuff that the server does not recognize or does not have configuration
information for?

This issue may exist on the DHCPv4 side as well.

I would like to ask the DHCP experts to explain what the recommended
approach is here. (The draft will need to be reviewed by the DHC
working group anyway.)

7. Security Considerations

The security considerations text should probably highlight the
importance of securing the actual ANDSF as opposed to securing merely
the discovery phase. This way you can also avoid reliance on
recommending something that is not in practice going to happen (DHCP
authentication).

In deployments where DHCP authentication is not available, 3GPP
specific lower layer security services may be sufficient to protect
DHCP messages.

... except in non-3GPP network access scenarios :-) I would suggest
simply saying "... specific link layer security services may be
sufficient ..."

Editorial:

ANDSF is specified in [3GPPTS23.402].

I'd prefer to not have references in the abstract so that it can stand
on its own. Perhaps this sentence can be removed and only retained in
the introduction?

and selection assistance data to the mobile nodes for multi-access

network scenarios where 3GPP access-network level solutions are not

Extra empty line.

selection of non-3GPP networks[3GPPTS23.402].

missing space between the last word and the "[" character.

When the DHCP server receives either an ANDSF IPv4 Address Option or
ANDSF Domain Name List Option in the PRL, the DHCP server MUST
Include the option in its response messages (as defined in [RFC2131])
that may contain a list of one or more IP addresses or a list of one
or more FQDNs of the ANDSF server hosting the service.

I thought that the server's PRL behaviour was actually defined in
RFC2132. But I could be mistaken.

6.2.1 Mobile node behavior

Different indentation (spaces before the section number) confuses the
IETF tools document htmlization.

This document also defines two DHCPv6 options as described in
Sections
4 and 5.

Indentation problems.

[3GPP TS23.402] www.3gpp.org/ftp/Specs/html-info/23402.htm
3GPP TS 23.402 V8.8.0 (2009-12): Architecture
enhancements for non-3GPP accesses (Release 8)

[3GPP Ts 24.302] www.3gpp.org/ftp/Specs/html-info/24302.htm
3GPP TS 24.302 V8.4.1 (2009-12): Access to the 3GPP
Evolved Packet Core (EPC) via non-3GPP access
networks; Stage 3;(Release 8)

Inconsistent capitalization and spacing.

Jari

---

From: Subir Das <[email-masked]>
Date: Tue, 22 Jun 2010 09:03:42 -0400

Jari,
Thanks for your review. My answers inline.

regards,
-Subir

Jari Arkko wrote:
> I will ask the DHC WG to review this draft as well, and would also 
> like to ask the authors to revise the draft according to the comments 
> as soon as possible.
>
> *Technical:*
>
> stuff that the server does not recognize or does not have 
> configuration information for?
>
   SD> Will wait for DHC WG review.
> recommending something that is not in practice going to happen (DHCP 

    SD> I am not sure I understand this. By 'actual ANDSF' do you mean 
ANDSF Server and client messages or protecting ANDSF server?
> simply saying "... specific link layer security services may be 
   SD>  Ok
> *Editorial:*
    SD> Ok
>> network scenarios where 3GPP access-network level solutions are not
  OK> will fix it.
> missing space between the last word and the "[" character.
 SD> will fix it
>> Include the option in its response messages (as defined in [RFC2131 <http://tools.ietf.org/html/rfc2131>])
  SD> will verify this.
>>    This document also defines two DHCPv6 options as described in 
  SD> will fix it.
>
>>    [3GPP TS23.402] www.3gpp.org/ftp/Specs/html-info/23402.htm <http://www.3gpp.org/ftp/Specs/html-info/23402.htm>
>>    [3GPP Ts 24.302] www.3gpp.org/ftp/Specs/html-info/24302.htm <http://www.3gpp.org/ftp/Specs/html-info/24302.htm>
 SD> will fix it.
>
> Jari
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mipshop
>

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Jun 2010 16:30:54 +0300

Subir,

> ANDSF Server and client messages or protecting ANDSF server?

Sorry, I was unclear. I meant the protocol between the MN and the ANDSF 
server.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Jun 2010 16:34:20 +0300

Subir,

>   SD> Will wait for DHC WG review.

By the way, after sending out the review I checked with Ralph Droms who 
said that servers should not return empty options, they should not 
return the option at all. But we can wait for additional comments from 
the working group.

Jari

---

From: Subir Das <[email-masked]>
Date: Tue, 22 Jun 2010 09:41:12 -0400

JAri,

Jari Arkko wrote:
> Sorry, I was unclear. I meant the protocol between the MN and the 
> ANDSF server.

  SD> But we are not dealing with any protocol messages between MN and 
ANDSF server in this draft  Do we need to make an assumption that DHCP 
server may reside in the ANDSF server and hence the transaction between
          MN and ANDSF server needs to be protected?

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Jun 2010 16:50:50 +0300

Subir,

> But we are not dealing with any protocol messages between MN and ANDSF 
> server in this draft  Do we need to make an assumption that DHCP 

The security considerations section need not be limited to the small 
protocol piece defined here. You can and often should explain something 
about the entire system. In this case my advice would be to recommend 
that while discovery security can be employed, the real security should 
reside in the actual protocol exchanges that come later.

I do not know what the ANDSF protocol does, however. If it has 
end-to-end security then that's great and your security considerations 
section becomes a better story by making the above change. If ANDSF has 
not seecurity then that too is interesting information and should 
probably be highlighted -- because then the only security of the 
operation at the system level depends on the security of the discovery 
phase.

Jari